CN108781396B

CN108781396B - Radio access network node, radio terminal, core network node and methods therefor

Info

Publication number: CN108781396B
Application number: CN201780014285.6A
Authority: CN
Inventors: 二木尚; 林贞福
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2016-08-10
Filing date: 2017-05-15
Publication date: 2021-04-13
Anticipated expiration: 2037-05-15
Also published as: EP3499968A4; JP2021180519A; US11356854B2; US20220046427A1; JP7036268B2; EP4138457B1; BR112018017081A2; CN113194478A; WO2018029930A1; JP2022058940A; JP7363995B2; US20190058997A1; CN108781396A; EP3499968A1; BR112018017081B1; US20210345119A1; US11343679B2; JPWO2018029930A1; EP3499968B1; JP6930540B2

Abstract

During handover of a radio terminal (1) from a first network to a second network, a target RAN node (3) is operable to: receiving slice information from a core network (5) regarding a network slice that is included in the second network and to which the radio terminal (1) is to be connected; upon receiving the slice information, creating radio resource configuration information to be used by the radio terminal (1) in the second network after handover; and transmitting the radio resource configuration information to the radio terminal (1) through the first network. It is possible to facilitate appropriate configuration of the AS layer or NAS layer of the target RAT in inter-RAT handover.

Description

Radio access network node, radio terminal, core network node and methods therefor

Technical Field

The present disclosure relates to radio communication systems and, in particular, to handover of a radio terminal between different Radio Access Technologies (RATs).

Background

The third generation partnership project (3GPP) has started working on standardization for a fifth generation mobile communication system (5G) (i.e., 3GPP Release 14, in 2016) to make 5G a commercial reality within 2020 (see non-patent document 1). 5G is expected to be enabled by the continued enhancements/evolutions of LTE and LTE-Advanced and by the innovative enhancements/evolutions resulting from the introduction of new 5G air interfaces, i.e. new Radio Access Technologies (RATs). The new RAT supports, for example, higher frequency bands and its continued evolution than the frequency bands supported by LTE/LTE-Advanced (e.g., 6GHz or lower). For example, the new RAT supports the centimeter band (10GHz or higher) and the millimeter band (30GHz or higher).

In the present specification, the fifth generation mobile communication system is also referred to as a next generation (NextGen) system (NG system). The new RAT of the NG system is called New Radio (NR), 5G RAT or NG RAT. The new Radio Access Network (RAN) and the core network for NG systems are referred to as NextGen RAN (NG RAN) and NextGen core (NG core), respectively. A radio terminal (i.e., User Equipment (UE)) connected to the NG system is called NextGen UE (NG UE). Official names of RATs, UEs, radio access networks, core networks, network entities (or nodes), protocol layers, etc. of the NG system will be determined in the future as standardization work progresses.

Unless otherwise specified, the term "LTE" as used in this specification includes enhancements/evolutions of LTE/LTE-Advanced to provide for interaction with NG systems. The enhancements/evolutions of LTE and LTE-Advanced that interact with NG systems are also known as LTE-Advanced Pro, LTE +, or enhanced LTE (eLTE). Further, unless otherwise specified, terms related to LTE networks and logical entities used in this specification, such as "Evolved Packet Core (EPC)", "Mobility Management Entity (MME)", "serving gateway (S-GW)", and "Packet Data Network (PDN) gateway (P-GW)" include their enhancements/evolution to provide interaction with NG systems. Enhanced EPCs, enhanced MMEs, enhanced S-GWs, and enhanced P-GWs are also referred to as, for example, enhanced EPCs (eEPCs), enhanced MMEs (eGMEs), enhanced S-GWs (eS-GWs), and enhanced P-GWs (eP-GWs), respectively.

In LTE and LTE-Advanced, to achieve quality of service (QoS) and packet routing, bearers per QoS class and per PDN connection are used in both the RAN (i.e., evolved universal terrestrial RAN) and the core network (i.e., Evolved Packet Core (EPC)). That is, in the bearer-based QoS (or per-bearer QoS) concept, one or more Evolved Packet System (EPS) bearers are configured between the UE and the P-GW in the EPC, and a plurality of Service Data Flows (SDFs) having the same QoS class are transmitted through one EPS bearer satisfying the QoS. An SDF is one or more packet flows that match an SDF template (i.e., packet filter) based on Policy and Charging Control (PCC) rules. Further, each packet to be sent over an EPS bearer for packet routing contains information identifying which bearer (i.e., a General Packet Radio Service (GPRS) tunneling protocol (GTP) tunnel) the packet is associated with.

In contrast, with the NG system, it has been suggested that although a radio bearer can be used in the NG RAN, no bearer is used in the NG core or in the interface between the NG RAN and the NG core (see non-patent document 1). In particular, instead of an EPS bearer, a PDU flow is defined and one or more SDFs are mapped to one or more PDU flows. The PDU flow between the NG UE and the user plane terminal entity in the NG core (i.e. the entity corresponding to the P-GW in the EPC) corresponds to an EPS bearer in the EPS bearer based QoS concept. That is, NG systems employ a flow-based QoS (or per-flow QoS) concept rather than a bearer-based QoS concept. In the flow-based QoS concept, QoS is handled per PDU flow. Note that the association between the UE and the data network is referred to as a "PDU session". The term "PDU session" corresponds to the term "PDN connection" in LTE and LTE-Advanced. Multiple PDU flows can be configured in one PDU session.

In this specification, systems such as LTE and LTE-Advanced systems that configure end-to-end bearers (e.g., EPS bearers) between a UE and an edge node (e.g., P-GW) in a core network and employ the bearer-based QoS concept are referred to as "bearer-based systems" or "bearer-based networks. In contrast, a system that does not use any bearer in the core network or in the interface between the core network and the RAN and employs a flow-based QoS concept (such as an NG system) is referred to as a "bearer-less system" or a "bearer-less network". Similar to the NG system described above, radio bearers may be used in the RAN in a bearer-less network. The term "bearer-less" can also be expressed as e.g. GTP-less, PDN-less, tunnel-less, IP-flow-based, SDF-based, transport-flow-based or (PDU) -session-based. However, in this specification, the NG system may function as a bearer-based system and may support both stream-based transmission of user data and bearer-based transmission of user data.

Further, it has been proposed that the NG system supports network slicing (see non-patent document 1). Network slicing uses Network Function Virtualization (NFV) technology and Software Defined Networking (SDN) technology and makes it possible to create multiple virtualized logical functions on a network. Each virtualized logical network is referred to as a network slice or network slice instance, includes logical nodes and functions, and is used for specific flows and signaling. Either the NG RAN or the NG core or both have Slice Selection Functions (SSFs). The SSF selects one or more network slices suitable for the NG UE based on information provided by at least one of the NG UE and the NG core.

Patent document 1 discloses handover from a bearer-less network (e.g., 5G) to a bearer-based network (e.g., LTE) and handover from a bearer-based network (e.g., LTE) to a bearer-less network (e.g., 5G). In the handover from 5G to LTE disclosed in patent document 1, a source control node (i.e., Access Control Server (ACS)/eMME) in a 5G core (or NG core) maps QoS parameters of a service flow in a bearer-less network (i.e., 5G) to EPS bearer level QoS in a bearer-based network (i.e., LTE). The 5G QoS parameters for a service flow are, for example, DiffServ code point (DSCP) values. EPS bearer level QoS in LTE is, for example, QoS level identifier (QCI) and Allocation and Retention Priority (ARP). Mapping the DSCP values to the EPS bearers may be performed in a one-to-one manner or in an n-to-one manner. The source ACS/eMME sends APN information including information on EPS bearer level QoS to the target MME. And the target MME establishes a GTP tunnel for the UE according to the received APN information.

Further, in the handover from LTE to 5G disclosed in patent document 1, the source MME in the LTE core (i.e., EPC) sends a forward relocation request containing necessary bearer context information to the target ACS/eMME in the 5G core (NG core). The target ACS/eMME performs mapping of QCI values received from LTE (i.e., source MME) to 5G QoS parameters (i.e., DSCP values) and supplies them to the transmitting node (i.e., mobility gateway access router (M-GW/AR) or mobility gateway edge router (M-GW/ER)) in the 5G core (or NG core). In so doing, the target ACS/eMME establishes at least one Generic Routing Encapsulation (GRE) tunnel for transporting the service flow (i.e., IP packet) of the UE.

CITATION LIST

Patent document

Patent document 1: international patent publication No. WO2015/160329

Non-patent document

Non-patent document 1: 3GPP TR 23.799V0.6.0(2016-07) "3rd Generation Partnership Project; technical Specification Group Services and System attributes; study on Architecture for Next Generation System (Release 14) ",2016, 7 months

Disclosure of Invention

Technical problem

The inventors have studied handover between NR system (i.e., 5G) and LTE system, and found several problems. For example, patent document 1 fails to teach that during a handover procedure from an LTE system to an NG system, a network slice to which a UE is to be connected after the handover is considered for configuring an Access Stratum (AS) layer or a non-access stratum (NAS) layer of a target RAT (i.e., NG RAT).

Accordingly, one of the objects to be achieved by the embodiments disclosed herein is to provide an apparatus, method and program that facilitate appropriately configuring the AS layer or NAS layer of a target RAT in handover from a network that does not support network slicing to a network that supports network slicing. It should be noted that the above described objective is only one of the objectives to be achieved by the embodiments disclosed herein. Other objects or problems and novel features will become apparent from the following description and the accompanying drawings.

Technical scheme

In one aspect, a target Radio Access Network (RAN) node associated with a second 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, during handover of the radio terminal from the first network to the second network: receiving slice information on a network slice, which is included in the second network and to which the radio terminal is to be connected, from the core network; creating radio resource configuration information to be used by the radio terminal after handover in the second network, upon receiving the slice information; and transmitting the radio resource configuration information to the radio terminal through the first network.

In one aspect, a source Radio Access Network (RAN) node associated with a 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 receive a handover-related message from the second network during handover of the radio terminal from the first network to the second network, and transmit the handover-related message to the radio terminal. The handover-related message contains at least one of slice information on a network slice that is included in the second network and to which the radio terminal is to be connected and radio resource configuration information based on the network slice in the second network.

In one aspect, a radioterminal 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 receive, during a handover from a first network to which the radio terminal is connected to a second network, a handover-related message from a Radio Access Network (RAN) node of the first network. The handover-related message includes at least one of slice information regarding a network slice in the second network and radio resource configuration information based on the network slice in the second network.

In one aspect, a 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 is configured to, during handover of the radio terminal from the first network to the second network, send slice information to a target Radio Access Network (RAN) node associated with the second network regarding a network slice that is included in the second network and to which the radio terminal is to be connected.

In one aspect, a method in a target Radio Access Network (RAN) node associated with a second network, comprising:

during handover of a radio terminal from a first network to a second network,

receiving slice information on a network slice that is included in the second network and to which the radio terminal is to be connected, from the core network;

creating radio resource configuration information to be used by the radio terminal after handover in a second network, upon receiving the slice information; and

radio resource configuration information is transmitted to the radio terminal through the first network.

In one aspect, a method in a source Radio Access Network (RAN) node associated with a first network, comprising:

during handover of a radio terminal from a first network to a second network,

receiving a handover-related message from the second network, the handover-related message containing at least one of slice information on a network slice that is included in the second network and to which the radio terminal is to be connected and radio resource configuration information based on the network slice in the second network; and

the handover-related message is transmitted to the radio terminal.

In one aspect, a method in a radio terminal, comprising: during handover from a first network to which a radio terminal is connected to a second network, receiving a handover-related message from a Radio Access Network (RAN) node of the first network, the handover-related message containing at least one of slice information regarding a network slice in the second network and radio resource configuration information based on the network slice in the second network.

In one aspect, a method in a core network node, comprising: during handover of a radio terminal from a first network to a second network, slice information is sent to a target Radio Access Network (RAN) node associated with the second network regarding a slice of the network that is included in the second network and to which the radio terminal is to be connected.

In one aspect, a program comprises a set of instructions (software code), which when loaded into a computer, causes the computer to perform a method according to the above described aspects.

Advantageous effects

According to the above-described aspects, it is possible to provide an apparatus, method, and program that facilitate appropriate configuration of the AS layer or NAS layer of a target RAT in handover from a network that does not support network slicing to a network that supports network slicing.

Drawings

Fig. 1 illustrates an example of a configuration of a radio communications network according to some embodiments;

fig. 2 illustrates an example of a configuration of a radio communications network according to some embodiments;

fig. 3A is a sequence diagram showing an example of an inter-RAT handover procedure from an LTE system to an NG system according to the first embodiment;

fig. 3B is a sequence diagram showing this example of an inter-RAT handover procedure from an LTE system to an NG system according to the first embodiment;

fig. 4A is a sequence diagram showing another example of an inter-RAT handover procedure from an LTE system to an NG system according to the first embodiment;

fig. 4B is a sequence diagram showing this another example of an inter-RAT handover procedure from the LTE system to the NG system according to the first embodiment;

fig. 5 is a flow chart illustrating an example of a method performed by a core network according to the first embodiment;

fig. 6 is a flow chart illustrating an example of a method performed by a target NR node b (NR nb) according to the first embodiment;

fig. 7 is a flow chart illustrating an example of a method performed by a source LTE eNB according to the first embodiment;

fig. 8 is a flowchart illustrating an example of a method performed by a radio terminal according to the first embodiment;

fig. 9 is a sequence diagram showing an example of an inter-RAT handover procedure from an LTE system to an NG system according to the second embodiment;

fig. 10 is a sequence diagram showing an example of an inter-RAT handover procedure from an LTE system to an NG system according to the second embodiment;

fig. 11 is a sequence diagram showing an example of an inter-RAT handover procedure from an LTE system to an NG system according to the third embodiment;

fig. 12 is a sequence diagram showing an example of an inter-RAT handover procedure from an LTE system to an NG system according to the third embodiment;

fig. 13A is a sequence diagram showing an example of an inter-RAT handover procedure from an NG system to an LTE system according to the fourth embodiment;

fig. 13B is a sequence diagram showing this example of an inter-RAT handover procedure from an NG system to an LTE system according to the fourth embodiment;

