Patent Description:
This section is intended to provide a background or context to the invention disclosed below. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived, implemented or described. Therefore, unless otherwise explicitly indicated herein, what is described in this section is not prior art to the description in this application and is not admitted to be prior art by inclusion in this section. Abbreviations that may be found in the specification and/or the drawing figures are defined below, at the beginning of the detailed description section.

A handover is performed to transfer operation of a user equipment (UE) from one base station to another in a cellular network. We will use the term base station (BS) herein to refer to a next generation Node B (gNB) in a <NUM> New Radio (NR) system or to any access point in general. It is also noted that in NR, a base station may also be referred to as a Radio Access Network (RAN) node and comprise a gNB, as described below. Whenever there is a handover of a UE from one base station to another, there is usually an interruption, if only for a relatively short time period.

Several solutions have been proposed in RAN2 #<NUM> for reducing the service interruption to <NUM> (zero milliseconds) or close to <NUM> during handover (HO) in LTE systems. Similar solutions may be adopted for NR systems. See the following documents: <NPL>; <NPL>; and <NPL>. All these assume that the UE is equipped with two transceivers (TRXs), connects simultaneously to source and target BSs during the HO, and/or continues to exchange data communication with the source BS after receiving the handover command. That is, during the HO, the UE first establishes the radio link with respect to the target BS before releasing the link of the source BS, which can help to achieve <NUM> or close to <NUM> interruption time.

As such, all the proposed techniques fall under the umbrella of "make-before-break" methods, although the naming of each specific solution stated in the documents cited above may differ, such as a "split-bearer" solution, or a "non-split bearer" solution. These make-before-break methods can still be improved.

<CIT> discloses a handover of a wireless terminal between different Radio Access Technologies (RATs). The Handover Preparation Required message that is sent from the source cell comprises a Handover Type Information Element, for example LTE to NR.

<NPL>) discloses a solution for slice rejection handling in Xn handover. A source NG-RAN node sends a Handover Request to a target NG-RAN node with a PDU Session List information. Slice ID (S-NSSAI) is included in the parameters of each PDU Session. The target RAN determines which PDU sessions are admitted and allocated DRBs. The Target NG-RAN node sends a Hanover Request Ack to source NG-RAN node with the admitted PDU session list and not admitted PDU session list.

<NPL>) discloses a source eNB initiating a Hanover procedure by sending a Handover Request message to the target eNB. The target eNB reserves necessary resources, and sends an Handover Request Ack message back to the source eNB. The target eNB includes the E-RABs for which resources have been prepared at the target cell in the E-RABs Admitted List IE, and the E-RABs which have not been admitted in the E-RABs Not Admitted List IE with an appropriate cause value. The target eNB may transmit an enhanced handover indication to the source eNB.

The exemplary embodiments herein describe techniques for enhanced mobility in cellular deployments with network slicing. Additional description of these techniques is presented after a system into which the exemplary embodiments may be used is described. For ease of reference, this disclosure is divided into sections.

Turning to <FIG>, this figure shows a block diagram of one possible and non-limiting exemplary system in which the exemplary embodiments may be practiced. A user equipment (UE) <NUM>, radio access network (RAN) nodes <NUM>-<NUM> and <NUM>-<NUM>, and network element (or elements) <NUM> are illustrated. In <FIG>, a user equipment (UE) <NUM> is in wireless communication with a wireless network <NUM>. The wireless network <NUM> is a cellular network. A UE is a wireless, typically mobile device that can access a wireless network. The UE <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more transceivers (TRXs) <NUM> interconnected through one or more buses <NUM>. In this case, there are N transceivers <NUM>-<NUM> through <NUM>-N, where N is, e.g., typically two, though N is not limited to two. The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The UE <NUM> includes a mobility module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The mobility module <NUM> may be implemented in hardware as mobility module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The mobility module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the mobility module <NUM> may be implemented as mobility module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. The one or more memories <NUM> and the computer program code <NUM> may be configured to, with the one or more processors <NUM>, cause the user equipment <NUM> to perform one or more of the operations as described herein. The UE <NUM> communicates with RAN node <NUM>-<NUM> via a wireless link <NUM>-<NUM> and communicates with RAN node <NUM>-<NUM> via wireless link <NUM>-<NUM>.

The RAN nodes <NUM>-<NUM> and <NUM>-<NUM> are base stations that provide access by wireless devices such as the UE <NUM> to the wireless, cellular network <NUM>. For simplicity, only an exemplary implementation of RAN node <NUM>-<NUM> will be described, and it is assumed that RAN node <NUM>-<NUM> is similar. The RAN node <NUM>-<NUM> may be, for instance, a base station for <NUM>, also called New Radio (NR). In <NUM>, the RAN node <NUM>-<NUM> may be a NG-RAN node, which is defined as either a gNB or an ng-eNB. A gNB is a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to a 5GC (e.g., the network element(s) <NUM>). The ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC. The NG-RAN node may include multiple gNBs, which may also include a central unit (CU) (gNB-CU) <NUM> and distributed unit(s) (DUs) (gNB-DUs), of which DU <NUM> is shown. Note that the DU may include or be coupled to and control a radio unit (RU). The gNB-CU is a logical node hosting RRC, SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected with the gNB-DU. The F1 interface is illustrated as reference <NUM>, although reference <NUM> also illustrates a link between remote elements of the RAN node <NUM>-<NUM> and centralized elements of the RAN node <NUM>-<NUM>, such as between the gNB-CU <NUM> and the gNB-DU <NUM>. The gNB-DU is a logical node hosting RLC, MAC and PHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU. One gNB-CU supports one or multiple cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface <NUM> connected with the gNB-CU. Note that the DU <NUM> is considered to include the transceiver <NUM>, e.g., as part of an RU, but some examples of this may have the transceiver <NUM> as part of a separate RU, e.g., under control of and connected to the DU <NUM>. The RAN node <NUM>-<NUM> may also be an eNB (evolved NodeB) base station, for LTE (long term evolution), or any other suitable base station.

The RAN node <NUM>-<NUM> includes one or more processors <NUM>, one or more memories <NUM>, one or more network interfaces (N/W I/F(s)) <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>.

