TECHNICAL FIELD The present invention relates to an apparatus for providing network slice continuity, particularly in a mobile communication network. Slice continuity means a continuation of providing slice coverage in areas, where the slice is not supported or available. The present invention also relates to a radio access node for providing network slice continuity, particularly in a mobile communication network. In addition, the present invention also relates to corresponding methods. The apparatus and radio access node may cooperate as system in the mobile communication network, in order to provide the slice continuity.

BACKGROUND The concept of network slicing is introduced in 5G for addressing various requirements from multiple vertical industries assuming a shared network infrastructure. With network slicing, network services can be customized based on the requirements of different use cases, and can thus significantly increase the network operation efficiency. According to the current definition in 3GPP (see TR23.501), a network slice is an end to end concept, and is defined a complete logical network that comprises of a set of network functions and corresponding resources necessary to provide certain network capabilities and network characteristics. This includes both 5G-Radio Access Network (RAN) and 5G Core Network (CN).

Due to diverse deployment and dynamic situations (e.g. load, resource, physical capabilities of the wireless access nodes) in a 5G RAN, some network slices may be available only in a part of the network. Slice availability may also depend on the operator deployment, and different network deployments pertaining to different operators can have different levels of slice availability. When an active User Equipment (UE) moves in the network, it may enter into an area, in which the active session of its currently associated slice cannot be supported, while also no further slice is available to the UE. That is, a slice Handover (HO) may not be possible. A slice HO is a slice re-selection for a UE. The UE may also enter into an area, in which a slice is in principle available for the UE, but the coverage of the slice is poor, e.g. due to channel conditions and/or interference. That is, a slice HO is in principle possible, but it is uncertain, if slice HO is also desirable. Notably, any lack of slice availability can cause service interruptions and undesired delays, and particularly fulfilment of Service Level Agreement (SLA), which is vital for network slicing and can lead to service dis-continuity, which is the failure to meet the service SLAs. A slice may include one or more services, e.g., each associated with a protocol data unit (PDU) session. Accordingly, service continuity may be possible for part of the slice services.

Accordingly, for a reliable and efficient UE mobility in a network, as well as for reliable service continuity, the RAN may need to adapt its configuration dynamically, in order to allow for a temporary solution that meets the slice requirements in case of no slice availability or in case of poor slice coverage or in case of traffic congestion of a slice.

According to current 3GPP (see TR 38.801), the RAN shall support the selection of the RAN part of the network slice, by one or more slice ID(s) provided by the UE or the CN, which unambiguously identifies one or more of the pre-configured network slices in the network. Furthermore, the RAN shall support a differentiated handling of traffic for different network slices. In this context, 3GPP (see TR 23.799) defines configured and accepted Network Slice Selection Assistance Information (NSSAI) used by the RAN to help deciding on the RAN configuration. 3GPP currently also states (see TR38.801): "The RAN and the CN are responsible to handle a service request for a slice that may or may not be available in a given area. Admission or rejection of access to a slice may depend by factors such as support for the slice, availability of resources, support of the requested service by other slices". However, it is not yet defined, according to which criteria, and depending on which costs (e.g. end-to-end delays and degradation of performance due to resource situation), it should be decided, whether to perform a slice HO or not. Also, it is not yet defined, how service discontinuity can be avoided, if a slice HO is not performed. SUMMARY

In view of the above-mentioned challenges, the present invention aims to improve the conventional concept of network slicing. The present invention has the object to provide an apparatus and radio access node, respectively, for providing network slice continuity. In particular, the present invention seeks to define criteria for deciding, whether to perform slice HO or not. Further, the present invention intends to provide a solution for slice continuity, if slice HO is not possible or not desirable. The present invention thereby intends implementing a temporary slice support, and an according RAN adaption, for a particularly efficient and homogeneous end-to-end slice coverage.

The object of the present invention is achieved by the solution provided in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the dependent claims.