fig. 14A is a sequence diagram showing another example of an inter-RAT handover procedure from an NG system to an LTE system according to the fourth embodiment;

fig. 14B is a sequence diagram showing this another example of an inter-RAT handover procedure from the NG system to the LTE system according to the fourth embodiment;

fig. 15 is a block diagram illustrating a configuration example of a radio terminal according to some embodiments;

fig. 16 is a block diagram illustrating a configuration example of a base station according to some embodiments;

fig. 17 is a block diagram illustrating a configuration example of a base station according to some embodiments;

fig. 18 is a block diagram illustrating a configuration example of a core network node according to some embodiments;

fig. 19A shows an example of the format of mobility from EUTRA command message;

fig. 19B shows an example of the format of mobility from EUTRA command message;

fig. 20 shows an example of a format of a handover required message;

fig. 21 shows an example of the format of a source NR NB to target NR NB transparent container;

fig. 22 shows an example of the format of a source NR NB to target NR NB transparent container;

fig. 23 shows an example of the format of a source NR NB to target NR NB transparent container;

fig. 24 shows an example of the format of a source NR NB to target NR NB transparent container;

fig. 25 shows an example of a format of an (NR) handover request message;

fig. 26 shows an example of a format of an (NR) handover request message;

fig. 27 shows an example of a format of an (NR) handover request message;

fig. 28 shows an example of the format of slice information;

fig. 29 shows an example of the format of a session endpoint ID;

fig. 30 shows an example of a format of an (NR) handover request response message;

FIG. 31 shows an example of a format of a target-to-source transparent container;

fig. 32 shows an example of a format of an (NR) handover request reply;

fig. 33 shows an example of the format of an (NR) handover request reply;

fig. 34 shows an example of the format of a forwarding address;

fig. 35 shows an example of a format of the S1AP handover command message; and

fig. 36 shows an example of the format of the NG2AP handover command message.

Detailed Description

Specific embodiments will be described in detail below with reference to the accompanying drawings. The same or corresponding elements are denoted by the same symbols throughout the drawings, and repeated explanation is omitted as necessary for the sake of clarity.

Each of the embodiments described below may be used alone, or two or more of the embodiments may be combined with each other as appropriate. These embodiments include novel features that differ from one another. Therefore, the embodiments contribute to achieving the object or solving problems different from each other and also contribute to obtaining advantages different from each other.

First embodiment

Fig. 1 shows a configuration example of a radio communication network according to some embodiments including this embodiment. In the example shown in fig. 1, the radio communications network comprises a radio terminal (UE)1, an LTE base station (i.e. eNB)2, a New Radio (NR) base station (i.e. NR nodeb (NR nb)3), an EPC4 and a nextgen (ng) core 5. UE1 has the capability to connect to an LTE system including LTE eNB2 and EPC4, and is based on the capability to connect to a Nextgen (NG) system including NR NB3 and NG core 5.

In the example shown in fig. 1, EPC4 is connected to NG core 5. In particular, one or more nodes in EPC4 are connected to one or more nodes in NG core 5 via a control plane interface. In some embodiments, the MME in the EPC4 may be connected to a control node (i.e., a Control Plane Function (CPF) node) via a control plane interface, which is included in the NG core 5 and has at least a portion of the MME function. Further, one or more nodes in the EPC4 may be connected to one or more data nodes (i.e., User Plane Function (UPF) nodes) in the NG core 5 via a user plane interface. Each data node (i.e., UPF node) may be a node having at least a portion of the S-GW functionality. That is, EPC4 may be enhanced to perform interactions with NG systems that include NG core 5 and may be referred to as eEPC.

Similarly, the NR NB3 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 NB3 may be connected to one or more UPF nodes in the NG core 5 via a user plane interface (e.g., NG3 interface). Also, the UE1 may be connected to one or more CPF nodes in the NG core 5 via a control plane interface (e.g., NG1 interface). The NG1 interface may be defined as a logical interface for transporting NAS layer information, and the transmission of NAS layer information may be performed over the NG2 interface and over a radio interface (e.g., NG Uu) between the NR NB3 and the UE 1.

Fig. 2 shows another configuration example of a radio communication network according to some embodiments including this embodiment. In the example shown in fig. 2, the LTE eNB2 is connected to the NG core 5. That is, the LTE eNB2 is connected to an MME in the NG core 5 or a control node having at least a part of MME functions (i.e., a CPF node) through a control plane interface (e.g., NG2 interface). Further, the LTE eNB2 is connected to a serving gateway (S-GW) in the NG core 5 or a data node (i.e., UPF node) having at least a part of the S-GW function through a user plane interface (e.g., NG3 interface). As described above, LTE eNB2 may be enhanced to connect to NG core 5 and may be referred to as an LTE eNB. In some embodiments, NG core 5 may establish a virtualized network slice that provides logical EPC node and EPC functionality. In some embodiments, an E-UTRAN including LTE eNB2 may be connected to the same network slice as a NG RAN including NR NB 3. Alternatively, the E-UTRAN including LTE eNB2 may connect to different network slices.

In the example shown in fig. 1 and 2, LTE eNB2 may connect to NR NB3 via a direct inter-base station interface (e.g., an X3 interface). The direct inter-base station interface may be used for signaling between LTE eNB2 and NR NB3 or user packet transfer or both. However, the direct inter-base station interface between LTE eNB2 and NR NB3 may be omitted.

In addition to the NG1, NG2, and NG3 interfaces described above, the NG system may include other interfaces. Each interface may be referred to as a reference point. NG RANs (i.e., different NR NBs) may be connected to each other through an NX2 interface. CPF nodes having one or both of Mobility Management Functions (MMF) and Session Management Functions (SMF) may be connected to UPF nodes through control plane interfaces (e.g., NG4 interfaces). Different UPF nodes may be connected to each other through a user plane interface (e.g., NG9 interface). CPF nodes having different functions may be connected to each other through a control plane interface. For example, a CPF node with MMF and SMF may be connected to a CPF node with Policy Control Function (PCF) through a control plane interface (e.g., NG7 interface). CPF nodes with MMF and SMF may be connected to a node with Subscriber Data Management (SDM) functionality through a control plane interface (e.g., NG8 interface). The CPF node may be connected to an Application Function (AF) enabled node through a control plane interface (e.g., NG5 interface). The UPF nodes may be connected to an external or local Data Network (DN) through a user plane interface (e.g., NG6 interface). The SMF may include a function of authenticating a user or a terminal and a function of authorizing a service or a network slice. The network nodes described above are individually or collectively referred to as a Network Function (NF).

In some embodiments, the NG system comprising the NR NB3 and NG core 5 supports data transfer based on the flow-based QoS (or per-flow QoS) concept described above. The NG system comprising the NR NB3 and NG core 5 can also be configured to support bearer-based transport using bearers per QoS class and per PDU session. The bearer in the NG system may be configured between a pair of Network Functions (NFs), e.g. between the NR NB3 and a user plane function in the NG core 5, or between two user plane functions in the NG core 5. Alternatively, the bearer in the NG system may be configured between the UE1 and the user plane function in the NG core 5 through the NR NB 3. The bearers in the NG system may be referred to as NG-EPS bearers and the radio access bearers in the NG system may be referred to as NG-RABs. The bearer in the NG system can be used for the transmission of multiple packet flows (i.e., PDU flows).

The NG-RAB may include a radio bearer configured between UE 1(NG UE) and NR NB3 and a bearer configured between NR NB3 and the user plane function in the NG core 5 (e.g., NG3 bearer). The NG-EPG bearer may comprise a NG-RAB and a core network bearer (e.g., NG9 bearer) configured between user plane functions in the NG core 5 (e.g., between an edge GW and a data network gateway (DN GW)). The edge GW is a gateway to the radio access network and is similar to the user plane functionality of the LTE S-GW. However, in the NG system, unlike the LTE S-GW, the UE1 may be connected to a plurality of edge GWs. The DN GW is a gateway to external networks (i.e., data networks) and is similar to the user plane functionality of the LTE P-GW. In the NG system, similar to the LTE P-GW, UE1 may be connected to a plurality of DN GWs.

More particularly, the NG-EPS bearer may be configured between UE1 (i.e., NG UE) and slice-specific user plane control (i.e., slice-specific user plane nf (sunf)) in NG core 5. The NG-RAB may be configured between UE1 (i.e., NG UE) and a common user plane function (i.e., common user plane (CUNF)) in the NG core 5. In this case, CUNF provides the function of the edge GW and sun provides the function of the DN GW. The CUNF may associate the NG-RAB with a core network bearer (e.g., a NG9 bearer). That is, the NG-EPS bearer may include a NG-RAB between UE1 (i.e., NG UE) and CUNF and a core network bearer (e.g., NG9 bearer) between CUNF and SUNF.

A NG system that supports bearer-based transport may also be configured to differentiate between data flows (e.g., PDU flows) in a bearer to perform QoS processing (e.g., dropping of packets) on a per-data-flow basis (e.g., on a per-PDU-flow basis). For example, the NR NB3 may associate a bearer (e.g., NG3 bearer) configured between the NR NB3 and the user plane functions in the NG core 5 with a radio bearer, perform packet forwarding between the bearer (e.g., NG3 bearer) and the radio bearer, and perform QoS processing (e.g., dropping of packets) per data flow (e.g., PDU flow) in the bearer.

Note that when (E) the LTE eNB2 is connected to the NG core 5 over the NG2 interface, the radio access bearer corresponding to the LTE EPS radio access bearer (E-RAB) may be defined as an NG EPS radio access bearer (NE-RAB) and the bearer corresponding to the LTE EPS may be defined as an NG EPS bearer (NEPS bearer). The NE-RAB may include a radio bearer configured between the UE1 and the LTE eNB2 and a bearer (e.g., a NG3 bearer) configured between the LTE eNB2 and a user plane function (e.g., an edge GW or CUNF) in the NG core 5. The NEPS bearers may include NE-RABs and core network bearers (e.g., NG9 bearers) configured between user plane controls in the NG core 5 (e.g., between an edge GW and a DN GW, or between a CUNF and a sun).

LTE eNB2 connected to NG systems may be configured to distinguish between data flows (e.g., PDU flows) in the NE-RAB and perform QoS processing (e.g., dropping of packets) on a per-data-flow basis (e.g., on a per-PDU-flow basis). For example, the LTE eNB2 may associate a bearer (e.g., NG3 bearer) configured between the LTE eNB2 and user plane functions in the NG core 5 with a radio bearer, perform packet forwarding between the bearer (e.g., NG3 bearer) and the radio bearer, and perform QoS processing (e.g., dropping of packets) according to a data flow (e.g., PDU flow) in the bearer.

The embodiment provides a method for handing over UE1 from an LTE system that does not support network slicing to an NG system that supports network slicing. Fig. 3A and 3B show an example of a procedure for handing over the UE1 from the LTE system to the NG system in the configuration example of the radio communication network shown in fig. 1. Fig. 3A shows a handover preparation phase and fig. 3B shows a handover execution phase.

In the procedure shown in fig. 3A and 3B, the source base station (i.e., LTE eNB 2) starts handover by sending a handover required message on the interface (or reference point) between the source base station (i.e., LTE eNB 2) and the core network (i.e., EPC 4). The procedure shown in fig. 3A and 3B may be an enhancement/evolution of "E-UTRAN to UTRAN Iu mode Inter RAT handover (E-UTRAN to UTRAN Iu mode Inter RAT handover)" in LTE. Alternatively, the procedure shown in fig. 3A and 3B may be an enhancement/evolution of "S1-based handover" with respect to MME relocation in LTE.

In step 301, UE1 is Connected to LTE eNB2 and is in a Connected state (i.e., RRC _ Connected). The UE1 receives a measurement configuration from the LTE eNB2, performs neighbor cell measurement and inter-radio access technology (inter-RAT) measurement according to the received measurement configuration, includes measurement of an E-utran (LTE) cell and a NG-RAN cell, and transmits a measurement report to the LTE eNB 2. The measurement configuration is for example contained in an RRC connection reconfiguration message transmitted from the E-UTRAN to the UE.

In step 302, the LTE eNB2 determines to perform inter-RAT handover on the cell of the NR NB3 and sends a handover required message to a source control node (i.e., source MME) in the EPC 4. The handover required message contains an identifier of the target NR NB 3. Further, the handover required message may contain a handover type Information Element (IE) indicating that it is handed over from LTE to NR. For example, "LTE to nr (ltetonr)" is set in the handover type IE. Additionally or alternatively, the handover required message may contain a target NR-NB identifier Information Element (IE). The handover required message may contain a source-to-target transparent container IE. The source-to-target transparent container IE may include RRC layer information (i.e., RRC container) and may also include information on a bearer (e.g., E-RAB). The RRC layer information (i.e., RRC container) includes at least a portion of the radio resource configuration in the serving cell of the UE1, e.g., managed by the LTE eNB2, which is necessary for the radio resource configuration in the NR NB 3.

In step 303, the source MME in the EPC4 determines that the type of handover is an inter-RAT handover to NR (or NG system) based on the handover type IE or the target NR-NB identifier UE contained in the received handover required message. The MME in EPC4 selects the target control node in NG core 5. The target control node is a node having at least a part of the functions of the MME in the EPC 4. The MME in EPC4 sends a forward relocation request message to the target control node to start the handover resource allocation procedure. The forward relocation request message contains the Mobility Management (MM) context and all PDN connections active for UE1 in the source system (i.e., the LTE system). Each PDN connection includes a list of associated APNs and EPS bearer contexts. The MM context includes information about the EPS bearer context and security-related information. The forward relocation request message may also include information identifying one or more service data flows associated with each EPS bearer context (e.g., SDF template or Traffic Flow Template (TFT)).

In step 304, the target control node in the NG core 5 performs a procedure for creating a bearer-less session. In particular, the target control node determines that the packet transfer node (or gateway) for the UE1 needs to be relocated and then selects the target transfer node (or gateway) in the NG core 5. The target transmitting node (or gateway) is a node having at least part of the functionality of the S-GW in the EPC 4. The target control node sends a create session request message to the target transfer node (or gateway). The create session request message may also include information identifying one or more service data flows associated with each EPS bearer context (e.g., SDF template or Traffic Flow Template (TFT)). This information for identifying one or more service data flows is derived from a forward relocation request message, which has been sent from a source MME in the EPC4 to a target control node in the NG core 5. The target transmitting node (or gateway) allocates its local resources and sends a create session response message to the target control node.