The RAN node <NUM>-<NUM> (and <NUM>-<NUM>) includes a mobility module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The mobility module <NUM> may be implemented in hardware as mobility module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The mobility module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the mobility module <NUM> may be implemented as mobility module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the RAN node <NUM> to perform one or more of the operations as described herein. Note that the functionality of the mobility module <NUM> may be distributed, such as being distributed between the DU <NUM> and the CU <NUM>, or be implemented solely either in the DU <NUM> or the CU <NUM>.

Two or more RAN nodes <NUM> (such as RAN nodes <NUM>-<NUM>, <NUM>-<NUM>) communicate using, e.g., link <NUM>. The link <NUM> may be wired or wireless or both and may implement, e.g., an Xn interface for <NUM>, an X2 interface for LTE, or other suitable interface for other standards. The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like.

The wireless, cellular network <NUM> may include a network element or elements <NUM> that may include core network functionality, and which provides connectivity via a link or links <NUM> with a further network, such as a telephone network and/or a data communications network (e.g., the Internet). Such core network functionality for <NUM> may include access and mobility management function(s) (AMF(s)) and/or user plane functions (UPF(s)) and/or session management function(s) (SMF(s)). Such core network functionality for LTE may include MME (Mobility Management Entity)/SGW (Serving Gateway) functionality. These are merely exemplary functions that may be supported by the network element(s) <NUM>, and note that both <NUM> and LTE functions might be supported. The RAN nodes <NUM> are coupled via links <NUM> to a network element <NUM>. The link <NUM> may be implemented as, e.g., an NG interface for <NUM>, or an S1 interface for LTE, or other suitable interface for other standards. The network element <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more network interfaces (N/W I/F(s)) <NUM>, interconnected through one or more buses <NUM>. There is a mobility module (MM) <NUM>, which may be implemented as hardware (illustrated by MM <NUM>-<NUM>) in circuitry or by software (illustrated by MM <NUM>-<NUM> in the computer program code <NUM>), or both. The one or more memories <NUM> include computer program code (CPC) <NUM>, which includes a mobility module (MM) <NUM>-<NUM> in some applications. The one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the network element <NUM> to perform one or more operations described herein.

It is noted that description herein indicates that "cells" perform functions, but it should be clear that the base station that forms the cell will perform the functions. The cell makes up part of a base station. That is, there can be multiple cells per base station. For instance, there could be three cells for a single carrier frequency and associated bandwidth, each cell covering one-third of a <NUM> degree area so that the single base station's coverage area covers an approximate oval or circle. Furthermore, each cell can correspond to a single carrier and a base station may use multiple carriers. So if there are three <NUM> degree cells per carrier and two carriers, then the base station has a total of <NUM> cells. In the examples below, a source RAN node <NUM>-<NUM> or target RAN node <NUM>-<NUM> may be referred to as cells, since one typical application is a handover from a cell of a source RAN node <NUM>-<NUM> to a cell of a target RAN node <NUM>-<NUM>.

The computer readable memories <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer readable memories <NUM>, <NUM>, and <NUM> may be means for performing storage functions. The processors <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples. The processors <NUM>, <NUM>, and <NUM> may be means for performing functions, such as controlling the UE <NUM>, RAN nodes <NUM>, and other functions as described herein.

Having thus introduced one suitable but non-limiting technical context for the practice of the exemplary embodiments of this invention, the exemplary embodiments will now be described with greater specificity.

For generality, we use the expression "enhanced HO" to refer to any handover method that seeks to achieve <NUM> or close to <NUM> interruption by leveraging the existence of the two TRXs <NUM> at the UE side, the ability for the UE to communicate simultaneously to source and target BSs, and/or for the UE to exchange (e.g., transmit and receive) user and control data with the source BS after the source BS has sent the HO command to the UE and the UE has received the command. In general we refer to any scheme reducing the interruption time in comparison to what can be achieved with legacy mechanisms. The genuine "<NUM>" can be achieved only when a sort of "multi-connectivity" is employed. "Close to <NUM>" implies that we reduce the interruption to few milliseconds, the time needed, e.g., to retune the RF and the like but without the need to support necessarily multiple links simultaneously (i.e., true <NUM>).

Certain embodiments herein concern the new Rel-<NUM> enhanced handover in a cellular deployment with network slicing. In the following, we provide an overview of the non-split bearer techniques discussed in <NPL>, as one exemplary implementation for enhanced HO in Rel. However, this does not limit the applicability of the techniques herein to any enhanced mobility solution as discussed above.

These techniques build on top of a baseline HO where the source BS (e.g., RAN node <NUM>-<NUM>) and UE <NUM> continue the radio communication after the transmission of the HO command. The connection between the source BS and UE <NUM> is released after the UE can send or has received Packet Data Convergence Protocol (PDCP) packets from the target BS (e.g., RAN node <NUM>-<NUM>).

The proposed techniques also build on top of the make-before-break solution which was standardized in Rel-<NUM>. See: <NPL>), Overall description; Stage <NUM> (Release <NUM>). However, this legacy set of techniques assumes only a single transceiver (TRX) at the UE side and this limitation leaves a residual HO interruption of ~<NUM> (about <NUM> milliseconds). These techniques shall go beyond the Rel-<NUM> solution, e.g., by assuming two TRXs.

For clarity, <FIG> shows one exemplary implementation of the non-split bearer techniques. In particular, <FIG> is a signaling diagram illustrating <NUM> (zero milliseconds) interruption time using a non-split bearer technique. The entities involved are the UE <NUM>, a source BS <NUM>-<NUM>, a target BS <NUM>-<NUM>, an MME/AMF <NUM>-<NUM> and a serving gateway/UPF(s) <NUM>-<NUM>. For ease of reference, the RAN nodes <NUM> are referred to as BSs herein.

Steps <NUM>-<NUM> are the same as in a baseline HO described in <NPL>), Overall description; Stage <NUM> (Release <NUM>). Step <NUM> is a measurement control signaling, followed by packet data communication. Step <NUM> is a signaling of measurement reports, and step <NUM> is a handover decision. Step <NUM> is a handover request, step <NUM> is an admission control method, and step <NUM> is a handover request Ack (acknowledgement). The Handover Request message in step <NUM> includes an indication for make-before-break from source cell to the target cell. The target BS <NUM>-<NUM> prepares the HO command according to that indication from the source cell.