In particular, the solution includes, how to determine, whether to perform a slice HO or to avoid a slice HO (considering also potential delays for the slice HO process). The solution also includes adapting RAN configuration parameters, in order to avoid a slice HO (or if slice HO may not be possible), so as to ensure service continuity in any case. Further, the solution also includes, how to specifically adapt the RAN configuration parameters, in order to enable a target node, e.g. a gigabit Node BSs (gNBs), to support a slice temporarily (e.g. by slice breathing), in order to minimize the probability of slice HO failure (due to, for instance, the slice re- selection preparation and execution time). A first aspect of the present invention provides an apparatus for providing network slice continuity in a mobile communication network, the apparatus being configured to, if a slice HO, to a target node is not possible, send a temporary slice support request to the target node, comprising at least one support requirement parameter and a RAN configuration parameter, receive from the target node an acknowledgement for admitting the slice to be temporarily supported at the target node, and determine temporary slice support upon receiving the acknowledgement from the target node.

That is, the apparatus of the first aspect is configured to determine and configure a temporary slice support, in order to avoid service discontinuity, if slice HO is not possible. For the configuring, the apparatus is able to define a support requirement parameter for the temporary slice support and a RAN configuration parameter, according to which the target node can provide the support of the slice. Accordingly, the apparatus allows implementing slice and service continuity. Service continuity means continuation of meeting the service requirements of a slice, assuming one or more services per slice, as defined by the service KPIs. In summary, the benefit of the apparatus is an improved user experience, because by the temporary support of the slice at the target node, a maximum (per slice) service continuity can be retained even during user mobility. In an implementation form of the first aspect, the apparatus is further configured to, if a slice HO to the target node is possible, estimate, a slice HO failure, SHOF, probability based on a slice parameter of a slice currently associated with the UE, determine whether to perform a slice HO or the temporary slice support to the target node according to the estimated SHOF probability, and send a temporary slice support request comprising the estimated SHOF probability and at least one support requirement parameter and a RAN configuration parameter to the target node.

Estimating the SHOF probability, and implementing temporary slice support in some cases, can reduce the HO failure rate, for instance, due to slice HO preparation latency. Furthermore, the estimation of the SHOF probability can lead to signal reduction, namely by avoiding unnecessary slice HO signaling (e.g. in case of multi-slice UEs this signalling can be large) to the UEs, RAN and network, where the requested slice is not supported by some RAN node.

In a further implementation form of the first aspect, the slice parameter comprises slice- availability information, a slice HO preparation latency, and/or a slice requirement.

Accordingly, the SHOF probability can be estimated accurately.

In a further implementation form of the first aspect, the apparatus is configured to further use RAN context information and/or UE context information to determine, whether to perform a slice HO or the temporary slice support.

Thus, the chances of finding the best possible procedure, i.e. perform slice HO or temporary slice support, are significantly increased.

In a further implementation form of the first aspect, the at least one support requirement parameter comprises a time duration for the temporary slice support.

That is, the apparatus requests slice support for a certain amount of time from the target node. In a further implementation form of the first aspect, the RAN configuration parameter comprises a RAN ID and/or RAN context information.

In a further implementation form of the first aspect, the temporary slice support request further comprises a slice ID and/or a network slice selection assistance information parameter.

Thereby, the temporary slice support can be performed by the target node more efficiently.

In a further implementation form of the first aspect, the apparatus is a base station, BS, currently serving the UE, and is configured to send the temporary slice support request to a target BS not serving the UE.

In this case, the temporary slice support is negotiated between serving and target BS, for instance, using signaling over Xn interface.

In a further implementation form of the first aspect, the apparatus is configured to negotiate the at least one support requirement parameter with the target BS.

Thus, the source and target BS can find the best compromise in terms of service continuity and resources.

In a further implementation form of the first aspect, the apparatus is further configured to send a temporary slice support notification to a Core Network Control Plane, CN-C, using signaling over NG interface.

In a further implementation form of the first aspect, the apparatus comprises a base station, BS, currently serving the UE, which is configured to estimate the SHOF probability, if a slice HO to the target node is possible, and a RAN slice management entity (DSS) and/or cross- domain slice management entity (SSS) configured to obtain the SHOF probability from the serving BS, to determine whether to perform a slice HO or the temporary slice support, and to send the temporary slice support request to the target node via a CN-C and/or via the BS currently serving the UE using the management and XN/NG interface accordingly. In this case, the temporary slice support can be implemented using a dedicated slice management domain (DSS) and/or cross-slice management domain (SSS), which has the better overall view of the network and can take the decision for temporary slice support on behalf of the BSs.