Note that when the NG system uses bearers per QoS class and per PDU session to support bearer-based transport, and when relocation of the transmitting node is not required, the target control node in the NG core 5 may perform the bearer modification procedure in step 304 instead of the session creation procedure.

Further, in step 304, the target control node (e.g., CPF) in the NG core 5 determines (or selects) a network slice to which the UE1 is to be connected after the handover. In one example, a target control node (e.g., CPF) in NG core 5 may select a network slice for UE1 based on the QoS required for the EPS bearer of the SDF of UE 1. Additionally or alternatively, the forward relocation request message sent by the source MME in the EPC4 (step 303) may also contain network slice assistance information. The network slice assistance information assists the target control node in selecting, configuring or authorizing a network slice. The source MME in EPC4 may receive at least a portion of the network slice assistance information from UE1 and send it to a target control node in NG core 5. The target control node in the NG core 5 may perform the creation of the selected network slice instance.

The network slice assistance information may indicate, for example: any one or any combination of the following: type of UE1 (e.g., device type or UE category); a purpose accessed by UE1 (e.g., UE usage type); a type of service desired by the UE1 (e.g., requested/preferred service type or multi-dimensional descriptor (MDD)); slice information selected by UE1 (e.g., selected slice type, selected slice Identity (ID), or selected Network Function (NF) ID); slice information that UE1 has previously authorized (e.g., authorized slice type, authorized slice ID, or authorized NF ID); acceptable delay for UE1 (e.g., allowed delay or tolerable delay). The service type may indicate, for example, a type of use case, such as broadband communication (e.g., enhanced mobile broadband: eMBB), high-reliability/low-latency communication (e.g., high-reliability low-latency communication: URLLC), M2M communication with a large number of connections (e.g., large number of machine type communication: mtc), or the like. The slice ID may indicate, for example, any one or any combination of: slice instance information (e.g., Network Slice Instance (NSI) ID); private network information (e.g., private core network (DCN) ID); and network domain name information (e.g., Domain Network Name (DNN) ID). The NF UD may indicate an identifier such as any one or any combination of the following: public network functions (e.g., public nf (cnf)); common control plane functions (e.g., common control plane nf (ccnf)); common user plane functions (e.g., common user plane nf (cunf)); and a data gateway (e.g., a data network gateway (DN GW)).

In step 305, the target control node in the NG core 5 transmits an NR handover request message to the target NR NB 3. The NR handover request message contains slice information. The slice information includes, for example, information on at least one of: a network slice that is included in the NG core 5 and to which the UE1 is to be connected (or the UE1 is to be connected) after handover; a network slice included in the NG core 5 and to which the UE1 is permitted to connect; and a network slice that is included in the NG core 5 and to which the UE1 can connect.

In particular, the slice information may include identification information of the determined (or selected) slice (i.e., network slice: NS), identification information of a network Node (NF), or type information of the slice, or any combination thereof. The slice identification information may be, for example, a slice ID, NSI ID, MDD, DCN ID, or DNN, or any combination thereof. The identification information of the network node may include, for example, a NF ID, CNF ID, CCNF ID, slice-specific control plane NF (scnf) ID, CUNF ID, slice-specific user plane (SUNF) ID, UPF ID, or DN GW ID, or any combination thereof. The slice type information may comprise, for example, a slice type indicating any one or any combination of: service type, service class, and use case. Additionally or alternatively, the slice type information may include a tenant ID or a subscription contract (subscription group, e.g., home UE or roaming UE) indicating a use case. The slice type information may include an MDD including a slice type and a tenant ID as its elements. Note that the content of the slice information described above may be specified per network slice. Thus, when the UE1 is to be connected to a plurality of network slices simultaneously, the slice information may include a set of a plurality of information items corresponding to the number of network slices to which the UE1 is to be connected.

The slice information may also include a mobility level or a session level or both. The mobility class may indicate one of predefined mobility levels (e.g., high mobility, low mobility, and no mobility). For example, high mobility means that the geographical area in which the network slice supports mobility for UE1 (or mobility of licensed UE 1) is larger than the geographical area of low mobility, and the level of continuity requirement for the service (or PDU session) during handover is higher. No mobility means that the network slice supports mobility of UE1 (or grants mobility of UE 1) only in a very limited geographical area. The mobility class may be specified per UE or may be specified per network slice. The session class may indicate one of the predefined session types (e.g., session pre-set, post-session set, and PDU-less session). For example, to maintain service (or PDU session) during mobility as in the case of existing handover, the session preset may indicate that the PDU session needs to be established before the UE completes the targeted movement (i.e., cell, beam, etc.). Conversely, the post-session settings may indicate that the PDU session may be established after the UE has moved to the target. The session class may be specified per PDU session. The mobility class and the session class may be included in a slice type. In other words, a slice type may contain multiple attributes, including a mobility level and a session level.

The slicing information may include at least a portion of the network slicing assistance information. That is, in step 305, the target control node in the NG core 5 may include at least a portion of the network slice assistance information that has been received from the source MME in the EPC4 contained in the slice information in the NR handover request message and forwarded it to the target NR NB 3.

Further, the NR handover request message in step 305 may contain flow information. The flow information relates to at least one session (i.e., PDU session) established in the bearer-less network (i.e., NG system) to transmit at least one packet flow (i.e., PDU flow) of the UE 1. For each packet flow (i.e., PDU flow) of the UE1, the flow information includes a flow identifier (e.g., PDU flow ID), an address of a transmitting node in the NG core 5 (e.g., transport layer address), and an Uplink (UL) Session Endpoint Identifier (SEID), and also includes flow QoS parameters. The Session Endpoint Identifier (SEID) may be, for example, a Tunnel Endpoint Identifier (TEID) or a network function (node) identifier (NF ID). The TEID may be, for example, a GTP-TEID or a GRE-TEID.

The flow information may also indicate a mapping between EPS bearers for UE1 and PDU flows. For example, the flow information may indicate one or more SDFs mapped to each EPS bearer of UE1 and a flow identifier (e.g., PDU flow ID) assigned to each of the one or more SDFs. The flow information may also include priority information (e.g., a priority indicator), flow type information (e.g., a flow type indicator), or a flow class. The priority information may indicate, for example, a relative priority order among the plurality of streams or an absolute priority order of each stream. The flow type information may indicate, for example, which use case or which service the flow corresponds to. Further, the stream level may indicate, for example, one of the predefined stream types (e.g., lossless, delay tolerant, delay sensitive, and mission critical). The flow information may include the mobility level or session level or both described above.

As already described, the NG system including the NR NB3 and NG core 5 may be configured to support bearer-based transport using per QoS class and per PDU session, or may be configured to differentiate between data flows (e.g., PDU flows) in a bearer to perform QoS processing (e.g., dropping of packets) on a per data flow basis (e.g., on a per PDU flow basis). For example, the NR NB3 may associate a bearer (e.g., NG3 bearer) configured between the NR NB3 and a user plane function in the NG core 5 with a radio bearer, perform packet forwarding between the bearer (e.g., NG3 bearer) and the radio bearer, and perform QoS processing (e.g., dropping of packets) per data flow (e.g., PDU flow) in the bearer.

In this case, the flow information described above may indicate an association between a bearer for UE1 (e.g., a NG-RAB or NG3 bearer) and one or more packet flows for UE1 (i.e., a PDU flow) conveyed over the bearer. In other words, a control node (e.g., CPF) in the NG core 5 may send flow information to the NR NB3 to inform the NR NB3 of an association between a bearer for the UE1 (e.g., a NG-RAB or NG3 bearer) and one or more packet flows for the UE1 (i.e., a PDU flow) conveyed over the bearer. The NR NB3 may receive flow information from the control node in the NG core 5 and then perform QoS processing (e.g., dropping of packets) per data flow (e.g., PDU flow) in a bearer (e.g., NG3 bearer) configured between the NR NB3 and the user plane function in the NG core 5 according to the received flow information.

The target NR NB3 may perform admission control based on the NR handover request message containing slice information. For example, the target NR NB3 may determine whether to accept a bearer or a flow on a per-bearer basis or a per-flow basis. Additionally or alternatively, the target NR NB3 may perform admission control per network slice to which the UE1 is to be connected, based on slice information. In this process, the NR NB3 may determine whether it can accept each network slice. When there is a network slice that the NR NB3 cannot accept (or does not accept), the NR NB3 may map the network slice to a specific network slice (e.g., a default network slice) or connect the network slice to a specific NF (e.g., a CUPF). Alternatively, the NR NB3 may determine that it has failed when accepting the network slice.

In step 306, upon receiving the NR handover request message containing slice information, the target NR NB3 creates a UE context and allocates resources. The target NR NB3 also creates (or derives from) the slice information radio resource configuration information (e.g., radio parameters) necessary for the UE1 to establish a radio connection (e.g., RRC connection or radio bearer) associated with the NG system supporting the network slice. The radio resource configuration information may include at least one parameter included in the slice information.

The radio resource configuration information derived from the slice information may include radio (or RAN) parameters per network slice (or per use case). Use cases include, for example, enhanced mobile broadband (eMBB), mass machine type communication (mtc), and high-reliability low-latency communication (URLLC). The radio parameters per network slice (or per use case) may be basic physical channel parameters or basic layer 2/layer 3 (L2/L3) configuration. The basic physical channel parameters may include, for example, a frame/subframe structure, a Transmission Time Interval (TTI) length, a subcarrier spacing, and Physical Random Access Channel (PRACH) resources. The PRACH resources may be one or both of a preamble index and time/frequency resources. The basic L2/L3 configuration may include, for example, a frame/subframe pattern and a configuration of L2 protocol sublayers (L2 configuration, e.g., PDCP config, RLC config, or MAC config).

Additionally or alternatively, at least one of a message structure, a format of an Information Element (IE), a parameter value, and an object to be encoded and decoded according to asn.1 (abstract syntax notation 1) defining the information structure may be different per slice when signaling the RRC layer to specify (or indicate) radio resource configuration information derived from slice information.

Then, the target NR NB3 transmits an NR handover request response message containing the target-to-source transparent container to the target control node. The target-to-source transparent container contains radio resource configuration information (e.g., radio parameters) created by the target NR NB 3. As described later, the target-to-source transparent container is forwarded to the source LTE eNB2 through the core network (i.e., EPC4 and NG core 5).

Further, in step 306, the target NR NB3 may consider flow information contained in the NR handover request message when creating the UE context and radio resource configuration information. In particular, the target NR NB3 may create a UE context and a security context including information on a packet flow (i.e., PDU flow) based on the NR handover request message containing flow information. Further, the target NR NB3 may create (or derive from) radio resource configuration information necessary for the UE1 to establish a radio connection (e.g., RRC connection or radio bearer) associated with the bearer-less network (i.e., NG system) based on the flow information. The radio resource configuration information may include at least one parameter included in the flow information. The radio resource configuration information may include system information (e.g., system information block: SIB) about the cell (or mobility area or beam coverage area) of the target NR NB3, a common radio resource configuration (e.g., common resource configuration) for the UE, or a UE-dedicated radio resource configuration (e.g., dedicated resource configuration). The radio resource configuration information may also include information indicating a mapping between bearers (e.g., EPS bearers or Data Radio Bearers (DRBs)) in the cell of the source LTE eNB2 and flows (e.g., PDU flows) to be established in the cell of the target NR NB 3.

In step 307, the target control node in the NG core 5 sends a forward relocation response message containing the target to source transparent container to the source MME in the EPC 4. The forward relocation response message may also include an address and TEID allocated for downlink data forwarding. These addresses and TEIDs may be the address and TEID of the S-GW in EPC4 when indirect downlink forwarding is used. These addresses and TEIDs may be those of the target NR NB3 when direct downlink forwarding is used.

In step 308, the source MME sends a handover command message containing the target-to-source transparent container to the source LTE eNB 2. The handover command message may also contain a list of bearers subject to downlink data forwarding (e.g., a list of bearers subject to data forwarding). The "bearer _ Subject to Data forwarding list" IE includes, for example, an address and TEID for user traffic Data forwarding, and an identifier of a flow (e.g., PDU flow) Subject to Data forwarding. The source LTE eNB2 starts data forwarding for the bearer or flow (e.g., PDU flow) specified by the "bearer list subject to data forwarding" IE.

In step 309, the source LTE eNB2 transmits a Radio Resource Control (RRC) message containing the handover command message to the UE 1. The handover command message includes a transparent container containing radio resource configuration information that has been established by the target NR NB3 in the preparation phase. The RRC message may be, for example, a mobility command message from EUTRA or an RRC connection reconfiguration message.

In step 310, upon receiving the RRC message including the handover command message, the UE1 moves to the target RAN (i.e., NG RAN) and performs handover per radio resource configuration information provided by the handover command message. That is, the UE1 and the target NR NB3 associated with the NG system establish a radio connection. In step 311, UE1 transmits a handover confirmation for the NR message to target NR NB3 after it has successfully synchronized with the target cell. The message in step 311 may be an NR RRC connection reconfiguration complete message.

In step 312, when the UE1 has successfully accessed the target NR NB3, the target NR NB3 notifies it to the target control node in the NG core 5 by transmitting an NR handover notification message.

In step 313, the target control node in the NG core 5 recognizes that the UE1 has arrived on the target side and informs the source MME in the EPC4 of it by sending a forward relocation complete notification message. And the source MME sends a forward relocation completion response message to the target control node.

In step 314, the target control node in the NG core 5 performs the flow modification procedure and thereby completes the inter-RAT handover procedure. For example, the target control node may send a per-session (i.e., per-PDU session) modified flow request message to the transmitting node in the NG core 5. The modified flow request message may contain a flow identifier (e.g., PDU flow ID) and also an address of the target NR NB3 and a Downlink (DL) Session Endpoint Identifier (SEID). The Session Endpoint Identifier (SEID) may be, for example, a Tunnel Endpoint Identifier (TEID). A transmitting node in the NG core 5 may communicate with an edge node (i.e., eP-GW) in the EPC4 to inform the edge node (i.e., (e) P-GW) in the EPC4 of relocation of the transmitting node or a change in RAT type due to inter-RAT HO. In particular, the transmitting node in the NG core 5 may send a modify bearer request message per session (i.e. per PDN connection) to the edge node in the EPC 4. The edge node in EPC4 may send a modified bearer response message to the transmitting node in NG core 5. The transmitting node in the NG core 5 may send the modified flow response message to the target control node.