In step <NUM>, the handover (HO) command sent by the source BS <NUM>-<NUM> can contain an indication of (e.g., enhanced) make-before-break to inform the UE that the source BS <NUM>-<NUM> will continue the transmission/reception of PDCP Protocol Data Units (PDUs). After the HO command, there are two packet data signaling sessions.

The UE <NUM> performs access to the target cell in steps <NUM>-<NUM> while receiving and transmitting PDCP Protocol PDUs from and to the source BS <NUM>-<NUM>. Step <NUM> involves synchronization signaling, step <NUM> involves UL allocation and timing advance for the UE, and step <NUM> involves RRC Reconfiguration Complete signaling. There are four sessions of packet data signaling after step <NUM>. After step <NUM>, the UE <NUM> distinguishes the PDCP PDUs between source and target BSs that can be ciphered using different security keys. See step <NUM>.

Having received or being able to receive PDCP PDUs from target BS <NUM>-<NUM>, the UE detaches from the source BS <NUM>-<NUM>. See step <NUM>.

It is up to network implementation when the source BS <NUM>-<NUM> sends Sequence Number (SN) Status Transfer message in step <NUM> to the target BS <NUM>-<NUM>, e.g., upon detecting a missing Medium Access Control (MAC) Hybrid Automatic Repeat Request (HARQ) / or Radio Link Control (RLC) Automatic Repeat Request (ARQ) feedback. For lossless HO, the SN Status Transfer message in step <NUM> provides the Sequence Numbers (SNs) of next missing downlink and uplink packets that the target BS shall transmit or receive.

A path switch from source BS to target BS is executed and completed in steps <NUM>-<NUM>. In step <NUM>, a Path Switch Request signaling is performed, and in step <NUM>, a path switch related core network internal signaling and actual DL switch is performed in the serving gateway/UPF(s) <NUM>-<NUM>. This is followed by an end marker routing, then two packet data sessions between the UE and target BS and between target BS and serving gateway/UPF(s). In step <NUM>, there is a Path Switch Request Ack signaling and in step <NUM>, a UE Context Release message.

It is noted that the hardware and RF design of the UE should allow simultaneous transmission and reception ("two TRXs") to two intra-frequency/inter-frequency cells. While the techniques of <FIG> are useful, these could still be improved, particularly for network slicing implementations.

Network slicing is a key <NUM> feature to support different services using the same underlying mobile network infrastructure. See: <NPL>), System Architecture for the <NUM> system (Release <NUM>). This technical standard defines a network slice as the following: "A logical network that provides specific network capabilities and network characteristics. " A network slice instance is defined as the following: "A set of Network Function instances and the required resources (e.g. compute, storage and networking resources) which form a deployed Network Slice".

Network slices can differ either in their service requirements like Ultra-Reliable Low Latency Communication (URLLC) and enhanced Mobile Broadband (eMBB), or in the tenant that provides those services. 3GPP TS <NUM>, section <NUM>. <NUM>, states the following: "Network slices may differ for supported features and network functions optimisations, in which case such Network Slices may have e.g. different S-NSSAIs with different Slice/Service Types (see clause <NUM>. " From a network management perspective, different network slices can also have different key performance indicator targets and optimization goals. For example, for a URLLC service, any kind of HO failures, outages, and service interruption would be critical and should be avoided as much as possible. However, for an eMBB service, HO failures and service interruption would be relatively less critical than in URLLC, and therefore the eMBB service has more relaxed requirements.

A network slice is identified via the S-NSSAI (Single-Network Slice Selection Assistance Information). According to 3GPP TS <NUM>, section <NUM>. <NUM>: "An S-NSSAI is comprised of A Slice/Service type (SST), which refers to the expected Network Slice behaviour in terms of features and services; A Slice Differentiator (SD), which is optional information that complements the Slice/Service type(s) to differentiate amongst multiple Network Slices of the same Slice/Service type. " Current 3GPP specifications (see 3GPP TS <NUM>) allow a UE to be simultaneously connected and served by at most eight S-NSSAIs. On other hand, there is no limit on the number of network slices that each cell may support: The cell may support tens or even hundreds of S-NSSAIs.

The S-NSSAI may include both Slice Service Type (SST) and Slice Differentiator (SD) field with a total length of <NUM> bits or include only SST field part in which case the length of S-NSSAI is <NUM> bits only, see <FIG>.

The SST field may have standardized and non-standardized values. Values <NUM> (zero) to <NUM> belong to the standardized SST range and they are defined in 3GPP TS <NUM>. For instance, an SST value of <NUM> (one) may indicate that the slice is suitable for handling of <NUM> eMBB, <NUM> (two) for handling of URLLC, and the like. SD is operator-defined only.

Current LTE Rel. <NUM> specification support for make-before-break handover is slice agnostic and is not sufficient for mobile network deployments with network slicing due to the following problems.

Rel-<NUM> signaling (as described also below) from source cell to target cell for handover preparation uses RRC Context IE to indicate the need for make-before-break handover for a UE. In scenarios, where a UE <NUM> is connected to multiple slices at the time of a handover request, the current signaling is ambiguous in the sense that one cannot tell whether make-before-break handover will be applicable to all the connected slices or not. The connected slices are those slices with which the UE is actively exchanging user data and/or control data.

The enhanced HO discussed for Rel. <NUM> may require that the source cell continues to transfer data to the UE even after the HO command is sent to the UE, i.e., from step <NUM> until step <NUM> in <FIG>. As such, the number of configured Data Radio Bearers (DRBs) for each PDU session (pertaining possibly to a network slice) has to be doubled as the UE needs to exchange user data simultaneously with source and target BS, i.e., after step <NUM> in <FIG>. Therefore, for efficient resource utilization, it is important that the enhanced HO is used only for the services/slices that really need such a feature. The make-before-break indication in the HO request message of Rel. <NUM> (which may be replaced by new indication for enhanced HO in Rel. <NUM>) from the source cell to target cell needs to be made flexible so that the source cell can freely choose for which services/slices the cell wants to support the enhanced HO even for the same UE.

The source cell might want to support the enhanced HO only for a subset of services/slices currently used by the UE due to following reasons.

One problem with current specifications for make-before-break (Rel. <NUM>) is that these are very rigid and do not allow the source cell to apply different policies for different simultaneously connected services/slices of a UE based on the cell's resource utilization and optimization goals.