In a further implementation form of the first aspect, the apparatus is further configured to determine, if temporary slice support is determined, whether the UE is handed over to the target BS after temporary slice support provided by the target BS, or the UE is temporarily served in a dual-connectivity mode by the serving BS and the target BS.

In a further implementation form of the first aspect, the apparatus is further configured to provide the UE with an ID of the target BS that is to provide the temporary slice support.

A second aspect of the present invention provides a method for providing network slice continuity in a mobile communication network, wherein the method comprises, if a slice Handover, HO, to a target node is not possible, sending a temporary slice support request to the target node, comprising at least one support requirement parameter and a Radio Access Network, RAN, configuration parameter, receiving from the target node an acknowledgement for admitting the slice to be temporarily supported at the target node, and determining temporary slice support upon receiving the acknowledgement from the target node.

In an implementation form of the second aspect, the method further comprises, if a slice HO to the target node is possible, estimating, a slice HO failure, SHOF, probability based on a slice parameter of a slice currently associated with the UE, determining whether to perform a slice HO or the temporary slice support to the target node according to the estimated SHOF probability, and sending a temporary slice support request comprising the estimated SHOF probability and at least one support requirement parameter and a RAN configuration parameter to the target node. In a further implementation form of the second aspect, the slice parameter comprises slice- availability information, a slice HO preparation latency, and/or a slice requirement. In a further implementation form of the second aspect, the method comprises further using RAN context information and/or UE context information to determine, whether to perform a slice HO or the temporary slice support. In a further implementation form of the second aspect, the at least one support requirement parameter comprises a time duration for the temporary slice support.

In a further implementation form of the second aspect, the RAN configuration parameter comprises a RAN ID and/or RAN context information.

In a further implementation form of the second aspect, the temporary slice support request further comprises a slice ID and/or a network slice selection assistance information parameter.

In a further implementation form of the second aspect, the method is carried out by a base station, BS, currently serving the UE, which sends the temporary slice support request to a target BS not serving the UE.

In a further implementation form of the second aspect, the method further comprises negotiating the at least one support requirement parameter with the target BS.

In a further implementation form of the second aspect, the method further comprises sending a temporary slice support notification to a Core Network Control Plane, CN-C.

In a further implementation form of the second aspect, the method is carried out by a base station, BS, currently serving the UE, which estimates the SHOF probability, if a slice HO to the target node is possible, and a RAN and/or cross-domain slice management entity, which obtains the SHOF probability from the serving BS, to determine whether to perform a slice HO or the temporary slice support, and sends the temporary slice support request to the target node via a CN-C and/or via the BS currently serving the UE.

In a further implementation form of the second aspect, the method further comprises determining, if temporary slice support is determined, whether the UE is handed over to the target BS after temporary slice support provided by the target BS, or the UE is temporarily served in a dual-connectivity mode by the serving BS and the target BS. In a further implementation form of the second aspect, the method further comprises providing the UE with an ID of the target BS that is to provide the temporary slice support.

The method of the second aspect and its implementation forms achieve the same advantages and effects as the apparatus of the first aspect.

A third aspect of the present invention provides a radio access node for providing network slice continuity in a mobile communication network, the node being configured to receive a temporary slice support request comprising at least one support requirement parameter and a RAN configuration parameter, determine whether to admit the temporary slice support request based on resource availability, traffic situation and/or RAN capability, if temporary slice support is admitted, adapt its RAN configuration parameter according to the received RAN configuration parameter to support the new network slice, apply the temporary slice support according to the received support requirement parameter, and send an acknowledgment for admitting the slice to be temporarily supported.

Thus, the radio access node is particularly configured to cooperate with the apparatus of the first aspect, in order to provide network slice continuity in the mobile communication network. Accordingly, with the radio access node of the third aspect, the advantages and effects described above with respect to the apparatus of the first aspect can be realized.

In particular, the radio access node can determine to provide the requested temporary slice support, in case that it has available resources, and/or the traffic situation allows it to provide the requested support, and/or if it is at all capable for providing the support. In this case, it uses the provided RAN configuration parameter to efficiently implement the temporary slice support. Thus, the radio access node allows ensuring service continuity without slice HO.