After completing the handover according to the procedure shown in fig. 3A and 3B, the path shown below may be used for data transmission of the UE 1. When the NG system comprising the NR NB3 and the NG core 5 supports bearer-based transport in the NG core 5 and a bearer (e.g., NG-EPS bearer) is used for the UE1 after handover, both the uplink path and the downlink path may comprise, for example, a path (e.g., GTP tunnel or GRE tunnel) between the source (or old) S/P-GW and the target (or new) user plane control (e.g., CUNF) in the NG core 5. In particular, the S/P-GW may transmit downlink data to a user plane control (e.g., CUNF) in the NG core 5, while a user plane control (e.g., CUNF) in the GN core 5 may transmit uplink data to the S/P-GW.

Conversely, when a bearer (e.g., an NG-EPS bearer) is not used for UE1 after handover, the CUNF may be relayed between the source (or old) S/P-GW and the target (or new) user plane function (e.g., SUNF with NW slicing function). In particular, the S/P-GW may transmit downlink data to the CUNF in the NG core 5 and then the CUNF may transmit the downlink data to another UNF having a per-flow control function. Alternatively, data transfer may be performed directly between the S/P-GW and the SUNF without traversing the CUNF. The data transmission path described above after the handover may also be used in other handover procedures described below.

Fig. 4A and 4B show an example of a procedure for handing over the UE1 from the LTE system to the NG system in the configuration example of the radio communication network shown in fig. 2. Fig. 4A shows a handover preparation phase and fig. 4B shows a handover execution phase.

Similarly to the procedure shown in fig. 3A and 3B, in the procedure shown in fig. 4A and 4B, the source base station (i.e., LTE eNB 2) starts handover by transmitting a handover required message on an interface between the source base station (i.e., LTE eNB 2) and the core network (i.e., NG core 5). Similar to the procedure shown in fig. 3A and 3B, the procedure shown in fig. 4A and 4B may be an enhancement/evolution of "E-UTRAN to UTRAN Iu mode inter-RAT handover" in LTE, or may be an enhancement/evolution of "handover based on S1" with respect to MME relocation in LTE.

The processes in steps 401 to 402 in fig. 4A are similar to those in steps 301 to 302 in fig. 3A. However, in step 402, the LTE eNB2 transmits a handover required message to the NG core 5. As already described, in the network configuration example shown in fig. 2, the E-UTRAN including the LTE eNB2 and the NG RAN including the NR NB3 may be connected to the same network slice. In this embodiment, handover of the UE1 from the LTE eNB to the NR NB3 is performed by signaling between one or more logical control nodes (i.e., control plane functions) and one or more logical transport nodes (i.e., user plane functions) created within the same network slice. In this embodiment, the handover required message in step 402 may be sent to a new or enhanced control node corresponding to the MME.

Alternatively, the E-UTRAN including LTE eNB2 and the NG RAN including NR NB3 may be connected to different network slices. In this embodiment, handover of the UE1 from LTE eNB2 to NR NB3 is performed by inter-slice communication between a network slice instance corresponding to the EPC to which LTE eNB2 is connected and a network slice instance corresponding to the pure NG core to which NR NB3 is connected. In this embodiment, the handover required message in step 402 may be sent to the MME in the network slice instance to which LTE eNB2 is connected.

The processes in steps 403 to 405 in fig. 4A are similar to those in steps 303 to 307 in fig. 3A. In the process shown in fig. 4A, the illustration of

steps

303 and 307 shown in fig. 3A is omitted. Processes corresponding to those in

steps

303 and 307 are executed within the NG core 5.

The processes in steps 406 to 411 in fig. 4B are similar to those in steps 308 to 314 in fig. 3B. In the process shown in fig. 4B, the illustration of step 313 shown in fig. 3B is omitted. Processes corresponding to those in step 313 are executed within the NG core 5.

Fig. 5 is a flow chart illustrating a procedure 500 as an example of a method performed by a core network. The core network corresponds to the EPC4 and the NG core 5 shown in fig. 1, or the NG core 5 shown in fig. 2. In step 501, the core network receives a handover required message for starting handover of the UE1 from the LTE system to the NG system from the source LTE eNB 2. Step 501 corresponds to step 302 in fig. 3A or step 402 in fig. 4A.

In step 502, the core network transmits to the target NR NB3 an (NR) handover request message containing slice information on a network slice that is included in the NG core 5 and to which the UE1 is to be connected after handover. Step 502 corresponds to step 305 in fig. 3A or step 404 in fig. 4A.

In step 503, the core network receives from the target NR NB3 an (NR) handover request reply message containing the target to source transparent container. The target-to-source transparent container contains radio resource configuration information (e.g., radio parameters) necessary for the UE1 to establish a radio connection associated with the NG system. Step 503 corresponds to step 306 in fig. 3A or step 405 in fig. 4A.

In step 504, the core network sends a handover command message containing the target-to-source transparent container to the source LTE eNB 2. Step 504 corresponds to step 308 in fig. 3B or step 406 in fig. 4B.

Fig. 6 is a flow chart illustrating a procedure 600 as an example of a method performed by the target NR NB 3. In step 601, the target NR NB3 receives an (NR) handover request message containing slice information on a network slice that is included in the NG core 5 and to which the UE1 is to be connected after handover from the core network (i.e., the NG core 5). Step 601 corresponds to step 305 in fig. 3A or step 404 in fig. 4A.

In step 602, the target NR NB3 sends a (NR) handover request reply message containing the target-to-source transparent container to the core network. The target-to-source transparent container contains the radio resource configuration information (e.g., radio parameters) necessary for the UE1 to establish a radio connection associated with the NG system. Step 602 corresponds to step 306 in fig. 3A or step 405 in fig. 4A.

In step 603, the target NR NB3 establishes a radio connection associated with the NG system for the UE1 based on the radio resource configuration information. Step 603 corresponds to step 310 in fig. 3B or step 408 in fig. 4B.

Fig. 7 is a flow diagram illustrating a procedure 700 as an example of a method performed by the source LTE eNB 2. In step 701, the source LTE eNB2 transmits a handover required message for starting handover of the UE1 from the LTE system to the NG system to the core network (i.e., EPC4 or NG core 5). Step 701 corresponds to step 302 of fig. 3A or step 402 of fig. 4A.

In step 702, the source LTE eNB2 receives a handover command message containing a target-to-source transparent container from the core network. The target-to-source transparent container contains radio resource configuration information necessary for UE1 to establish a radio connection associated with the NG system supporting network slicing. Step 702 corresponds to step 308 in fig. 3B or step 406 in fig. 4B.

In step 703, the source LTE eNB2 sends a mobility command message (e.g., handover command message) to the UE1, which contains radio resource configuration information and indicates handover to the bearer-less network. Step 703 corresponds to step 309 in fig. 3B or step 407 in fig. 4B.

Fig. 8 is a flow chart illustrating a procedure 800 as an example of a method performed by UE 1. In step 801, the UE1 receives a mobility command message (e.g., handover command message) from the source LTE eNB 2. The mobility command message contains radio resource configuration information necessary for the UE1 to establish a radio connection associated with the NG system. Step 801 corresponds to step 309 in fig. 3B or step 407 in fig. 4B.

In step 802, the UE1 establishes a radio connection by using the radio resource configuration information and a target NR NB3 associated with the NG system. Step 802 corresponds to step 310 in fig. 3B or step 408 in fig. 4B.

In this embodiment, the network may be configured so that the UE1 can know in advance whether the handover target cell (i.e., NR cell) supports network slicing. For example, the NR NB3 may broadcast system information (e.g., system information block type x: SIBx, e.g., x ═ 1) including network slice support information explicitly or implicitly indicating that network slices are supported in the NR cell (or it is possible to connect to an NG core capable of providing network slices). To indicate that network slicing is supported, the explicitly transmitted network slicing support information may further include a type of supported service (e.g., supported service type) or a supported slicing type (e.g., supported slicing type). In contrast, the explicitly transmitted network slice support information may include information on radio resource configurations that differ per network slice. UE1 may know to support network slicing in the cell upon detecting at least a portion of the received radio resource configuration per network slice designation. This information on radio resource configuration may include configuration information on physical resources, or system configuration information, or both. The configuration information on the physical resource may indicate at least one of: code, time, frequency and RACH preamble sequence(s). The system configuration information may indicate at least one of: subcarrier spacing, sampling rate, TTI, and subframe/frame format type. The network slice support information may be transmitted AS NAS layer information or may be transmitted AS layer information. In the former case, the AS layer (i.e., RRC) of UE1 receives this information and transmits it to the NAS layer.

The detailed procedure of the handover from the LTE system to the NG system according to the present embodiment is not limited to the specific example described above. For example, the names of messages in the handover procedure are not limited to those shown in several examples described above. In several of the examples of handover procedures described above, the order of the messages may be changed and some of them may be omitted. Further, they may include one or more additional messages.

As understood from the above description, the procedure of handover from the LTE system that does not support network slicing to the NG system that supports network slicing according to this embodiment includes the following steps. That is, the target NR NB3 receives slice information about a network slice to which the UE1 is to be connected from the NG core 5. Upon receiving the slice information, the target NR NB3 creates radio resource configuration information to be used by the UE1 in the NG system (i.e., NR NB 3) after handover, and transmits the created radio resource configuration information to the UE1 through the LTE system (i.e., LTE eNB 2). In this way, the UE1 uses the radio resource configuration information created by the target NR NB3 based on the slice information, thereby appropriately configuring one or both of the AS layer and the NAS layer of the target RAT associated with the NG system supporting the network slice.

Second embodiment

This embodiment provides a modified example of the method for handing over the UE1 from the LTE system to the NG system according to the first embodiment. Fig. 9 shows an example of a procedure for handing over the UE1 from the LTE system to the NG system in the configuration example of the radio communication network shown in fig. 1. The handover procedure shown in fig. 9 provides details and modifications to the handover procedure shown in fig. 3A and 3B. In particular, fig. 9 shows in a concrete way the configuration within the NG core 5 and the selection of network slices performed by the NG core 5.

The NG core 5 shown in fig. 9 includes a public Network Function (NF)51, a network function for network slice (NF for slice a) 52, a network function for network slice B (NF for slice B) 53, and a Home Subscriber Server (HSS) 54.

Note that each network element (i.e., NF) is a component of a network slice. Each network slice includes Network Functions (NFs) necessary to provide the required telecommunication services and network capabilities. Each network element (NF) is a processing function in the network and defines functional behavior and interfaces. Each network element may be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform.

Each network slice may be identified by a particular network slice specific instance ID (NSI-ID). Each Network Function (NF) may be identified by a network function id (NF id). When a common control plane network function (common CP NF) is present (or used), the NSI-ID may be a combination of the common CP NF ID and the slice specific ID (i.e., the NF ID for the selected slice).

The common NF51 shown in fig. 9 includes a control plane network function (CP NF). The common NF51 may also include a user plane network function (UP NF). The NF for slice a52 includes UP NF and may also include CP NF. Similarly, NF for slice B53 includes UP NF and may also include CP NF.

Fig. 9 shows an example in which a Slice Selection Function (SSF) is co-located with a common NF 51. However, SSFs may be located separately from the common NF 51. In this case, the common NF51 exchanges messages with SSf. The SSF selects a network slice to be associated with UE 1. For example, the SSF may associate UE1 with a default network slice. Additionally or alternatively, the SSF may slice UE1 with the network (or slice type) that has been specified by UE 1. Further, the SSF may provide a NAS Node Selection Function (NNSF) to select a CP NF (or CP NFID) corresponding to the selected slice. Note that the default network slice may be configured per Public Land Mobile Network (PLMN), per RAT, per UE usage type, per service type, or per slice type.

The allocation of one or more packet flows for UE1 to a network slice may be performed according to one of the three examples described below. In a first example, an NG system comprising an NR NB3 and NG core 5 supports bearer-based transport using per QoS class and per PDU session. As already explained, the bearers in the NG system may be referred to as NG-EPS bearers and the radio access bearers in the NG system may be referred to as NG-RABs. In a first example, each bearer is assigned to a network slice. In some embodiments, the common NF51 communicates with a particular slice user plane NF (SUNF) of the network slice selected for UE1 and establishes bearers for UE1 in that SUNF.

In a second example, similar to the first example, the NG system comprising the NR NB3 and NG core 5 supports bearer-based transport using per QoS class and per PDU session. The bearer in the NG system can be used for the transmission of multiple packet flows (e.g., PDU flows). In a second example, the NG system is configured to differentiate between data flows (e.g., PDU flows) in the bearer and perform QoS processing (e.g., dropping of packets) on a per-data-flow basis (e.g., on a per-PDU-flow basis). In a second example, each packet flow (e.g., PDU flow) for UE1 is assigned to a network slice on a per-flow basis (e.g., on a per-PDU flow basis).

In a third example, an NG system comprising an NR NB3 and an NG core 5 supports stream-based transmission of user data. In a third example, the network slice is configured per PDU session for UE 1. In other words, a set of packet flows (e.g., PDU flows) included in one PDU session is commonly allocated to the network slice.

In step 901, UE1 is Connected to LTE eNB2 and is in a Connected state (i.e., RRC _ Connected). UE1 sends network slice assistance information to LTE eNB 2. The LTE eNB2 transmits the received network slice assistance information to the EPC 4. As already explained, the network slicing assistance information may indicate, for example, the type of UE1, the type of service desired by UE1, or the acceptable delay of UE1, or any combination thereof. The network slice assistance information may be NAS information and may be included in a measurement report sent from the UE1 to the LTE eNB 2. Note that the transmission of network slice assistance information performed by UE1 may be omitted.