In the following, we capture the 3GPP specifications of LTE Rel. <NUM> and NR that are relevant for supporting the enhanced HO of the exemplary embodiments in the context of network slicing. For simplification, the text below does not show the full messages but only the parts that are relevant for the network slicing aspects.

The handover preparation procedure, which is described in<NPL>), NG-RAN; Xn Application Protocol (XnAP) (Release <NUM>) is shown in <FIG>. There is a source NG-RAN node <NUM>-<NUM> and a target NG-RAN node <NUM>-<NUM>, a handover request message from the source RAN node <NUM>-<NUM> to the target RAN node <NUM>-<NUM>, and a handover request acknowledge message from the target RAN node <NUM>-<NUM> to the source RAN node <NUM>-<NUM>.

The HANDOVER REQUEST message is defined in 3GPP TS <NUM> V15. <NUM>, Section <NUM>. <NUM>, and this message is sent by the source NG-RAN node to the target NG-RAN node to request the preparation of resources for a handover. The HANDOVER REQUEST message is shown in <FIG>. The columns are as follows: the IE (information element) name is shown in the leftmost column; this is followed by the presence (e.g., M for mandatory or O for optional); the range, which may include an indication of how many values there might be; the IE type and reference, where the reference is to another section of the TS and the IE type can be, e.g., OCTET STRING; semantics description, which can provide a description of the semantics; criticality, which indicates whether the item is critical for operation; and assigned criticality.

In this example, the IE of PDU session resources to be setup list <NUM> and the RRC context <NUM> are entries that might be used to convey information in exemplary embodiments herein, as described below. The semantics description of the PDU session resources to be setup list <NUM> is the following: "Similar to NG-C signalling, containing UL tunnel information per PDU Session Resource; and in addition, the source side QoS flow ⇔ DRB mapping". The semantics description of the RRC context <NUM> is the following: "Either includes the HandoverPreparationlnformation message as defined in subclause <NUM>. of TS <NUM> [<NUM>], if the target NG-RAN node is an ng-eNB, or the HandoverPreparationlnformation message as defined in subclause <NUM>. <NUM> of TS <NUM> [<NUM>], if the target NG-RAN node is a gNB.

<FIG> is a table illustrating configuration of a PDU Session Resources To Be Setup List IE <NUM> from <FIG>. This IE contains PDU session resource related information used at UE context transfer between NG-RAN nodes. This IE <NUM> has a PDU session Resources To Be Setup Item <NUM>, which may be used in certain exemplary embodiments here, as described below. See, e.g., <NPL>), NG-RAN; Xn Application Protocol (XnAP) (Release <NUM>).

The HandoverPreparationlnformation message in the RRC Context <NUM> is defined in 3GPP TS <NUM> V15. <NUM> Section <NUM>. <NUM> and is illustrated in <FIG>. This message is used to transfer the E-UTRA RRC information used by the target eNB during handover preparation, including UE capability information. The direction is from source eNB/source RAN node to a target eNB/target RAN node. The makeBeforeBreakReq-r14 <NUM> is a variable that might be used in the techniques described herein.

Turning to the HANDOVER REQUEST ACKNOWLEDGE message of <FIG>, this is described in 3GPP TS <NUM> V15. <NUM> Section <NUM>. <FIG> is a table illustrating contents of a HANDOVER REQUEST ACKNOWLEDGE message. This message is sent by the target NG-RAN node <NUM>-<NUM> to the source NG-RAN node <NUM>-<NUM> to inform the source NG-RAN node <NUM>-<NUM> about the prepared resources at the target. The following are options available for use with exemplary embodiments herein: PDU Session Resources Admitted List <NUM>; PDU Session Resources Not Admitted List <NUM>; and Target NG-RAN node To Source NG-RAN node Transparent Container <NUM>. <FIG> is a table illustrating configuration of a PDU Session Resources Admitted List IE <NUM> from <FIG>. This IE contains PDU session resource related information to report success of the establishment of PDU session resources. <FIG> is a table illustrating configuration of a PDU Session Resources Not Admitted List IE <NUM> from <FIG>. This IE contains a list of PDU session resources which were not admitted to be added or modified. See, e.g., <NPL>), NG-RAN; Xn Application Protocol (XnAP) (Release <NUM>) for at least <FIG>. These messages might be used in exemplary embodiments herein.

Another message that might be used herein is the RRC Connection Reconfiguration message with mobility control information/Handover Command (TS <NUM>). This message is shown in <FIG>. The variable MobilityControlInfo might be used in an exemplary embodiment herein.

<FIG> is an illustration of a MobilityControlInfo information element. The makeBeforeBreak-r14 variable <NUM> of the MobilityControlInfo IE and/or the makeBeforeBreakSCG-r14 variable <NUM> of the MobilityControlInfoSCG-r12 IE might be used in exemplary embodiments herein. The makeBeforeBreak <NUM> indicates that the UE shall continue uplink transmission/downlink reception with the source cell(s) before performing the first transmission through PRACH to the target intra-frequency PCell, or performing initial PUSCH transmission to the target intra-frequency PCell while rach-Skip is configured. The makeBeforeBreakSCG <NUM> indicates that the UE shall continue uplink transmission/downlink reception with the source cell(s) before performing the first transmission through PRACH to the target intra-frequency PSCell, or performing initial PUSCH transmission to the target intra-frequency PSCell while rach-SkipSCG is configured.

Handover between cells belonging to NG-RAN nodes <NUM> that are not direct neighbors (do not have an Xn interface between them) is also supported via the core network using the NG interface between the NG-RAN node and AMF, as described in <NPL>), NG-RAN; NG Application Protocol (NGAP) (Release <NUM>). The relevant details are given below.

Handover Preparation is described in 3GPP TS <NUM> V15. <NUM>, Section <NUM>. <NUM>, and <FIG> is a signaling diagram of Handover Preparation with successful operation via a core network based HO and the NG interface. <FIG> shows signaling between a source NG-RAN node <NUM>-<NUM> and an AMF <NUM>-<NUM>.