A fourth aspect of the present invention provides a method for providing network slice continuity in a mobile communication network, the method comprising receiving a temporary slice support request comprising at least one support requirement parameter and a RAN configuration parameter, determining whether to admit the temporary slice support request based on resource availability, traffic situation and/or RAN capability, if temporary slice support is admitted, adapting a RAN configuration parameter of a radio access node according to the received RAN configuration parameter to support the new network slice, applying the temporary slice support according to the received support requirement parameter, and sending an acknowledgment for admitting the slice to be temporarily supported. The method of the fourth aspect achieves the effects and advantages of the radio access node of the third aspect.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. BRIEF DESCRIPTION OF THE DRAWINGS

The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which:

Fig. 1 highlights an apparatus and a corresponding method according to embodiments of the present invention.

Fig. 2 highlights a radio access node (target node) and a corresponding method according to embodiments of the present invention.

Fig. 3 shows a specific procedure for temporary slice support using Xn signaling. Fig. 4 shows a specific procedure for temporary slice support using a slice management domain.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Fig. 1 highlights an apparatus 100 according to an embodiment of the present invention. The apparatus 100 may be a BS, or may include a BS, particularly a gNB. The apparatus 100 may further include a RAN and/or cross-domain slice management entity. The apparatus 100 interacts with a target node 200, which may be a radio access node, like a BS, particularly a gNB.

The apparatus 100 is configured to provide network slice continuity in a mobile communication network. In particular, the apparatus 100 is configured to avoid slice- unavailability, when a UE moves within the mobile communication network into an area, in which the slice currently associated with the UE is not supported. In one case, the area is served by a target node 200 that does not have any new slice available for the UE. In other words, slice HO to the target node 200 is not possible in this case. In another case, the slice coverage of one or more slices supported by the target node 200 is poor. In other words, slice HO to the target node 200 is in principle possible in the second case, but may not be desirable, due to the poor slice coverage.

If a slice HO to the target node 200 is not possible, the apparatus 100 is configured to send 101 a temporary slice support request to the target node 200. This request comprises at least one support requirement parameter and a RAN configuration parameter. The apparatus 100 is further configured to receive 102, from the target node 200, an acknowledgement for admitting the slice to be temporarily supported at the target node 200. The apparatus 100 is also configured to determine 103 temporary slice support upon receiving the acknowledgement from the target node 200. If a slice HO to the target node 200 is possible, the apparatus 100 is configured to estimate a slice HO failure (SHOF) probability based on a slice parameter of a slice currently associated with the UE. The slice parameter preferably comprises slice-availability information, a slice HO preparation latency, and/or a slice requirement. The apparatus 100 is further configured to determine, whether to perform a slice HO or to perform the temporary slice support to the target node 200, respectively. In particular, the apparatus 100 makes this determination according to the estimated SHOF probability. That is, for example, if the estimated SHOF probability is above a determined threshold value, the apparatus 100 may determine that temporary slice support should be performed. Otherwise, the apparatus may determine that a slice HO should be performed.

The apparatus 100 is further configured to send a temporary slice support request comprising the estimated SHOF probability and at least one support requirement parameter and a RAN configuration parameter to the target node 200. The at least one support requirement parameter preferably comprises a time duration for the temporary slice support, but may also comprise a slice ID and/or a network slice selection assistance information parameter. The apparatus 100 and the target node 200 may negotiate about the at least one support requirement parameter. That means, the support requirement parameter included in the temporary slice support request may be an initial proposal, and the apparatus 100 and the target node 200 may agree - after their negotiation is finished - on a different support requirement parameter. For instance, in the end the apparatus 100 and target node 200 may agree on a different time duration for the temporary slice support, than the time duration initially proposed with the request. The apparatus 200 is accordingly configured to carry out a method according to an embodiment of the present invention, which comprises the following steps, if the slice HO to the target node is not possible. A step 101 of sending a temporary slice support request to the target node 200, wherein the request comprises at least one support requirement parameter and a RAN, configuration parameter. A step 102 of receiving, from the target node 200, an acknowledgement for admitting the slice to be temporarily supported at the target node 200. And a step 103 of determining temporary slice support, upon receiving the acknowledgement from the target node 200.