Step 902 corresponds to step 303 in fig. 3A. In particular, the source MME of EPC4 sends a forward redirect request message to the target control node (in this example, common NF 51) in NG core 5. The forward relocation request message includes an EPS radio access bearer (E-RAB) QoS Information Element (IE). The E-RAB QoS IE indicates the QoS (e.g., QoS Class Identifier (QCI), Assignment and Retention Priority (ARP)) of the E-RAB for UE 1. The forward relocation request message may also include network slice assistance information sent from the NAS layer of UE1 (step 901).

In step 903, the common NF51 performs authentication of the UE1, if necessary. The authentication includes confirming the slice allowed (or authorized) for the UE1 (slice authorization). In slice authorization, the common NF51 may decide/determine for each slice whether UE1 is allowed or not.

Fig. 9 shows case a (i.e., steps 904 to 906) and case B (i.e., steps 907 and 908). Either case a or case B is performed. Case a corresponds to the case where at least one network slice is allowed to the UE1 or where at least one network slice is adapted to an ongoing service performed by the UE1 or a service requested by the UE 1. In contrast, case B corresponds to the case where none of the network slices is allowed to UE1 or where none of the network slices is suitable for the ongoing service(s) performed by UE1 or the service requested by UE 1.

In case a, the common NF51 selects a slice (step 904). In other words, the common NF51 selects the network slice to be associated with UE 1. In the example shown in fig. 9, the common NF51 selects slice a for UE 1. The slice selection in step 904 may be performed per ongoing service performed by UE1 or per service requested by UE1 (e.g., EPS bearer/E-RAB, IP flow). As already described, the slice selection in step 904 may be performed by SSFs located separately from the common NF 51.

Step 905 corresponds to step 304 in fig. 3A. The common NF51 communicates with the UP NF for the slice selected by UE1 (in this example, slice a), i.e., the NF for slice a52, to create a bearer-free session in the selected slice. Note that when the NG system supports bearer-based delivery of user data and when relocation of the delivery node is not required, the common NF51 may perform a bearer modification procedure instead of the session creation procedure.

Step 906 corresponds to step 305 in fig. 3A. In particular, the common NF51 sends an NR handover request message to the target NR NB 3. The NR handover request message includes information (i.e., a slice Information Element (IE)) about a network slice selected by the common NF51 (or SSF). The slice information IE may contain, for example, an NSI ID indicating the selected network slice, an NF ID indicating the selected Network Function (NF), or a multidimensional descriptor (MDD), or any combination thereof. MDD can be provided by the UE in the RRC signaling layer and the NAS signaling layer. MDD represents tenant ID and service descriptor/slice type. The service descriptor/slice type indicates a service or use case (e.g., eMBB, mtc, URLLC, or critical communication (CriC)) associated with UE1 or with the selected network slice.

In case B, the common NF51 does not perform slice selection. Step 907 corresponds to step 304 in fig. 3A. To create a bearer-less session in a predetermined network slice, the common NF51 communicates with the UP NF of that slice. The predetermined network slice may be a network slice to which the common NF51 belongs. Note that when the NG system supports bearer-based delivery of user data and when relocation of the delivery node is not required, the common NF51 may perform a bearer modification procedure instead of the session creation procedure.

Step 908 corresponds to step 305 in fig. 3A. The common NF51 sends an NR handover request message to the target NR NB 3. The NR handover request message does not include information on network slices (i.e., slice information IE). Alternatively, the NR handover request message may include a slice information IE regarding a predetermined network slice (e.g., a network slice to which the common NF51 belongs).

Fig. 10 is an example of a procedure for handing over the UE1 from the LTE system to the NG system in the configuration example of the radio communication network shown in fig. 2. The handover procedure shown in fig. 10 provides details and modifications to the handover procedure shown in fig. 4A and 4B. In particular, fig. 10 shows in a concrete manner the configuration in the NG core 5 and the selection of network slices performed by the NG core 5.

In step 1001, UE1 is Connected to LTE eNB2 and is in a Connected state (i.e., RRC _ Connected). UE1 sends network slice assistance information to LTE eNB 2. The network slice assistance information may be NAS information and may be included in a measurement report sent from the UE1 to the LTE eNB 2. Note that the transmission of network slice assistance information performed by UE1 may be omitted.

Step 1002 corresponds to step 402 in fig. 4A. Specifically, the LTE eNB2 transmits a handover required message to the common NF51 in the NG core 5. The handover required message includes an E-RAB QoS IE. The handover required message may further include network slice assistance information transmitted from the NAS layer of the UE1 (step 1001).

The processes in steps 1003 to 1008 are similar to those in steps 903 to 908 in fig. 9.

According to the handover procedure from the LTE system to the NG system according to this embodiment, the NG core 5 can provide the target NR NB3 with information (i.e., slice information IE) about the network slice selected by the common NF51 for the UE 1. Thus, for example, the target NR NB3 can use this information about the network slice selected by the common NF51 for the UE1 to create or derive information or parameters to be included in the handover command (i.e., the transparent container (RRCConnectionReconfiguration)) and to be sent to the UE 1. Further, information on a network slice selected by the common NF51 (i.e., slice information IE) can be transmitted to the UE 1.

Third embodiment

This embodiment provides a modified example of the method for handing over the UE1 from the LTE system to the NG system according to the first embodiment. Fig. 11 shows an example of a procedure for handing over the UE1 from the LTE system to the NG system in the configuration example of the radio communication network shown in fig. 1. The handover procedure shown in fig. 11 provides details and modifications to the handover procedure shown in fig. 3A and 3B. In particular, fig. 11 shows in a concrete manner the configuration in the NG core 5 and the selection of network slices performed by the NG core 5.

Note that in the process shown in fig. 9 described above in the second embodiment, slice selection (in step 904) is performed by the common NF51 in the handover preparation phase. In contrast, in the process shown in fig. 11, slice selection (in step 1109) is performed by the common NF51 in the handover complete phase. This difference is mainly described hereinafter.

Step 1101 corresponds to step 303 in fig. 3A. In particular, the source MME of EPC4 sends a forward redirect request message to the target control node (in this example, common NF 51) in NG core 5. The forward relocation request message includes an E-RAB QoS IE.

Step 1102 corresponds to step 304 in fig. 3A. To create a bearer-less session in a predetermined network slice, the common NF51 communicates with the UP NF of that slice. The predetermined network slice may be a network slice to which the common NF51 belongs. Note that when the NG system supports bearer-based delivery of user data and when relocation of the delivery node is not required, the common NF51 may perform a bearer modification procedure instead of the session creation procedure.

Step 1103 corresponds to

steps

305 and 306 in fig. 3A. The common NF51 sends an NR handover request message to the target NR NB 3. The NR handover request message does not include information on network slices (i.e., slice information IE). Alternatively, the NR handover request message may include a slice information IE regarding a predetermined network slice (e.g., a network slice to which the common NF51 belongs).

Step 1104 corresponds to step 307 in fig. 3A. The common NF51 sends a forward relocation response message to the MME in the EPC 4.

Step 1105 is a handover execution phase and corresponds to steps 308 to 311 in fig. 3B. The handover execution phase (step 1105) includes transmitting a handover confirm message (e.g., NR RRC connection reconfiguration complete message) for NR from UE1 to the target NR NB3 (step 1106). The handover confirmation for the NR message may include network slice assistance information. The network slice assistance information may be NAS information or RRC information.

Step 1106 corresponds to step 312 in FIG. 3B. Specifically, the target NR NB3 transmits an NR handover notification message to a target control node (in this example, the common NF 51) in the NG core 5. The NR handover notification message may include network slice assistance information.

The processes in step 1108 are similar to those in step 903 in fig. 9. That is, the common NF51 performs authentication of the UE1 if necessary. The authentication includes confirming the slice allowed (or authorized) for the UE1 (slice authorization). In slice authorization, the common NF51 may decide/determine for each slice whether UE1 is allowed or not.

Fig. 11 shows only case a which is intermediate between cases a and B described above with reference to fig. 9. Case a corresponds to the case where at least one network slice is allowed to the UE1 or where at least one network slice is suitable for an ongoing service performed by the UE1 or a service requested by the UE 1. In step 1109, the common NF51 selects a slice for UE 1. The process in step 1109 is similar to that in step 904 in fig. 9.

Step 1110 corresponds to step 314 in fig. 3B. That is, the common NF51 performs the flow modification process. In particular, the common NF51 changes the transmitting node participating in the bearer-less session created in step 1102 from the UP NF of the predetermined network slice (e.g., the network slice to which the common NF51 belongs) to the UP NF of slice a selected for UE 1. For example, the common NF51 may send a create session request message to the UP NF for slice a (i.e., the NF for slice a 52) selected for UE 1. In addition, the common NF51 may transmit a delete session request message to the UP NF of a predetermined network slice (e.g., a network slice to which the common NF51 belongs).

Further, in step 1110, the transmitting node of slice a (i.e., the UP NF for the NF of slice a 52) may communicate with the edge node in EPC4 (i.e., the eP-GW) to notify the edge node in EPC4 (i.e., (e) the P-GW) of the relocation of the transmitting node or the change in RAT type due to inter-RAT HO. In particular, the transmitting node of slice a (i.e., the UP NF for the NF of slice a 52) may send a per-session (i.e., per PDN connection) modify bearer request message to the edge node in EPC 4. An edge node in EPC4 may send a modify bearer response message to the transmitting node of slice a (i.e., UP NF for NF of slice a 52).

In step 1111, the common NF51 transmits information on the network slice selected for the UE1 (i.e., slice information IE) to the UE 1. When the NF for slice a52 has a CP NF, the transmission in step 1111 may be performed by the NF for slice a 52. The slice information IE may be NAS information and may be transmitted from the target NR NB3 to the UE1 by using an RRC: DL information transfer message. Alternatively, the slice information IE may be RRC information and may be transmitted from the target NR NB3 to the UE1 by using an RRC: RRC connection reconfiguration message.

Fig. 12 is an example of a procedure for handing over the UE1 from the LTE system to the NG system in the configuration example of the radio communication network shown in fig. 2. The handover process shown in fig. 12 provides details and modifications to the handover process shown in fig. 4A and 4B and is shown in more detail. In particular, fig. 12 shows in a concrete manner the configuration in the NG core 5 and the selection of network slices performed by the NG core 5.

Step 1201 corresponds to step 402 in fig. 4A. Specifically, the LTE eNB2 transmits a handover required message to the common NF51 in the NG core 5. The handover required message includes an E-RAB QoS IE.

Step 1202 corresponds to step 403 in fig. 4A. The processes in step 1202 are similar to those in step 1102 in FIG. 11. Step 1203 corresponds to

steps

404 and 405 in fig. 4A. The processes in step 1203 are similar to those in step 1103 in fig. 11.

Step 1204 corresponds to step 406 in fig. 4B. The common NF51 sends a handover command message to the source LTE eNB 2.

Step 1205 is a handover execution stage and corresponds to steps 407 to 409 in fig. 4B. The handover execution phase (step 1205) includes transmitting a handover confirm message (e.g., NR RRC connection reconfiguration complete message) for NR from UE1 to the target NR NB3 (step 1206). The handover confirmation for the NR message may include network slice assistance information. The network slice assistance information may be NAS information or RRC information.

The processes in steps 1207 to 1211 are similar to those in steps 1107 to 1111 in fig. 11.

According to the handover procedure from the LTE system to the NG system according to this embodiment, the NG core 5 can provide the target NR NB3 with information (i.e., NSI-ID, MDD, or NFID) about the network slice selected by the common NF51 for the UE 1. Thus, for example, the target NR NB3 can create or derive information or parameters to be included in the handover command (i.e., the transparent container (RRCConnectionReconfiguration)) and to be transmitted to the UE1 using this information on the network slice selected by the common NF51 for the UE 1. Further, information on a network slice selected by the common NF51 (i.e., slice information IE) can be transmitted to the UE 1.

Fourth embodiment

This embodiment provides a method for handing over UE1 from an NG system that supports network slicing to an LTE system that does not support network slicing. Fig. 13A and 13B show an example of a procedure for handing over the UE1 from the NG system to the LTE system in the configuration example of the radio communication network shown in fig. 1. Fig. 13A shows a handover preparation phase and fig. 13B shows a handover execution phase.

In the procedure shown in fig. 13A and 13B, the source base station (i.e., NR NB 3) starts handover by transmitting a handover required message on an interface (or reference point) between the source base station (i.e., NR NB 3) and the core network (i.e., NG core 5). The procedure shown in fig. 13A and 13B may be an enhancement/evolution of "UTRAN Iu mode to E-UTRAN inter-RAT handover" in LTE. Alternatively, the procedure shown in fig. 13A and 13B may be an enhancement/evolution of "S1-based handover" with respect to MME relocation in LTE.

In step 1301, UE1 is Connected to NR NB3 and is in a Connected state (e.g., RRC _ Connected). The UE1 receives measurement configurations from the NR NB3, performs neighbor cell measurement and inter-RAT measurement (including measurement of NG-RAN cells and E-utran (lte) cells) per the received measurement configuration, and transmits a measurement report to the NR NB 3.

In step 1302, the NR NB3 determines to perform inter-RAT handover to the cell of the LTE eNB2 and transmits a handover required message to the source control node in the NG core 5. The handover required message includes an identifier of the target LTE eNB 2. Further, the handover required message may contain a handover type Information Element (IE) indicating that it is handed over from NR to LTE. For example, "NR to lte (nrtolte)", is set in the handover type IE. Alternatively, the handover required message may contain a target LTE eNB identifier Information Element (IE). The handover required message may contain a source-to-target transparent container IE.

In step 1303, the source control node in the NG core 5 determines that the type of handover is an inter-RAT handover to the LTE system based on the handover type IE or the target LTE eNB identifier included in the received handover required message. The source control node in NG core 5 selects the target MME in EPC 4. The source control node in the NG core 5 sends a forward relocation request message to the target MME to start handover resource allocation. The forward relocation request message contains the Mobility Management (MM) context and all PDU sessions valid for UE1 in the source system (i.e., NG system). Each PDN session includes a list of associated APNs and PDU flow contexts. The MM context includes information on PDU flow and security-related information. The forward relocation request message also includes information identifying one or more service data flows associated with each PDU flow context (e.g., SDF template or Traffic Flow Template (TFT)).