Section <NUM>. <NUM> of TS <NUM> describes Handover Resource Allocation, and <FIG> is a signaling diagram of Handover Resource Allocation with successful operation via a core network based HO and the NG interface. <FIG> shows signaling between a target NG-RAN node <NUM>-<NUM> and an AMF <NUM>-<NUM>.

The HANDOVER REQUIRED message is described in 3GPP TS <NUM> V15. <NUM>, Section <NUM>. This message is sent by the source NG-RAN node to the AMF and illustrated by the table in <FIG>. The PDU Session Resource Item <NUM>, PDU Session ID IE <NUM>, and/or the Source to Target Transparent Container <NUM> might be used in exemplary embodiments herein.

The HANDOVER COMMAND message is described in 3GPP TS <NUM> V15. <NUM>, Section <NUM>. <NUM>, and is sent by the AMF <NUM>-<NUM> to inform the source NG-RAN node <NUM>-<NUM> that resources for the handover have been prepared at the target side. <FIG> is a table illustrating contents of a HANDOVER COMMAND message of <FIG>. The PDU Session Resource Handover Item group <NUM>, which includes the PDU Session ID IE <NUM>, and the Target to Source Transparent Container IE <NUM> may be used in exemplary embodiments described below. In this message, this IE would be what is shown in <FIG>. However, as given in the semantics description of <FIG>, this IE just carries the Target NG-RAN Node to Source NG-RAN Node Transparent Container as given in <FIG> as reference <NUM>. So the contents would be same, but the IE name is different.

The HANDOVER REQUEST message of <FIG> is described in 3GPP TS <NUM> V15. <NUM>, Section <NUM>. This message is sent by the AMF <NUM>-<NUM> to the target NG-RAN node <NUM>-<NUM> to request the preparation of resources. <FIG> is a table illustrating contents of a HANDOVER REQUEST message of <FIG>. The PDU Session Resource Setup Item group <NUM>, which includes a PDU Session ID IE <NUM> and an S-NSSAI IE <NUM>, may be used in certain exemplary embodiments described below. Additionally, the Source to Target Transparent Container IE <NUM> may be used in certain exemplary embodiments described below.

The HANDOVER REQUEST ACKNOWLEDGE message is described in 3GPP TS <NUM> V15. <NUM>, Section <NUM>. <NUM>, and is illustrated in <FIG> as being a response from the target NG-RAN node <NUM>-<NUM> to the AMF <NUM>-<NUM>. This message is sent by the target NG-RAN node <NUM>-<NUM> to inform the AMF <NUM>-<NUM> about the prepared resources at the target. <FIG> is a table illustrating contents of a HANDOVER REQUEST ACKNOWLEDGE message of <FIG>. The PDU Session Resource Admitted Item group <NUM>, which includes a PDU Session ID IE <NUM> and a Handover Request Acknowledge Transfer IE <NUM>, may be used in certain exemplary embodiments described below. Additionally, the Source to Target Transparent Container IE <NUM> may be used in certain exemplary embodiments described below.

There is a Target to Source Transparent Container IE described in 3GPP TS <NUM> V15. <NUM>, Section <NUM>. <NUM>, which might be used herein in one or more exemplary embodiments. This IE is used to transparently pass radio related information from the handover target to the handover source through the core network; it is produced by the target RAN node and is transmitted to the source RAN node. A table illustrating configuration of the Target to Source Transparent Container IE is shown in <FIG>. The semantics description for this IE is as follows: "This IE includes a transparent container from the target RAN node to the source RAN node. The octets of the OCTET STRING are encoded according to the specifications of the target system. Note: In the current version of the specification, this IE may carry either the Target NG-RAN Node to Source NG-RAN Node Transparent Container IE or the Target eNB to Source eNB Transparent Container IE as defined in TS <NUM> [<NUM>].

There is also a Target NG-RAN Node to Source NG-RAN Node Transparent Container IE, described in 3GPP TS <NUM> V15. <NUM>, Section <NUM>. This IE might be used in exemplary embodiments. This IE is produced by the target NG-RAN node and is transmitted to the source NG-RAN node. For inter-system handovers to <NUM>, the IE is transmitted from the target NG-RAN node to the external relocation source. This IE is transparent to the 5GC.

<FIG> is a table illustrating configuration of a Target NG-RAN Node to Source NG-RAN Node Transparent Container IE. The semantics description for this IE is as follows: "Includes the RRC HandoverCommand message as defined in TS <NUM> [<NUM>] if the target is a gNB. Includes the RRC HandoverCommand message as defined in TS <NUM> [<NUM>] if the target is an ng-eNB.

Another IE that might be used in an exemplary embodiment is a Source to Target Transparent Container IE, described in 3GPP TS <NUM> V15. <NUM>, Section <NUM>. This IE is used to transparently pass radio related information from the handover source to the handover target through the core network. This IE is produced by the source RAN node <NUM>-<NUM> and is transmitted to the target RAN node <NUM>-<NUM>. <FIG> is a table illustrating configuration of a Source to Target Transparent Container IE. The semantics description for this IE states the following: "This IE includes a transparent container from the source RAN node to the target RAN node. The octets of the OCTET STRING are encoded according to the specifications of the target system. Note: In the current version of the specification, this IE may carry either the Source NG-RAN Node to Target NG-RAN Node Transparent Container IE or the Source eNB to Target eNB Transparent Container IE as defined in TS <NUM> [<NUM>].

A further IE that might be used in exemplary embodiments is a Source NG-RAN Node to Target NG-RAN Node Transparent Container IE, described in 3GPP TS <NUM> V15. <NUM>, Section <NUM>. This IE is produced by the source NG-RAN node <NUM>-<NUM> and is transmitted to the target NG-RAN node <NUM>-<NUM>. For inter-system handovers to <NUM>, the IE is transmitted from the external handover source to the target NG-RAN node. This IE is transparent to the 5GC. <FIG> is a table illustrating configuration of a Source NG-RAN Node to Target NG-RAN Node Transparent Container IE. The RRC Container IE <NUM> and also the RRC HandoverCommand message as defined in TS <NUM> (see reference <NUM>) may be used in exemplary embodiments herein.

An exemplary embodiment proposes that the source cell provides a service/slice specific indication for enhanced HO (similar to make-before-break indication of LTE Rel. <NUM>) to the target cell in the HO preparation phase. The target cell can then prepare a HO command that considers the service/slice specific request from the source cell. This HO command is then delivered to the UE, via the source cell, to inform the UE for which services/slices the UE needs to maintain the connection to both the source cell and target cell during the HO and for which services/slices the UE can perform the normal HO and does not need to maintain two simultaneous connections.