Fig. 2 highlights a radio access node 200, which may be the target node shown in Fig. 1. The radio access node 200 may be a BS, particularly a gNB. The radio access node 200 is configured to provide network slice continuity in a mobile communication network. Preferably, the radio access node 200 and the apparatus 100, which is highlighted in Fig. 1, interact and/or cooperate with each other as a system, in order to provide the slice continuity. The radio access node 200 is particularly configured to receive 201 a temporary slice support request comprising at least one support requirement parameter and a RAN configuration parameter. Preferably, the node 200 receives the temporary slice support request directly from the apparatus 100, as is indicated in Fig. 2 (or Fig. 1 for that matter). The radio access node 200 is further configured to determine 202, whether to admit the temporary slice support request based on resource availability, traffic situation and/or RAN capability.

If temporary slice support is admitted, the radio access node 200 is configured to adapt 203 its RAN configuration parameter according to the received RAN configuration parameter, in order to support the network slice (new network slice at the radio access node 200). Then, the radio access node 200 is configured to apply 204 the temporary slice support according to the received support requirement parameter, e.g. according to the included time duration for supporting the slice. Again, the support requirement parameter may be negotiated by the radio access node 200 and the apparatus 100. Finally, the radio access node 200 is configured to send 205 an acknowledgment for admitting the slice to be temporarily supported, preferably send it directly to the apparatus 100, as is shown in Fig. 2 (or Fig. 1 for that matter).

The radio access node 200 is accordingly configured to carry out a method according to an embodiment of the present invention, wherein the method comprises steps 201-205 according to the actions 201-205 of the radio access node 200, respectively.

According to the above, two phases can particularly be identified for providing slice continuity in case that the currently associated slice of the UE is not available in the target area, into which it moves.

One phase, if slice HO to the target node 200 is possible, includes the computation of a new metric based on statistics, i.e. the estimation of the SHOF probability used for aiding the decision, whether to enable slice HO or temporary slice support. The metric may have a different effect per slice type, since a time window for failure may be different for different services/slices. Moreover, backhaul (BH) quality and availability, as well as resource availability per slice, may play a role for the decision. In particular, slice- availability information, a slice HO preparation latency, and/or a slice requirement is preferably taken into account by the apparatus 100 for estimating the SHOF probability. Further, preferably RAN context information and/or UE context information is additionally used by the apparatus 100 to determine, whether to perform a slice HO or the temporary slice support. It is noted that SHOF can also be interpreted from a HO success rate perspective. In addition, further mobility-related performance indications can also be taken into account, such as, too late HO or too early HO, and ping pong statistics.

The other phase, if slice HO to the target node 200 is not possible or if it is determined to perform no slice HO based on the estimated SHOF probability, includes an adaptation of RAN configuration parameters, preferably in a slice aware manner, and/or the adaption of the temporary slice support. For example, more than one target node 200 may be enabled to temporarily support a slice, in order to meet per- slice KPIs. This can include temporary slice support by the target node 200 and/or a serving node (aka source node) that may be part of the apparatus 100, in order to decrease the slice HO failure probability.

For the following more detailed description of the two phases, it is assumed that the apparatus 100 comprises at least a serving BS, and that the target node 200 is a target BS.

The phase of estimating the SHOF probability is now described in more detail. The SHOF probability is preferably estimated at the serving BS of the apparatus 100, or at some slice management entity that is included in the apparatus 100. For instance, the apparatus 100 may be the current serving BS of the UE. Alternatively, the apparatus 100 may comprise the serving BS and additionally a slice management entity. The serving BS and/or the slice management entity estimate, what the probability of having a successful slice HO to the target BS 200 is, for example, given admission control information, slice type criticality, and a BH/RAN status.

The SHOF probability is especially used for identifying, whether slice HO can be reasonably (with reasonable chance of success) done or not. The SHOF probability may be estimated based on slice availability information, slice HO preparation latency statistics, for example, in case of Het-Nets, D-RAN, resource availability, and/or slice type requirements (e.g. criticality of the service). An example for high delays, due to excessive signaling is the case of two slices, which are associated with different CN instances/functions, wherein due to the same service support, slice HO is needed from one slice to another. This will provide very high delays for slice re-mapping, due to signaling in both management and control plane in multiple domains (RAN, Transport, and Core). For certain slices (e.g. supporting Ultra Reliable and Low Latency (URLLC) services), this extra delay will be critical, and disruptions in the service may result in a failure to meet the slice SLAs. Hence, the estimation of the SHOF probability helps the apparatus 100 to decide, whether to trigger slice HO or adapt RAN configurations of a target BS 200 and/or the serving BS, in order to temporarily support the slice.