In step 1304, the target MME in EPC4 performs the procedure for creating a bearer-based session. In particular, the target MME determines that the packet transfer node (or gateway) for UE1 needs to be relocated and selects the target transfer node (i.e., S-GW) in the EPC 4. The target MME sends a create session request message to the target S-GW. The create session request message may also include information identifying one or more service data flows associated with each PDU flow context (e.g., SDF template or Traffic Flow Template (TFT)). This information for identifying one or more service data flows is derived from a forward relocation request message, which has been sent from a source control node in the NG core 5 to a target MME in the EPC 4. The target S-GW allocates its local resources and sends a create session response message to the target MME.

In step 1305, the target MME in the EPC4 sends a handover request message to the target LTE eNB 2.

In step 1306, upon receiving the handover request message, the target LTE eNB2 creates a UE context and a security context including information on the EPS bearer, and allocates resources. The target LTE eNB2 then sends a handover request reply message containing the target-to-source transparent container to the target MME.

In step 1307, the target MME in EPC4 sends a forward relocation response message containing the target to source transparent container to the source control node in NG core 5. The forward relocation response message may also include an address and TEID allocated for downlink data forwarding. These addresses and TEIDs may be the addresses and TEIDs of the transmitting nodes in the NG core 5 when indirect downlink forwarding is used. These addresses and TEIDs may be those of the target LTE eNB2 when direct downlink forwarding is used.

In step 1308, the source control node sends a handover command message containing the target to source transparent container to the source NR NB 3. The handover command message may also contain a list of flows subject to downlink data forwarding (e.g., a list of flows subject to data forwarding). The "flow Subject to Data forwarding list" IE includes, for example, an address and TEID for user traffic Data forwarding, and an identifier of a flow Subject to Data forwarding (e.g., PDU flow). The source NR NB3 starts data forwarding for the flows (e.g., PDU flows) specified by the "flow list subject to data forwarding" IE.

In step 1309, the source NR NB3 transmits an RRC message containing the handover command message to the UE 1. The handover command message includes a transparent container containing radio resource configuration information that has been established by the target LTE eNB2 in the preparation phase. The RRC message may be, for example, a mobility command message from the NR or an RRC connection reconfiguration message.

Upon receiving the RRC message including the handover command message, the UE1 moves to the target RAN (i.e., E UTRAN) and performs handover according to the radio resource configuration information provided by the handover command message in step 1310. That is, the UE1 establishes a radio connection with a target LTE eNB2 associated with a bearer-based network (i.e., an LTE system). In step 1311, the UE1 transmits a handover acknowledgement for the EUTRA message to the target LTE eNB2 after it has successfully synchronized with the target cell. The message in step 1311 may be an RRC connection reconfiguration complete message.

In step 1312, when the UE1 has successfully accessed the target LTE eNB2, the target LTE eNB2 notifies it to the target MME in the EPC4 by transmitting a handover notification message.

In step 1313, the target MME in EPC4 recognizes that UE1 has arrived at the target side and notifies it to the source control node in NG core 5 by sending a forward relocation complete notification message. And the source control node sends a forward relocation completion response message to the target MME.

In step 1314, the target MME in EPC4 performs the bearer modification procedure and thereby completes the inter-RAT handover procedure. For example, the target MME may transmit a per-session (i.e., per PDN connection) modify bearer request message to the (e) S-GW in the EPC 4. The modify bearer request message may contain a bearer identifier (e.g., EPS bearer ID) and also an address of the target LTE eNB2 and a Downlink (DL) TEID. The (e) S-GW in EPC4 may communicate with the edge node in NG core 5 to inform the edge node in NG core 5 of relocation of the transmitting node or change in RAT type due to inter-RAT HO. In particular, the S-GW in EPC4 may send a modify flow request message to the edge node in NG core 5 per bearer-less session (i.e., per PDU session). The edge node in the NG core 5 may send a modify flow response message to the S-GW in the EPC 4. The S-GW in EPC4 may send a modify bearer response message to the target MME.

Fig. 14A and 14B show an example of a procedure for handing over the UE1 from the NG system to the LTE system in the configuration example of the radio communication network shown in fig. 2. Fig. 14A shows a handover preparation phase and fig. 14B shows a handover execution phase.

Similarly to the process shown in fig. 13A and 13B, in the process shown in fig. 14A and 14B, the source base station (i.e., NR NB 3) starts the handover by transmitting a handover required message on the interface between the source base station (i.e., NR NB 3) and the core network (i.e., NG core 5). Similar to the procedure shown in fig. 13A and 13B, the procedure shown in fig. 14A and 14B may be an enhancement/evolution of "UTRAN Iu mode to E-UTRAN inter-RAT handover" in LTE, or may be an enhancement/evolution of "S1-based handover" with respect to MME relocation in LTE.

The processes in steps 1401 to 1405 in fig. 14A are similar to those in steps 1301 to 1307 in fig. 13A. In the process shown in fig. 14A, the illustration of

steps

1303 and 1307 shown in fig. 13A is omitted. Processes corresponding to those in

steps

1303 and 1307 are performed within the NG core 5.

The processes in steps 1406 to 1411 in fig. 14B are similar to those in steps 1308 to 1314 in fig. 13B. In the process shown in fig. 14B, the illustration of step 1313 shown in fig. 13B is omitted. Processes corresponding to those in step 1313 are executed within the NG core 5.

The detailed procedure of the handover from the NG system to the LTE system according to the present embodiment is not limited to the specific example described above. For example, the names of messages in the handover procedure are not limited to those shown in several examples described above. In several of the examples of handover procedures described above, the order of the messages may be changed and some of them may be omitted. Further, they may include one or more additional messages.

Examples of configurations of UE1, LTE eNB2, NR NB3 and core network nodes according to the embodiments described above are provided below. Fig. 15 is a block diagram showing a configuration example of the UE 1. The LTE transceiver 1501 performs analog RF signal processing related to the PHY layer of the LTE RAT to communicate with the LTE eNB 2. The analog RF signal processing performed by the LTE transceiver 1501 includes frequency up-conversion, frequency down-conversion, and amplification. The LTE transceiver 1501 is coupled to an antenna 1502 and a baseband processor 1505. That is, the LTE transceiver 1501 receives modulation symbol data (or OFDM symbol data) from the baseband processor 1505, generates a transmission RF signal, and supplies the generated transmission RF signal to the antenna 1502. Further, the LTE transceiver 1501 generates a baseband reception signal based on the reception RF signal received by the antenna 1502, and supplies the generated baseband reception signal to the baseband processor 1505.

The New Radio (NR) transceiver 1503 performs analog RF signal processing related to the PHY layer of the NG RAT to communicate with the NR NB 3. The new 5G transceiver 1503 is coupled to an antenna 1504 and a baseband processor 1505.

The baseband processor 1505 performs digital baseband signal processing (i.e., data plane processing) and control plane processing for radio communication. The digital baseband signal processing includes (a) data compression/decompression, (b) data segmentation/concatenation, (c) composition/decomposition of a transmission format (i.e., a transmission frame), (d) channel coding/decoding, (e) modulation (i.e., symbol mapping)/demodulation, and (f) generation of OFDM symbol data (i.e., a baseband OFDM signal) generated by Inverse Fast Fourier Transform (IFFT). Meanwhile, the control plane process includes layer 1 (e.g., transmission power control) and layer 2 (e.g., radio resource management and hybrid automatic repeat request (HARQ) process) and layer 3 (e.g., signaling for attachment, mobility, and packet communication) communication management.

In the case of LTE or LTE-Advanced, for example, the digital baseband signal processing performed by the baseband processor 1505 may include signal processing of a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, a Medium Access Control (MAC) layer, and a Physical (PHY) layer. Further, the control plane processing performed by the baseband processor 1505 may include processing of non-access stratum (NAS) protocol, RRC protocol, and MAC CE.

The baseband processor 1505 may include a modem processor (e.g., a Digital Signal Processor (DSP)) that performs digital baseband signal processing and a protocol stack processor (e.g., a Central Processing Unit (CPU) or a Micro Processing Unit (MPU)) that performs control plane processing. In this case, a protocol stack processor that performs control plane processing may be integrated with the application processor 1506 described below.

The application processor 1506 may also be referred to as a CPU, MPU, microprocessor, or processor core. The application processor 1506 may include multiple processors (processor cores). The application processor 1506 loads and executes a system software program (operating system (OS)) and various application programs (e.g., a communication application for collecting metering data or sensing data) from the memory 1508 or from another memory (not shown), thereby providing various functions of the UE 1.

In some embodiments, the baseband processor 1505 and the application processor 1506 may be integrated on a single chip, as represented by the dashed line (1507) in fig. 15. In other words, the baseband processor 1505 and the application processor 1506 may be implemented in a single system-on-a-chip (SoC) device 1507. SoC devices may be referred to as system large scale integrated circuits (LSIs) or chipsets.

Memory 1508 is volatile memory, non-volatile memory, or a combination thereof. Memory 1508 can include multiple memory devices that are physically independent of one another. Volatile memory is, for example, Static Random Access Memory (SRAM), dynamic ram (dram), or a combination thereof. The non-volatile memory is, for example, Mask Read Only Memory (MROM), electrically erasable programmable rom (eeprom), flash memory, a hard drive, or any combination thereof. Memory 1508 may include, for example, external memory devices accessible by baseband processor 1505, application processor 1506, and SoC 1507. Memory 1508 may include internal memory devices integrated in baseband processor 1505, application processor 1506, or SoC 1507. Further, memory 1508 may include memory in a Universal Integrated Circuit Card (UICC).

The memory 1508 may store one or more software modules (computer programs) 1509 including instructions and data for performing processing by the UE1 described in the above embodiments. In some embodiments, the baseband processor 1505 or the application processor 1506 may load a plurality of software modules 1509 from the memory 1508 and execute the loaded software modules to perform the processing of the UE1 described in the above embodiments.

Fig. 16 is a block diagram showing a configuration example of the LTE eNB2 according to the above-described embodiment. As shown in fig. 16, the LTE eNB2 includes an LTE transceiver 1601, a network interface 1603, a processor 1604, and memory 1605. The LTE transceiver 1601 performs analog RF signal processing to communicate with UEs supporting the LTE RAT, including UE 1. The LTE transceiver 1601 may include multiple transceivers. The LTE transceiver 1601 is connected to an antenna 1602 and a processor 1604. The LTE transceiver 1601 receives modulation symbol data (or OFDM symbol data) from the processor 1604, generates a transmission RF signal, and supplies the generated transmission RF signal to the antenna 1602. Further, the LTE transceiver 1601 generates a baseband reception signal based on the reception RF signal received by the antenna 1602 and supplies the signal to the processor 1604.

Network interface 1603 is used to communicate with network nodes (e.g., MME and S-GW in EPC 4). Network interface 1603 may include, for example, an IEEE 802.3 family compliant Network Interface Card (NIC).

The processor 1604 performs digital baseband signal processing (i.e., data plane processing) and control plane processing for radio communication. In the case of LTE or LTE-Advanced, the digital baseband signal processing performed by the processor 1604 may include signal processing of PDCP, RLC, MAC, and PHY layers. Further, the control plane processing performed by the processor 1604 may include processing of S1 protocol, RRC protocol, and MAC CE.

The processor 1604 may include multiple processors. The processor 1604 may include, for example, a modem processor that performs digital baseband signal processing and a protocol stack processor (e.g., a CPU or MPU) that performs control plane processing.

The memory 1605 includes a combination of volatile and non-volatile memory. Volatile memory is, for example, SRAM, DRAM, or a combination thereof. The non-volatile memory is, for example, MROM, PROM, flash memory, hard disk drive, or a combination thereof. The memory 1605 may include storage located separately from the processor 1604. In this case, the processor 1604 may access the memory 1605 through the network interface 1603 or an I/O interface (not shown).

The memory 1605 may store one or more software modules (computer programs) 1606, including instructions and data for performing processing by the LTE eNB described in the above embodiments. In some embodiments, the processor 1604 may load one or more software modules 1606 from the memory 1605 and execute the loaded software modules, thereby performing the processing of the LTE eNB described in the embodiments above.

Fig. 17 is a block diagram showing a configuration example of the NR NB3 according to the above-described embodiment. As shown in fig. 17, the NR NB3 includes a New Radio (NR) transceiver 1701, a network interface 1703, a processor 1704, and a memory 1705. The NR transceiver 1701 performs analog RF signal processing to communicate with UEs supporting the NG RAT, including UE 1. The NR transceiver 1701 may include a plurality of transceivers. NR transceiver 1701 is coupled to antenna 1702 and processor 1704. The NR transceiver 1701 receives the modulation symbol data from the processor 1704, generates a transmission RF signal, and supplies the generated transmission RF signal to the antenna 1702. Further, the NR transceiver 1701 generates a baseband reception signal based on the reception RF signal received by the antenna 1702 and supplies the signal to the processor 1704.

The network interface 1703 is used to communicate with network nodes (e.g., a control node and a transfer node in the NG core 5). The network interface 1703 may comprise, for example, a Network Interface Card (NIC) conforming to the IEEE 802.3 family.

The processor 1704 performs digital baseband signal processing (i.e., data plane processing) and control plane processing for radio communication. Processor 1704 may include multiple processors. The processor 1704 may include, for example, a modem processor that performs digital baseband signal processing and a protocol stack processor (e.g., a CPU or MPU) that performs control plane processing.

The memory 1705 includes a combination of volatile and non-volatile memory. Volatile memory is, for example, SRAM, DRAM, or a combination thereof. The non-volatile memory is, for example, MROM, PROM, flash memory, hard disk drive, or a combination thereof. The memory 1705 may include a storage device located separately from the processor 1704. In this case, the processor 1704 may access the memory 1705 through a network interface 1703 or an I/O interface (not shown).

The memory 1705 may store one or more software modules (computer programs) 1706 comprising instructions and data for performing processing by the NR NB3 described in the above embodiments. In some embodiments, processor 1704 may load one or more software modules 1706 from memory 1705 and execute the loaded software modules to perform the processing of NR NB3 described in the embodiments above.