This would allow the source cell to choose for which services/slices the source cell wants to support the enhanced HO depending on its resource utilization status and the service characteristics of different slices the UE is connected to (e.g., the tolerance for user service interruption per particular service).

Referring to <FIG>, this figure is a logic flow diagram and signaling for enhanced mobility in cellular deployments with network slicing, and illustrates a RAN-based handover. This figure illustrates the operation of an exemplary method or methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiments. The blocks in <FIG> are assumed to be performed by the UE <NUM>, under control of the mobility module <NUM>, and the source and target RAN nodes <NUM>-<NUM>, <NUM>-<NUM>, under control of corresponding mobility modules <NUM>. Each of the source RAN node <NUM>-<NUM> and the target RAN node <NUM>-<NUM> forms a corresponding cell described in this figure (and also <FIG>), and may also form other cells. Note that intra-gNB handover is also possible. That is, handover between cells of a RAN node <NUM> (e.g., the source and target RAN nodes are the same, but different cells). But in this case there will be no message exchange on the standardized interfaces. Instead, the exchange is internal to the gNB.

In block <NUM>, the source RAN node <NUM>-<NUM> determines an enhanced HO is to be performed for a UE for one or more service/slice types. That is, it is the source cell (e.g., formed by the source RAN node <NUM>-<NUM>) that decides for which slices the cell wants to have make-before-break, so the optimization logic is with the source cell. The target cell (e.g., formed by the target RAN node <NUM>-<NUM>) just follows the request from the source cell. The source RAN node <NUM>-<NUM> makes this determination in block <NUM>. <FIG> is an example of block <NUM> from <FIG>. <FIG> shows the source RAN node <NUM>-<NUM> performing the operation of choosing for which services/slices the source cell (formed by the source RAN node <NUM>-<NUM>) wants to support the enhanced HO, depending on the resource utilization status of the source RAN node <NUM>-<NUM> and the service characteristics of different slices to which the UE is connected (e.g., the tolerance for user service interruption per particular service).

In block <NUM>, the source RAN node <NUM>-<NUM> provides (e.g., via a HO request message <NUM>) service/slice specific indication(s) for the enhanced HO to the target cell. Turning to <FIG>, this figure is an example of possible indications in a HO request message from <FIG>. There is an indication in (A) of a list of slices to be handed over to the target cell. This is part of, e.g., the "PDU Session Resource To Be Setup List" (for example <FIG>, reference <NUM>). With this list, the target cell already knows all the slices/services that require a HO and the target RAN node <NUM>-<NUM> can accept or reject those slices individually. The HO request <NUM> may also indicate (B) the type of HO to be performed for the individual slices. This needs to be communicated from source cell to the target cell in addition to the list above. Two possible examples are illustrated by <FIG>, where the source RAN node <NUM>-<NUM> can perform one of the following: <NUM>. ) Provide a full list of slices with their corresponding HO types, or <NUM>. ) Provide only the list of slices that require enhanced HO and the other slices are assumed to be handed over with normal HO. How to communicate this list is explained below. In short, as examples, one can either: (a) Modify the "makeBeforeBreakReq-r14" (<FIG>) to be a list that contains the slice IDs and their required HO type, or (b) Add a new IE to indicate the required HO type in the "PDU Session Resources To Be Setup Item" (see item <NUM> of <FIG>). Returning to <FIG>, the target RAN node <NUM>-<NUM> receives the service/slice specific indication(s) for the enhanced HO in block <NUM>.

In block <NUM>, the target RAN node <NUM>-<NUM> considers the service/slice specific request(s) from the source node. The target cell is free to accept or reject any HO requests depending, for example, on its resource utilization and supported features. In case of network slices, the target cell can accept all or only a subset of network slices that are requested by the source cell for a UE. But if the target cell accepts a HO request for a slice, the target cell will simply follow the instructions from the source cell about the type of HO to be performed for that slice. In block <NUM>, the target RAN node <NUM>-<NUM> prepares and provides a HO command that considers the service/slice specific request(s). The HO command is packaged in the HO request Acknowledge (Ack) message <NUM>. Referring to <FIG>, this figure is an example of possible indications in a HO request acknowledgement (Ack) message <NUM> from <FIG>. This example has the target RAN node <NUM>-<NUM> indicating in the HO request acknowledgement (Ack) message <NUM> acceptance of or rejection of the provided slices, where the provided slices were given in option (<NUM>. ) or (<NUM>. ) of <FIG>. To clarify, the HO request acknowledgement message <NUM> contains the acceptance or rejection indication at individual slice level. This means that the target RAN node <NUM>-<NUM> can possibly accept all or a subset (less than all) of the requested slices. The target RAN node <NUM>-<NUM> does not necessarily have to either accept or reject the whole HO request, although rejection of the whole HO request is possible (but is not shown in this figure or <FIG>). In addition, the HO acknowledgement also contains the HO command message that defines the radio configuration to be used by the UE to perform the HO to the target cell including the type of HO information. See for example <FIG>. Note that the HO request Ack <NUM> can contain its own list, e.g., of slices and whether they were accepted or rejected.

In additional detail, regardless of HO type, the target cell needs to tell the source cell about which slices/PDU sessions the target cell can accept and which cannot be accepted. One option for this is given in <FIG> as "PDU Session Resources Admitted List" <NUM> (see <FIG> also), and "PDU Session Resources Not Admitted List" <NUM> (see <FIG> also). Assume the source cell indicates the following using the HO request <NUM>: Slice A, enhanced HO; Slice B, enhanced HO; Slice C, normal HO; and Slice D, normal HO. Assume the target cell accepts slices A, C, and D, but rejects slice B. In this case, the HO request Ack <NUM> could indicate the following:.

Now what is needed is to add the HO type indication. This we can add to both the accepted and rejected lists <NUM>, <NUM>, or only the accepted list <NUM>.

The HO Request Ack <NUM> also contains the "Target NG-RAN node To Source NG-RAN node Transparent Container" (see <FIG>), which includes the HandoverCommand message to be forwarded to the UE. For this HandoverCommand message we have two options to indicate the HO type as described below:.