The decision preferably takes into account the following parameters: slice context information, i.e. statistics at the serving BS and/or historical slice HO information. This will help the apparatus 100 to decide also (apart from the decision on slice HO per se), for which slice to start a slice HO process (e.g., according to their SHOF probabilities). RAN context information and/or changes (regarding e.g. RAN capabilities, resource availability, interference levels and coverage) in target and source BS. UE context (e.g. mobility information), which may affect the selection of a slice. The phase of implementing temporary slice support is now described in more detail. The temporary slice support decision, and the execution thereof, is made as described above at the serving BS and/or slice management entity of the apparatus 100. In particular, it is decided whether to request and/or dictate temporary slice support from at least a target BS 200, or to trigger a slice HO.

Slice-aware RAN configuration adaptation at the serving and/or target BS 200 is supported by sending, in the temporary slice support request, information on the slice to be temporary supported, and corresponding RAN configuration parameters. The RAN configuration parameters of the slice to be temporarily supported by the target BS 200 may include context information (e.g. the configuration of protocols / functions, resource preference, 5G Air Interface Variants, antenna and power configurations, multi-connectivity requirement etc., which are required by this slice). Also, slice-related information may be sent to the target BS 200 (e.g. for how much time the temporary slice support is required to last). Slice-related information can also include service requirements that are associated with this slice. This can be beneficial particularly when more than one service are associated with the slice.

The RAN configuration adaptation can have two different outcomes. Firstly, the UE associated with the slice to be supported (and being served by the serving BS), is handed over to the target BS 200, after the temporary support of the slice by the target BS 200. Secondly, the UE is continued to be served by the serving BS, and at the same time also by the target BS 200. This will result in a dual-connectivity (e.g. in a make-before -break fashion) and/or a Coordinate Multipoint (CoMP) case (via Joint Transmission or Dynamic Point Selection), and can have benefit to enhance the performance of the UE (depending e.g. on the slice KPI, e.g. in terms of throughput or reliability) at the edges of the slice coverage.

Fig. 3 shows a specific procedure implemented by the apparatus 100 and the radio access node 200 according to embodiments of the present invention, wherein the temporary slice support is enabled using signaling over Xn interface. The apparatus 100 in this case is a serving BS, namely a gNB (named gNBl) that is currently serving a UE 304. The target node 200 is a target BS, namely a target gNB (named gNB2).

Based on the estimation of the SHOF probability, and preferably on real time RAN/UE context changes (e.g. resource availability changes, backhaul availability and load, interference levels, UE mobility), the temporary slice support is decided by the serving gNB 100, and relevant signaling is exchanged with the target gNB 200 via the Xn interface. The Xn connection refers generally to the communication link between cells, e.g. between one/or more neighboring cell BSs, here specifically between the target gNB 200 and the serving gNB 100. A similar interface between cells in LTE is called X2 interface, and connects eNBs. The Xn connection may further be a direct link, e.g. provided by a fiber optic link or millimeter- wave wireless link, or may be an indirect link, where there could be routers between the cells. Accordingly, the Xn connection can be referred to as a logical interface between the cells, particularly the BSs serving these cells. Target gNB 200 and serving gNB 100 decide, whether to apply the decision and accordingly adapt their RAN configuration parameters, in order to add a new slice at the target gNB 200 for this case. In particular the following process is performed, explained with respect to Fig. 3.