Fig. 18 is a block diagram illustrating a configuration example of the core network node 1800 according to the above-described embodiment. The core network node 1800 is e.g. an MME in EPC4 or a control node in NG core 5. As shown in fig. 18, the core network node 1800 includes a network interface 1801, a processor 1802, and a memory 1803. The network interface 1801 is used to communicate with a network node (e.g., a RAN node or other core network node). The network interface 1801 may comprise, for example, a Network Interface Card (NIC) conforming to the IEEE 802.3 family.

The processor 1802 may be, for example, a microprocessor, an MPU, or a CPU. The processor 1802 may include a plurality of processors.

The memory 1803 includes a combination of volatile memory and non-volatile memory. Volatile memory is, for example, SRAM, DRAM, or a combination thereof. The non-volatile memory is, for example, MROM, PROM, flash memory, hard disk drive, or a combination thereof. The memory 1803 may include storage located separately from the processor 1802. In this case, the processor 1802 may access the memory 1803 through the network interface 1801 or an I/O interface (not shown).

The memory 1803 may store one or more software modules (computer programs) 1804 including instructions and data for performing processing by the core network node (e.g., an MME in EPC4 or a control node in NG core 5) described in the above embodiments. In some implementations, the processor 1802 can load one or more software modules 1804 from the memory 1803 and execute the loaded software modules to perform the processing for the core network node described in the embodiments above.

As described above with reference to fig. 15 to 18, each of the processors included in the UE1, LTE eNB2, NR NB3 and core network node in the above embodiments executes one or more programs comprising sets of instructions that cause the computer to perform the algorithms described above with reference to the figures. These programs may be stored in various types of non-transitory computer-readable media and thereby supplied to a computer. Non-transitory computer readable media include various types of tangible storage media. Examples of the non-transitory computer readable medium include magnetic recording media such as floppy disks, magnetic tapes, and hard disk drives, magneto-optical recording media such as magneto-optical disks, compact disc read only memories (CD-ROMs), CD-R, CD-R/ws, and semiconductor memories such as mask ROMs, programmable ROMs (proms), erasable proms (eproms), flash ROMs, and Random Access Memories (RAMs). These programs can be supplied to the computer by using various types of transitory computer-readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves. The transitory computer-readable medium can be used to supply the program to the computer through a wired communication line (e.g., an electric wire and an optical fiber) or a wireless communication line.

Fifth embodiment

This embodiment provides specific examples of RRC messages and control messages (i.e., S1 and NG2 messages) between the RAN and the core network described in the above embodiments.

Fig. 19A and 19B show examples of the format of mobility from EUTRA command message. In the case of handover from the LTE system to the NG system, the mobilityformeutralcommand message includes a target RAT-Type (target RAT Type) set to the purpose of "handover" and to "ngutra" corresponding to the NG RAN. Further, the mobilityfromeutralcommand message includes targetRAT-MessageContainer. the targetRAT-MessageContainer contains the rrcconnectionreconfiguration NR message created by the target NR NB 3. Also, when the targetRAT type is "otheraran" (i.e., is "utra", "geran", or "ngutra"), the mobilityparameutral command message includes nas-SecurityParamFromEUTRA.

Fig. 20 shows an example of a format of a handover required message (e.g., step 302 in fig. 3A) sent from LTE eNB2 to an MME in EPC4 over an S1 interface. The handover required message includes a handover type set to "LTE-to-NR" and a source-to-target transparent container.

Fig. 21 shows an example of a format of a handover required message (e.g., step 402 in fig. 4A) sent from LTE eNB2 to a control node (e.g., common control plane nf (ccnf)) over a NG2 interface. The handover required message includes a handover type set to "LTE-to-NR" and a source-to-target transparent container. Further, the handover required message includes CCNF UE NG2AP ID and eNB UE NG2AP ID. The CCNF UE NG2AP ID is an identifier assigned by a control node (e.g., CCNF) in the NG core 5 to identify UE1 on the NG2 interface. The eNB UENG2AP ID is an identifier assigned by LTE eNB2 to identify UE1 on the NG2 interface.

Fig. 22 to 24 show several examples of formats of source NR NB to target NR NB transparent containers contained in the handover required message. In the example shown in fig. 22, the source NR NB to target NR NB transparent container includes an RRC container and a nextgen (ng) -RAB information list. The RRC container includes an RRC handover preparation information message. The NG-RAB information list indicates a list of radio access bearers (e.g., NG-RABs) handed over from the LTE eNB2 to the NR NB 3. The format shown in fig. 22 may be used when the NG system including the NR NB3 and NG core 5 is configured to support bearer-based transport using per QoS class and per PDU session. As already described, the bearer may be configured between a pair of Network Functions (NFs), e.g. between the NR NB3 and a user plane function in the NG core 5 or between two user plane functions in the NG core 5. The bearers in the NG system may be referred to as NG-EPS bearers and the radio access bearers in the NG system may be referred to as NG-RABs.

The source NR NB to target NR NB transparent container shown in fig. 23 includes an RRC container and an NG-RAB information list as in the case of fig. 22. However, the NG-RAB information list shown in fig. 23 includes a flow information list indicating a list of packet flows (e.g., PDU flows) mapped to each NG-RAB. The format shown in fig. 23 may be used when the NG system including the NR NB3 and NG core 5 is configured to support bearer-based transport using per QoS class and per PDU session and to distinguish between packet flows (e.g., PDU flows) in a bearer to perform QoS processing (e.g., dropping of packets) on a per data flow basis (e.g., on a per PDU flow basis).

The source NR NB to target NR NB transparent container shown in fig. 24 may include one or both of a session information list and an NG-RAB information list. The format shown in fig. 24 can be used when the NG system including the NR NB3 and the NG core 5 supports both bearer-based transmission and stream-based transmission. Further, when the NG system including the NR NB3 and the NG core 5 supports only stream-based transmission, the format shown in fig. 24 may be used.

Fig. 25 shows an example of a format of an (NR) handover request message (e.g., step 305 in fig. 3A and step 404 in fig. 4A) transmitted from the NG core 5 to the NR NB3 on the NG2 interface. The (NR) handover request message includes the CCNF UE NG2AP ID. CCNF UE NG2AP ID is an identifier assigned by a control node (CCNF) in the NG core 5 to identify UE1 on the NG2 interface. Note that CCNF is only an example. That is, the names of other control plane network functions or nodes (e.g., CNF, CPF, SMF, and MMF) may be used instead of CCNF. The (NR) handover request message also includes a security context and NAS security parameters to the NG-UTRAN. The security context refers to, for example, a next hop parameter (NH) and a next hop link counter parameter (NCC). In case of handover from E-UTRAN to NG RAN (NG-UTRAN), NAS security parameters to NG-UTRAN are included in the (NR) handover request message. The security context and NAS security parameters to NG-UTRAN can be configured per network slice.

Further, as in the example shown in fig. 25, the (NR) handover request message includes a NG-RAB list to be set. The NG-RAB list to be set indicates a list of radio access bearers (e.g. NG-RABs) that should be established in the target NR NB 3. The format shown in fig. 25 may be used when the NG system including the NR NB3 and NG core 5 is configured to support bearer-based transport using per QoS class and per PDU session.

Fig. 26 shows a modified example of the (NR) handover request message. In the example shown in fig. 26, the (NR) handover request message includes a NG-RAB list to be set as in the case of fig. 25. However, the NG-RAB list to be set up shown in fig. 26 includes a flow information list indicating a list of packet flows (e.g., PDU flows) mapped to each NG-RAB. The format shown in fig. 26 may be used when the NG system including the NR NB3 and NG core 5 is configured to support bearer-based transport using per QoS class and per PDU session and to distinguish between packet flows (e.g., PDU flows) in a bearer to perform QoS processing (e.g., dropping of packets) on a per data flow basis (e.g., on a per PDU flow basis).

Fig. 27 shows another modified example of the (NR) handover request message. The (NR) handover request message shown in fig. 27 may include one or both of a list of sessions to be set and a list of NG-RABs to be set. The session list to be set includes information on one or more sessions of the UE1 to be handed over. For example, the session list to be set includes per-session slice information. The slice information shown in fig. 27 corresponds to the slice information described in the above embodiment. Further, the session list to be set includes per-Session Endpoint Identifiers (SEIDs). When the NG system including the NR NB3 and the NG core 5 supports both bearer-based transmission and stream-based transmission, the format shown in fig. 27 can be used. Further, when the NG system including the NR NB3 and the NG core 5 supports only stream-based transmission, the format shown in fig. 27 may be used.

Fig. 28 shows an example of the format of slice information. As described in detail in the first embodiment, the slice information includes an identifier of the determined (or selected) network slice for the UE1 (i.e., a network slice instance ID) and an identifier of the network function or node associated with the network slice (i.e., a network function ID). The slice information may include type information (i.e., a multi-dimensional descriptor) of the network slice. Further, the slice information may include a mobility level or a session level or both.

Fig. 29 shows an example of the format of the session endpoint ID. As detailed in the first embodiment, the session endpoint ID may be a GTP-TEID, a GRE-TEID, or an identifier of a network function or node (NF ID).

Fig. 30 shows an example of the format of an (NR) handover request reply message (e.g., step 306 in fig. 3A and step 405 in fig. 4A) sent from the NR NB3 to the NR core 5 over the NG2 interface. The (NR) handover request reply message includes a target-to-source transparent container. The target-to-source transparent container includes radio resource configuration information (e.g., radio parameters) created by the target NR NB 3. As shown in fig. 31, the target-to-source transparent container may include an RRC container containing an RRC NG-UTRA handover command message.

Further, as in the example shown in fig. 30, the (NR) handover request reply message includes an acknowledged NG-RAB list. The admitted NG-RAB list indicates a list of radio access bearers (e.g. NG-RABs) for which resources have been prepared in the target cell. The format shown in fig. 30 may be used when the NG system including the NR NB3 and NG core 5 is configured to support bearer-based transport using per QoS class and per PDU session.

Fig. 32 shows a modified example of the (NR) handover request acknowledge message. In the example shown in fig. 32, the (NR) handover request reply message includes an acknowledged NG-RAB list as in the case of fig. 30. However, the admitted NG-RAB list shown in fig. 32 includes a flow information list indicating a list of packet flows (e.g., PDU flows) mapped to each NG-RAB. The format shown in fig. 32 may be used when the NG system including the NR NB3 and NG core 5 is configured to support bearer-based transport using per QoS class and per PDU session and to distinguish between packet flows (e.g., PDU flows) in a bearer to perform QoS processing (e.g., dropping of packets) on a per data flow basis (e.g., on a per PDU flow basis).

Fig. 33 shows another modified example of the (NR) handover request acknowledge message. The (NR) handover request reply message shown in fig. 33 may include one or both of an acknowledged session list and an acknowledged NG-RAB list. The admitted session list includes information about one or more sessions of UE1 for which resources have been prepared in the target cell. The format shown in fig. 33 can be used when the NG system including the NR NB3 and the NG core 5 supports both bearer-based transmission and stream-based transmission. Further, when the NG system including the NR NB3 and the NG core 5 supports only stream-based transmission, the format shown in fig. 33 may be used.

Fig. 34 shows an example of the format of the forwarding address shown in fig. 33. The forwarding address includes one or both of information for downlink data forwarding (i.e., DL transport layer address and DL session endpoint ID) and information for uplink data forwarding (i.e., UL transport layer address and UL session endpoint ID).

Fig. 35 shows an example of a format of an S1AP handover command message (e.g., step 308 in fig. 3B) sent from an MME in EPC4 to LTE eNB2 over an S1 interface. The handover command message includes a list of E-RABs subject to forwarding. The list of E-RABs subject to forwarding indicates the E-RABs subject to data forwarding.

Further, in the case of handover from E-UTRAN to "other RAN", in other words, when the handover type IE is set to "LTE to NR (or LTE to ngutran (ltetongutran))", "LTE to UTRAN (ltetoutran)", or "LTE to geran (ltetogeran)", the S1AP handover command message includes NAS security parameters from E-UTRAN. The NAS security parameters from the E-UTRAN include security related information for inter-RAT handover from the E-UTRAN.

Fig. 36 shows an example of a formula of a NG2AP handover command message (e.g., step 406 in fig. 4B) sent from a control node (e.g., CCNF) in the NG core 5 to the LTE eNB2 over the NG2 interface. The handover command message includes a list of NE-RABs subject to forwarding. The NE-RAB list subject to forwarding indicates the NextGen E-RAB subject to data forwarding. Note that NextGen E-RABs (e.g., NE-RABs) are E-RABs established between the UE and the user plane function (e.g., CUNF) in the NG core 5 by the lte eNB enhanced to support the interface with the NG core.

OTHER EMBODIMENTS

Each of the above embodiments may be used alone, or two or more of the embodiments may be combined with each other as appropriate.

The E-URAN and NG RAN described in the above embodiments may be implemented based on a cloud radio access network (C-RAN) concept. The C-RAN is also referred to as a centralized RAN. In this case, the procedures and operations performed by each of the LTE eNB2 and the NR NB3 described in the above embodiments may be provided by a Digital Unit (DU) included in the C-RAN architecture or by a combination of the DU and a Radio Unit (RU). The DU is also called a baseband unit (BBU) or Central Unit (CU). An RU is also referred to as a Remote Radio Head (RRH), a Remote Radio Equipment (RRE), or a Distributed Unit (DU). The DU and RU may provide functions of an AS layer provided in the entire RAN while dividing them into functions provided by the DU and functions provided by the RU. For example, the DU and RU may be provided by a configuration in which a part of the AS layer (e.g., layer 2/layer 3 or sublayers thereof, or a part of the functions of the layer) is disposed in the DU and the remaining layer (or the remaining part of the layer) is disposed in the RU. That is, the procedures and operations performed by each of the LTE eNB2 and the NR NB3 described in the above embodiments may be provided by one or more radio stations (or RAN nodes).

The NR NB3 may be configured to dynamically change allocation of the AS layer or its functions to the DUs and RUs. In other words, the NR NB3 may be configured to dynamically change the AS layer between the DU and RU or the division point of its function. For example, the NR NB3 may be configured to dynamically select one of a plurality of different function splitting options. In this case, in the HO procedure from LTE to NR in the above embodiment, the NG core 5 may allocate the AS layer or its function to the DU and RU of the NR NB3 in response to receiving the forward relocation request message or the handover required message. Alternatively, the NR NB3 may determine that the AS layer or its functions are allocated to the DU and RU of the NR NB 3. The NG core 5 or the NR NB3 may select one function division option to be applied to the NR NB3 from among a plurality of predetermined function division options.