Returning to <FIG>, the source RAN node <NUM>-<NUM> receives the HO command in block <NUM> and in block <NUM> delivers the HO command to the UE via (in this example) the HO command <NUM>. <FIG> is an example of possible indications in a HO command message <NUM> from <FIG>. The HO command message <NUM> may indicate the following, e.g., the source RAN node <NUM>-<NUM> may: (A) Indicate a list of slices to be handed over to target cell; and (B) indicate the HO type as follows: <NUM>. ) Provide a full list of slices with their corresponding HO types, or <NUM>. ) Provide only the list of slices that require enhanced HO and the other slices are assumed to be handed over with normal HO.

In <FIG>, the UE <NUM> in block <NUM> receives the HO command <NUM>. In block <NUM>, the UE <NUM> determines, based on the HO command and current network slices, which network slice(s) (e.g., via service/slice type(s)) need to maintain two simultaneous connections (e.g., make-before-break handovers) and which network slice(s) (e.g., via service/slice type(s)) do not need to maintain simultaneous connections (e.g., legacy handovers). In respective blocks <NUM>, <NUM>, and <NUM>, the UE <NUM>, the source RAN node <NUM>-<NUM>, and the target RAN node <NUM>-<NUM> cooperate to perform handover of the UE from the source RAN node <NUM>-<NUM> to the target RAN node <NUM>-<NUM>. Additionally, in block <NUM>, the UE <NUM> performs the handover, maintaining two simultaneous connections for those network slice(s) determined to need simultaneous connections, and does not maintain simultaneous connections for those network slice(s) determined to not need simultaneous connections. In block <NUM>, the source RAN node <NUM>-<NUM> performs handover of the UE <NUM> from the source cell to the target cell, performing make-before-break handovers to hand over network slice(s) for enhanced handovers, and performing normal handover(s) for other network slice(s). Similarly, in block <NUM>, the target RAN node <NUM>-<NUM> performs handover of the UE <NUM> from the source cell to the target cell, performing make-before-break handovers to hand over network slice(s) for enhanced handovers, and performing normal handover(s) for other network slice(s). As previously described, enhanced HO means the UE can simultaneously maintain connections to both the source and target cells after the UE has received the HO command. For a normal handover, by contrast, the UE does not simultaneously maintain connections to both the source and target cells after the UE has received the HO command and instead breaks connection with the source cell before making a connection with the target cell.

<FIG> is a logic flow diagram and signaling diagram for enhanced mobility in cellular deployments with network slicing, and illustrates a network-based handover, in accordance with an exemplary embodiment. This figure illustrates the operation of an exemplary method or methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiments. The blocks in <FIG> are assumed to be performed by the source and target RAN nodes <NUM>-<NUM>, <NUM>-<NUM>, under control of corresponding mobility modules <NUM>, and the AMF (and/or other network functionality, such as MME) <NUM>-<NUM>, e.g., under control of the mobility module <NUM>. This figure does not refer to the UE <NUM> for ease of reference, but the UE <NUM> would perform the actions in <FIG>.

Block <NUM> is the same as in <FIG>. In block <NUM>-<NUM>, the source RAN node <NUM>-<NUM> provides service/slice specific indication(s) for the enhanced HO to the AMF <NUM>-<NUM>. The source RAN node <NUM>-<NUM> uses the HO required message <NUM>, which is also illustrated in <FIG>. The AMF <NUM>-<NUM> is one example of a network element <NUM> that might be used in a core network, but other elements such as an MME could be used alternatively or in addition to the AMF <NUM>-<NUM>. The AMF <NUM>-<NUM> receives the service/slice specific indication(s) for the enhanced HO in block <NUM>. The AMF <NUM>-<NUM> in block <NUM> provides the service/slice specific indication(s) for the enhanced HO to the target (target RAN node <NUM>-<NUM>), using the HO request message <NUM>. This message is shown in <FIG> and <FIG>.

The blocks <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> correspond to blocks <NUM>, <NUM> and <NUM> of <FIG>, except that block <NUM>-<NUM> receives the HO request message <NUM> (e.g., instead of the HO request message <NUM>), the block <NUM>-<NUM> uses this information (instead of the information from the HO request message <NUM>), and block <NUM>-<NUM> sends a HO request acknowledgement (Ack) message <NUM> (e.g., may be different from the HO request Ack message <NUM>). The HO request Ack message <NUM> is also illustrated in <FIG> and <FIG>.

In block <NUM>, the AMF <NUM>-<NUM> receives the HO request Ack message <NUM> and sends a HO command <NUM>. The HO command <NUM> is also illustrated in <FIG> and <FIG>. The source RAN node <NUM>-<NUM> receives the HO command <NUM> in block <NUM>-<NUM>, delivers the HO command (as HO command <NUM>) to the UE in block <NUM>. The source RAN node <NUM>-<NUM> and target RAN node <NUM>-<NUM> perform the handover in blocks <NUM> and <NUM>.

To implement the exemplary embodiments, a mechanism similar to "make-before-break indication" is used in NR, but to achieve the required flexibility, one or more of the following additions could still be needed.

It is noted that, if only one slice needs HO, then the HO may be performed with the single "make-before-break" flag, e.g., from LTE. On the other hand, as a UE is allowed to be simultaneously connected to up to eight slices, a "list" of HO type indication would be useful. Otherwise, there might have two different IEs, one for the single slice case and another for multiple slices. Having a list caters for both cases, e.g., where the list can also be of size one.

Therefore, one of the proposals herein is to modify the existing "make-before-break" single flag into a list of individual slices and their required HO type flags. Another exemplary option is to add the HO type flag in the PDU Session Resources To Be Setup Item for RAN-based HO or the PDU Session Resource Setup Item for Core-network-based HO. This would be totally different from current/legacy specification. This way, the number of flags automatically depends on the number of Items we have in the PDU Session List, whose size could be one or more.

For RAN-based HO (without involving the MME/AMF), the two X2AP/XnAP signaling messages "Handover Request" and "Handover Request Acknowledge" (see <FIG> and <FIG>) and the RRC Connection Reconfiguration message/HO command (or their equivalent in NR) may be updated as follows.