0. Slice information (availability, new instantiation trigger) is sent to RAN nodes (e.g. to the gNBl, gNB2) from a slice management entity 301, which can be a DSS (AN- DSM) and/or a SSS (Cross Domain Management). The SHOF probability is estimated at the serving gNB 100 (optionally together with the target gNB 200) taking into account slice/RAN/UE context information and changes thereof. The estimated SHOF probability is forwarded to the slice management entity 301 (DSS/SSS), optionally together with a slice HO triggering message (to initiate the start of a slice HO procedure, if such is determined). Slice-aware RAN adaptation functionality is then performed. This includes exchanging between the involved serving gNB 100 and target gNB 200, in Xn, a temporary slice support request (Temp_Slice_Support request msg), which generally includes a support requirement parameter and a RAN configuration parameter. In particular, the following parameters are preferably included in the request: a slice ID and/or a network slice selection assistance information parameter, a RAN configuration ID and related context, and/or a time window request (this parameter identifies the amount of time, for which the slice support is required at the target gNB 200). The target gNB 200 responds, in Xn, to the serving gNB 100 by accepting or rejecting or negotiating the request. In the latter case, specifically the at least one support requirement parameter included in the request (e.g. the time duration for the support) is negotiated. The serving gNB 100 and/or the target gNB 200 then send to the UE 304 (preferably in Uu interface or a similar 5G interface) the ID of the target gNB 200, which will temporarily support the slice. The serving gNB 100 and/or the target gNB 200 may send to a CN-C 302 via NG2 Interface aka N2 interface, a temporary slice support notification (Temporary Slice Support Notification msg). A CN-U 303 forwards slice traffic through the involved gNBs (serving gNB 100 and/or target gNB 200) to the UE 304. Fig. 4 shows another specific procedure implemented by the apparatus 100 and the radio access node 200 according to embodiments of the present invention, wherein the temporary slice support is enabled using a slice management domain. The apparatus 100 in this case comprises a serving BS, namely a gNB 400 (named gNBl) currently serving a UE 304, and additionally comprised a slice management entity 401. The target node 200 is a target BS, namely a target gNB (named gNB2).

Based on the SHOF probability estimation, and optionally other factors (e.g. RAN resource situation, context changes), the serving gNB 400 sends to the slice management entity 401 (DSS/SSS) a request to trigger a decision about performing temporary slice support or slice HO. The slice management entity 401 (taking into account the resource/traffic situation in all gNBs) decides on either slice HO or temporary slice support, respectively, and sends an according notification to the CN-C 302. The CN (CN-C 302 or CN-U 303), via NG2, then informs the target gNB 200. Then, for instance, the slice HO process between the gNBs 200 and 400 is initiated, or multi-connectivity via both serving gNB 400 and target gNB 200 is supported.

In particular the following process is performed with respect to Fig. 4:

0. Slice information (availability, new instantiation trigger) is sent to RAN nodes from the slice management entity 401, which can be DSS (AN-DSM) and/or SSS (Cross Domain Management).

1. The SHOF probability is estimated at the serving gNB 400 (optionally in cooperation with the target gNB 200), taking into account slice/RAN/UE context and changes thereof.

2. The estimated SHOF probability is forwarded to the slice management entity 401 (DSS/SSS), optionally together with a slice HO triggering message (that is, indicating that the slice currently associated with the UE is not supported at the target gNB 200) and context changes. Then, the slice management entity 401 decides between slice HO and temporary slice support, and in the latter case a slice-aware RAN adaptation functionality is performed in a more centralized manner. This includes determining at least one support requirement parameters and a RAN configuration parameter. 3. The slice management entity 401 sends via Slice Management-to-CN-C interface the temporary slice support request to the target gNB 200 (via the CN-C 302, named Temporary Slice Support Notification Request in Fig. 4), which generally includes the support requirement parameter and the RAN configuration parameter. Preferably, the following parameters are included in the request: a slice ID and/or a network slice selection assistance information parameter, a RAN configuration ID and related context information, and/or a time window request (this parameter identifies the amount of time, for which the slice support is required at the target gNB 200, and is estimated at the slice management entity 401 based on the slice/service criticality and the UE context information).

4. The CN-C 302 may forward to the serving gNBs 400 and/or target gNB 200 via NG2 interface the temporary slice support request. Alternatively, it may send to at least the target gNB 200 only a temporary slice support notification (as in Fig. 4, named Temporary Slice Support Notification). In this case, the RAN configuration parameters are not included in this notification, but are sent to the target gNB 200, for instance, by the serving gNB 400.

5. Serving gNB 400 and/or target gNB 200 send to the UE 304 (in Uu interface) the ID of the target gNB 200, which will temporarily support the slice. In case of slice HO, the serving gNB 400 and target gNB 200 will start the HO preparation to change the serving cell of the UE 304.

6. CN-U 303 forwards slice traffic through the involved gNBs (serving 200 and/or target 400) to the UE 304.

The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word "comprising" does not exclude other elements or steps and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.