In an example, the function splitting option to be applied to the NR NB3 may be determined (or selected) based on E-RAB QoS information IE such as QCI or ARP or flow information included in the forward relocation request message or the handover required message. Additionally or alternatively, the function splitting option to be applied to the NR NB3 may be determined based on a slice created by the NG core 5 or the NR NB3 or information on the slice (i.e., slice information). Additionally or alternatively, the functionality splitting option to be applied to the NR NB3 may be determined based on network slice assistance information included in NAS information transmitted from the UE 1.

Further, in the above embodiments, the UE identifier may be included in a message transmitted between the nodes. The UE identifier is used in the handover procedure to identify the UE1 to be handed over.

More particularly, the UE identity may be a UE identifier used on an interface (e.g., Sn interface or NG2 interface, n being an integer) between the NR NB3 and a control node corresponding to the MME and included in the NG core 5. The UE identifier may be expressed as an NR NB UE SnAP ID (NR NB UE Sn application protocol identifier) or an NR NB UE NG2AP ID.

Alternatively, the UE identifier may be a UE identifier used on an interface between the NR NB3 and the LTE eNB2 (e.g., an Xn interface, n being an integer). The UE identifier may be expressed as an NR NB UE XnAP ID.

Alternatively, the UE identifier may be a UE identifier used on an interface (e.g., Sm interface, m is an integer) between the MME in the EPC4 and a control node corresponding to the MME and included in the NG core 5. The UE identifier may be expressed as an eMME UE SmAP ID.

Alternatively, the UE identifier may be a UE identifier used on an interface (e.g., Sl interface, l is an integer) between the LTE eNB2 and a control node corresponding to the MME and included in the NG core 5 and allocated by the control node. The UE identifier may be expressed as an eMME UE SlAP ID.

Further, these UE identifiers may be communicated between nodes during a handover procedure. Note that Sn, NG2, Sm, Sl, and Xn used to identify the respective interfaces are merely examples and may be expressed by different symbols.

Further, the above-described embodiments are only examples of applications of the technical ideas obtained by the inventors. The technical ideas are not limited to the above-described embodiments and various modifications may be made thereto.

For example, all or part of the embodiments disclosed above can be described as, but not limited to, the following supplementary notes.

(supplementary notes 1)

A target Radio Access Network (RAN) node associated with a second network, the target RAN node comprising:

at least one memory; and

at least one processor coupled to the at least one memory and configured to, during handover of a radio terminal from a first network to the second network:

receiving slice information on a network slice that is included in the second network and to which the radio terminal is to be connected, from a core network;

upon receiving the slice information, creating radio resource configuration information to be used by the radio terminal in the second network after the handover; and

transmitting the radio resource configuration information to the radio terminal through the first network.

(supplementary notes 2)

The target RAN node described in supplementary note 1, wherein,

the at least one processor is configured to:

receiving a handover request message from the core network, the handover request message requesting handover of the radio terminal from the first network to the second network and including the slice information on the network slice, the network slice being included in the second network and the radio terminal to be connected to the network slice; and

transmitting a handover request reply message to the core network in response to the handover request message, the handover request reply message including a target-to-source transparent container, wherein,

the target-to-source transparent container contains the radio resource configuration information that is derived from the slice information and is to be forwarded through the core network to a source RAN node associated with the first network.

(supplementary notes 3)

The target RAN node described in

supplementary note

1 or 2, wherein the slice information includes: (a) identification information of the network slice selected for the radio terminal; (b) type information of the network slice selected for the radio terminal; or (c) identification information of a network node or network function associated with the network slice selected for the radio terminal; or any combination thereof.

(supplementary notes 4)

The target RAN node described in any of supplementary notes 1 to 3, wherein the slice information includes at least one of a mobility level and a session level supported by the network slice selected for the radio terminal.

(supplementary notes 5)

The target RAN node described in any of supplementary notes 1 to 4, wherein the at least one processor is configured to determine whether to accept a bearer or a flow for each bearer or each flow of the radio terminal based on the slice information.

(supplementary notes 6)

The target RAN node described in any of supplementary notes 1 to 5, wherein the at least one processor is configured to determine whether it is possible to accept each network slice based on the slice information.

(supplementary notes 7)

A source Radio Access Network (RAN) node associated with a first network, the source RAN node comprising:

at least one memory; and

at least one processor coupled to the at least one memory and configured to, during handover of a radio terminal from the first network to a second network:

transmitting the handover-related message to the radio terminal.

(supplementary notes 8)

The source RAN node described in supplementary note 7, wherein the at least one processor is configured to:

transmitting a handover required message for starting the handover of the radio terminal from the first network to the second network to the core network;

receiving a handover command message from the core network containing a target-to-source transparent container containing radio resource configuration information created by a target RAN node associated with the second network, the radio resource configuration information being necessary for the radio terminal to establish a radio connection associated with the network slice that is included in the second network and to which the radio terminal is to be connected; and

transmitting a mobility command message to the radio terminal, the mobility command message containing the radio resource configuration information and indicating the handover to the second network.

(supplementary notes 9)

A radio terminal, comprising:

at least one memory; and

at least one processor coupled to the at least one memory and configured to receive, during a handover from a first network to which the radio terminal is connected to a second network, a handover-related message from a Radio Access Network (RAN) node of the first network, the handover-related message containing at least one of slice information regarding a network slice in the second network and radio resource configuration information based on the network slice in the second network.

(supplementary notes 10)

The radio terminal described in supplementary note 8, wherein the at least one processor is configured to:

receiving, from the RAN node, a mobility command message indicating the handover from the first network to the second network, the mobility command message containing the radio resource configuration information created by a target RAN node associated with the second network, the radio resource configuration information necessary for the radio terminal to establish the radio connection associated with the network slice that is included in the second network and to which the radio terminal is to be connected; and

establishing a radio connection with the target RAN node associated with the second network using the radio resource configuration information.

(supplementary notes 11)

A core network node, comprising:

at least one memory; and

at least one processor coupled to the at least one memory and configured to send, to a target Radio Access Network (RAN) node associated with a second network, slice information regarding a network slice that is included in the second network and to which a radio terminal is to be connected, during handover of the radio terminal from a first network to the second network.

(supplementary notes 12)

The core network node described in supplementary note 11, wherein the at least one processor is configured to:

receiving a handover required message from a source RAN node associated with the first network for initiating the handover of the radio terminal from the first network to the second network; and

transmitting a handover request message to the target RAN node in response to the handover required message, the handover request message including the slice information and requesting handover of the radio terminal from the first network to the second network.

(supplementary notes 13)

The core network node described in supplementary note 12, wherein the at least one processor is further configured to:

receiving a handover request acknowledgement message from the target RAN node including a target-to-source transparent container including radio resource configuration information derived from the slice information; and

sending a handover command message to the source RAN node including the target-to-source transparent container.

(supplementary notes 14)

The target RAN node described in any one of supplementary notes 11 to 13, wherein the slice information includes: (a) identification information of the network slice selected for the radio terminal; (b) type information of the network slice selected for the radio terminal; or (c) identification information of a network node or network function associated with the network slice selected for the radio terminal; or any combination thereof.

(supplementary notes 15)

The target RAN node described in any of supplementary notes 11 to 14, wherein the slice information includes at least one of a mobility level and a session level supported by the network slice selected for the radio terminal.

(supplementary notes 16)

A method in a target Radio Access Network (RAN) node associated with a second network, the method comprising:

during handover of a radio terminal from a first network to said second network,

upon receiving the slice information, creating radio resource configuration information to be used by the radio terminal after the handover in the second network; and

(supplementary notes 17)

A method in a source Radio Access Network (RAN) node associated with a first network, the method comprising:

during handover of a radio terminal from the first network to a second network,

transmitting the handover-related message to the radio terminal.

(supplementary notes 18)

A method in a radio terminal, the method comprising:

during handover from a first network to which the radio terminal is connected to a second network, receiving a handover-related message from a Radio Access Network (RAN) node of the first network, the handover-related message including at least one of slice information regarding a network slice in the second network and radio resource configuration information based on the network slice in the second network.

(supplementary notes 19)

A method in a core network node, the method comprising:

during handover of a radio terminal from a first network to a second network, transmitting slice information to a target Radio Access Network (RAN) node associated with the second network regarding a network slice that is included in the second network and to which the radio terminal is to be connected.

(supplementary notes 20)

A program for causing a computer to perform a method in a target Radio Access Network (RAN) node associated with a second network, wherein the method comprises:

transmitting the radio configuration information to the radio terminal over the first network.

(supplementary notes 21)

A program for causing a computer to perform a method in a source Radio Access Network (RAN) node associated with a first network, wherein the method comprises:

during handover of a radio terminal from the first network to a second network,

receiving a handover-related message from the second network, the handover-related message containing at least one of slice information on a network slice that is included in the second network and to which the radio terminal is to be connected and radio resource configuration information based on the network slice in the second network from the second network; and

transmitting the handover-related message to the radio terminal.

(supplementary notes 22)

A program for causing a computer to execute a method in a radio terminal, wherein the method comprises:

(supplementary notes 23)

A program for causing a computer to execute a method in a core network node, wherein the method comprises:

The present application is based on and claims the right to priority of Japanese patent application number 2016-158280, filed on 10.8.2016, the disclosure of which is incorporated herein by reference in its entirety.

Claims

1. A target radio access network, RAN, node associated with a second network, the target RAN node comprising:

at least one memory; and

at least one processor coupled to the at least one memory and configured to, during handover of a radio terminal from a first network that does not support network slicing to the second network that supports network slicing:

receiving, from a core network node associated with the second network, a handover request message requesting the handover of the radio terminal and including slice information on a network slice that is included in the second network and to which the radio terminal is to be connected;

creating radio resource configuration information to be used by the radio terminal in the second network after the handover based on the slice information; and

transmitting a handover request acknowledgement message including the radio resource configuration information to the core network node to allow transmission of the radio resource configuration information by the core network node to the radio terminal over the first network.

2. The target RAN node of claim 1, wherein

The at least one processor is configured to:

transmitting the handover request reply message to the core network in response to the handover request message, the handover request reply message including a target-to-source transparent container, wherein

3. The target RAN node of claim 1 or 2, wherein the slice information comprises: (a) identification information of the network slice selected for the radio terminal; (b) type information of the network slice selected for the radio terminal; or (c) identification information of a network node or network function associated with the network slice selected for the radio terminal; or any combination thereof.

4. The target RAN node of claim 1 or 2, wherein the slice information comprises at least one of a mobility level and a session level supported by the network slice selected for the radio terminal.

5. The target RAN node of claim 1 or 2, wherein the at least one processor is configured to determine, for each bearer or each flow of the radio terminal, whether to accept a bearer or a flow based on the slice information.

6. The target RAN node of claim 1 or 2, wherein the at least one processor is configured to determine whether it is possible to accept each network slice based on the slice information.

7. A source radio access network, RAN, node associated with a first network that does not support network slicing, the source RAN node comprising:

at least one memory; and

at least one processor coupled to the at least one memory and configured to, during handover of a radio terminal from the first network that does not support network slicing to a second network that supports network slicing:

receiving, from a target RAN node through a core network node associated with the second network, radio resource configuration information to be used by the radio terminal in the second network after the handover, the radio resource configuration information being created by the target RAN node based on slice information received from the core network node, the slice information relating to a network slice that is included in the second network and to which the radio terminal is connected; and

transmitting the radio resource configuration information to the radio terminal.

8. A radio terminal, comprising:

at least one memory; and

at least one processor coupled to the at least one memory and configured to, during handover from a first network that does not support network slicing to a second network that supports network slicing, to which the radio terminal is connected:

receiving, from a source Radio Access Network (RAN) node of the first network, radio resource configuration information to be used by the radio terminal in the second network after the handover, the radio resource configuration information created by a target RAN node associated with the second network based on slice information received from a core network node associated with the second network, the slice information relating to network slices supported by the second network, the radio resource configuration information communicated from the target RAN node to the source RAN node by the core network node;

using the radio resource configuration information to connect the network slices.

9. A core network node associated with a second network supporting network slicing, the core network node comprising:

at least one memory; and

determining a network slice that is included in the second network and to which the radio terminal is to be connected after the handover; and

sending a handover request message requesting the handover of the radio terminal and including slice information on the network slice to a target radio access network, RAN, node associated with the second network;

receiving, from the target RAN node, a handover request acknowledgement message including radio resource information; and

forwarding the radio resource information to the radio terminal over the first network.

10. The core network node of claim 9, wherein the at least one processor is configured to:

transmitting the handover request message including the slice information to the target RAN node in response to the handover required message.

11. A method performed by a target radio access network, RAN, node associated with a second network, the method comprising:

during handover of a radio terminal from a first network that does not support network slicing to said second network that supports network slicing,

receiving, from a core network node associated with the second network, a handover request requesting the handover of the radio terminal and including slice information on a network slice that is included in the second network and to which the radio terminal is to be connected;

12. A method performed by a source radio access network, RAN, node associated with a first network that does not support network slicing, the method comprising:

during handover of a radio terminal from said first network not supporting network slicing to a second network supporting network slicing,

13. A method performed by a radio terminal, the method comprising:

during handover from a first network that does not support network slicing and to which the radio terminal is connected to a second network that supports network slicing:

receiving, from a source Radio Access Network (RAN) node of the first network, radio resource configuration information to be used by the radio terminal in the second network after the handover, the radio resource configuration information created by a target RAN node associated with the second network based on slice information received from a core network node associated with the second network, the slice information relating to network slices supported by the second network, the radio resource configuration information communicated from the target RAN node to the source RAN node by the core network node; and

14. A method performed by a core network node associated with a second network supporting network slicing, the method comprising:

determining, during handover of a radio terminal from a first network that does not support network slicing to the second network that supports network slicing, a network slice that is included in the second network and to which the radio terminal is to be connected after the handover; and

15. A non-transitory computer-readable medium storing a program for causing a computer to execute the method according to any one of claims 11 to 14.