The Handover Request message is illustrated in <FIG> and <FIG>. There are a number of options for this message.

For preparing the handover command in current LTE Rel. <NUM>, the target BS <NUM>-<NUM> uses one Boolean IE (true or false) to indicate whether make-before-break handover will be executed, as instructed by the source BS in a HO Request. To implement an exemplary proposed solution, the target BS could indicate a list of required S-NSSAIs and their corresponding flags for the make-before-break/enhanced HO when preparing the HO command to the UE. One option is to use the "Target NG-RAN node to Source NG-RAN node transparent container" <NUM> in <FIG>.

In addition, the target BS <NUM>-<NUM> may include the make-before break/enhanced HO indication in the "PDU Session Resources Admitted List" <NUM> (see <FIG>) which identifies the individual PDU sessions that are admitted by the target BS.

The handover command prepared by the target BS <NUM>-<NUM> is sent to the UE <NUM> via the source BS <NUM>-<NUM>. Currently for LTE, the RRC Connection Reconfiguration messages/HO command contains the mobility control information with make-before-break indication to notify the UE about the enhanced mobility option. For NR, a similar IE like ReconfigurationWithSync can be extended to include a list of required S-NSSAIs and their corresponding flag for the make-before-break/enhanced HO. ReconfigurationWithSync is the Information Element (IE) present in RRC Reconfiguration message sent by the network for HO purposes in NR (related behavior can be found in 3GPP TS <NUM>, section <NUM>. This is similar to the mobilityControlInfo IE, known from LTE (i.e., described in 3GPP TS <NUM>) and also used in RRC Connection Reconfiguration to indicate this is a HO Command.

To implement the exemplary embodiments using the core-network-based HO, one or more of the following messages on a NG interface may be modified as described below.

A make-before-break or enhanced-HO indication can be added to the "PDU Session Resource Item" <NUM> (see <FIG>) and the corresponding PDU session ID <NUM>, which identify the individual PDU sessions to be supported during the HO.

Otherwise, the RRC Container within the "Source NG-RAN Node to Target NG-RAN Node Transparent Container" (see <FIG>) can also be enhanced. This RRC Container includes the "HandoverPreparationInformation" (see <FIG>), which can be enhanced with the list of S-NSSAI and its make-before-break/enhanced HO indication flag as also described above for the RAN-based HO.

Similar to the HO Required message, either the make-before-break/enhanced HO indication can be added to the "PDU Session Resource Setup Item" <NUM> (see <FIG>), which identifies the individual PDU sessions (e.g., via the PDU Session ID IE <NUM>) to be supported during the HO or if the "Source NG-RAN Node to Target NG-RAN Node Transparent Container" <NUM> is enhanced in the HO Required message (see <FIG>) then this can also be used to inform the target BS <NUM>-<NUM> about the specific mobility requirements of individual PDU sessions belonging to different slices/services.

A make-before-break/enhanced HO indication can be added to the "PDU Session Resource Admitted Item" <NUM> (see <FIG>) and its corresponding PDU Session ID IE <NUM>, and/or the "Target to Source Transparent Container" <NUM> can be enhanced, which contains the RRC Container indicating the "HandoverCommand" message from the target BS. That is, the Target to Source transparent container includes an RRC container which includes the HandoverCommand, as illustrated in <FIG>. This HandoverCommand extension would be similar to the RAN-based HO as described above.

A make-before-break indication can be added to the "PDU Session Resource Handover Item" <NUM> (see <FIG>) (e.g., and its corresponding PDU Session ID IE <NUM>) and/or the enhanced "HandoverCommand" can be added to the RRC Container in the "Target to Source Transparent Container" <NUM>.

Without in any way limiting the scope, interpretation, or application of the claims appearing below, technical effects and advantages of one or more of the example embodiments disclosed herein includes the following:.

As such, the exemplary embodiments allow the flexibility for the source cell to apply different policies regarding the HO procedure to different services/slices that are simultaneously used by the same UE. The source cell might want to apply different HO policy based on, for example, the service characteristics or the connected services/slices or its own resource utilization status and optimization objectives.

Embodiments herein may be implemented in software (executed by one or more processors), hardware (e.g., an application specific integrated circuit), or a combination of software and hardware. In an example embodiment, the software (e.g., application logic, an instruction set) is maintained on any one of various conventional computer-readable media. In the context of this document, a "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted, e.g., in <FIG>. A computer-readable medium may comprise a computer-readable storage medium (e.g., memories <NUM>, <NUM>, <NUM> or other device) that may be any media or means that can contain, store, and/or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer. A computer-readable storage medium does not comprise propagating signals.

Although various aspects are set out above, other aspects comprise other combinations of features from the described embodiments, and not solely the combinations described above.

Claim 1:
An apparatus for a source cell (<NUM>-<NUM>), the apparatus comprising:
means for providing, by the apparatus and to an apparatus of a target cell (<NUM>-<NUM>) in a wireless network, a list of one or more service/slice specific indications for individual ones of one or more network slices in a request for enhanced handover of a user equipment (<NUM>) from the apparatus to the apparatus of the target cell (<NUM>-<NUM>), the providing performed in a handover preparation phase prior to handover of the user equipment (<NUM>);
means for receiving, by the apparatus and from the apparatus of the target cell (<NUM>-<NUM>), a handover request acknowledgement comprising a handover command and indications of one or more selected network slices, from the list of one or more service/slice specific indications, to be handed over from the apparatus to the apparatus of the target cell using enhanced handovers, for maintaining by the user equipment (<NUM>) two simultaneous connections for the one or more selected network slices with both the apparatus and the apparatus of the target cell (<NUM>-<NUM>);
means for providing, by the apparatus and to the user equipment (<NUM>), the indications in the handover command of the one or more selected network slices for enhanced handover of the user equipment (<NUM>) from the apparatus to the apparatus of the target cell (<NUM>-<NUM>), the providing performed in the handover preparation phase prior to handover of the user equipment (<NUM>)
means, for the one or more selected network slices, for performing enhanced handovers to hand over these one or more selected network slices from the apparatus to the apparatus of the target cell (<NUM>-<NUM>); and
means, for one or more other network slices to be handed over for the user equipment from the apparatus to the apparatus of the target cell (<NUM>-<NUM>), for performing normal handovers for the one or more other network slices.