Patent Description:
Over the recent decades, several generations of mobile communication systems have been deployed. While mobile communication systems according to the first generation (<NUM>) are generally based on analog transmission, second generation (<NUM>) mobile communications systems have introduced - by means of the Global System for Mobile Communications (GSM) standard - digital transmission techniques for the first time. The General Packet Radio Service (GPRS) and High Speed Circuit Switched Data (HSCSD) standards - sometimes also classified as <NUM> systems - have been introduced for the transmission of data, and the Enhanced Data Rates for GSM Evolution (EDGE) standard has been developed as an enhancement for the transmission rates in GSM systems. The introduction of the Universal Mobile Telecommunications System (UMTS) has established a third generation (<NUM>) of mobile communication systems which particularly enables data driven services, such as video telephony and mobile broadband Internet access, for example. The UMTS standard has further been enhanced by the High Speed Packet Access (HSPA) and HSPA+ standards. In the following, the term "<NUM>/<NUM>" will be used to denote any standard of a <NUM> or <NUM> system, including the ones mentioned above.

The Long Term Evolution (LTE) standard has been introduced as a fourth generation (<NUM>) mobile communication system and has been enhanced by the LTE Advanced and LTE Advanced Pro standards. The next generation, i.e., the fifth generation (<NUM>), of mobile communications systems is currently under development and generally aims at providing support for enhanced mobile broadband (e.g., for Ultra High Definition (UHD) and virtual presence), support for critical communication (e.g., for robot/drone and emergency communication), support for massive machine type communication (e.g., for e-health applications), support for enhanced network operation (e.g., network slicing and interworking) and support for vehicle-to-everything communication (e.g., for autonomous driving), for example. Much of the standardization work on the above-mentioned standards is and has been done by the 3rd Generation Partnership Project (3GPP).

For the ongoing standardization of <NUM> networks, there has been a general requirement that interworking with <NUM>/<NUM> networks should not be taken into account in order to allow minimizing legacy aspects for <NUM> networks and to avoid the requirement of supporting direct interfaces between <NUM> networks and <NUM>/<NUM> networks, for example. The assumption was that mobility between <NUM> networks and <NUM>/<NUM> networks, if n3G QoS parameters eeded, would generally work via <NUM> networks, i.e., from <NUM> networks to <NUM> networks and then from <NUM> networks to <NUM>/<NUM> networks, and vice versa. In practice, however, mobility may also occur directly between <NUM> networks and <NUM>/<NUM> networks and, also, there may be restrictions which are unacceptable for some deployments which have not yet been discussed or investigated in detail. Direct mobility between <NUM> networks and <NUM>/<NUM> networks may be required due to radio planning reasons of operators, or due to base stations being temporarily out of order, for example.

As an example, it is referred to the deployment scenario illustrated in <FIG> in which a legacy Packet Data Network Gateway (PGW) acts as a common gateway serving the <NUM>/<NUM> network as well as the <NUM> network and a Session Management Function + Packet Data Network Gateway-Control (SMF+PGW-C) entity acts as a common gateway supporting interworking between and serving the <NUM> network as well as the <NUM> network. When a UE moves from the <NUM> network to the <NUM> network and subsequently from the <NUM> network to the <NUM>/<NUM> network in such a scenario, Internet Protocol (IP) address preservation may not be possible in general, so that the UE cannot generally keep its IP address during mobility between the <NUM>, <NUM> and <NUM>/<NUM> networks. Rather, the UE may need to re-initiate respective sessions (e.g., a Packet Data Network (PDN) connection or a Protocol Data Unit (PDU) session through which the UE receives a service from the respective network) each time the UE moves from one network to another, possibly including performing initial IP Multimedia Subsystem (IMS) registrations including full authentication, for example. This may not only result in session breaks but also in additional load in the networks.

<NPL>, describes a method of handling of ethernet and unstructured PDU session types when interworking with EPC. For PDU Sessions with PDU Session type Ethernet or Unstructured, the SMF provides SM Context for non-IP PDN type. The AMF provides the target MME capability to SMF in the request to allow the SMF to determine whether to included EPS Bearer context for non-IP PDN type or not.

<NPL>, describes disclose EPS QoS mapping from <NUM> to <NUM> but does not disclose about mapped QoS flow which corresponds to <NUM>/<NUM> QoS parameters. During PDU session establishment and GBR QoS flow establishment, EPS QoS mappings and EPS Bearer IDs are allocated such that non-GBR flows map to default EPS bearer (which is allocated an EPS bearer ID) and EPS Bearer IDs are allocated for the GBR flows that are mapped to dedicated bearers in EPC.

<CIT>, discloses an interworking method between networks of a UE in a wireless communication system, including: performing a first interworking procedure for changing a network of the UE from a <NUM>-generation core network (5GC) network to an evolved packet core (EPC) network, wherein, when an interface between the 5GC and the EPC networks does not exist, the performing of the first interworking procedure includes: receiving a AMF of the 5GC network; and performing a handover attach procedure in the EPC network based on the first indication.

"<NPL>, describes about connection management which is used to establish and release the Control Plane signalling connection between the UE and the AMF. Further, D4 talks about registration management which is used to register or deregister a UE/user with the 5GS and establish the user context in the 5GS. The Mobility Management functions are used to keep track of the current location of a UE.

<CIT>, describes a method and system for managing a plurality of network bearers in a wireless communication. User Equipment (UE) sends measurement reports to source E-UTRAN (or eNodeB in the E-UTRAN) for initiating Handover (HO). The eNodeB identifies whether an SRVCC operation should be triggered for voice and/or for video based on the Quality of Service (QoS) Class Identifier (QCI) and/or Allocation and Retention Priority (ARP) value associated with bearers and the possibility of SRVCC operation at the MME.

Accordingly, there is a need for a technique which avoids one or more of the problems discussed above, or other problems.

Implementations of the technique presented herein are described herein below with reference to the accompanying drawings, in which:.

Those skilled in the art will further appreciate that the steps, services and functions explained herein below may be implemented using individual hardware circuitry, using software functioning in conjunction with a programmed micro-processor or general purpose computer, using one or more Application Specific Integrated Circuits (ASICs) and/or using one or more Digital Signal Processors (DSPs). It will also be appreciated that when the present disclosure is described in terms of a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories are encoded with one or more programs that perform the steps, services and functions disclosed herein when executed by the one or more processors.

<FIG> schematically illustrates an exemplary composition of a network node <NUM> for preparing UE mobility to a <NUM>/<NUM> network for a UE moving from a <NUM> network, optionally via a <NUM> network, to the <NUM>/<NUM> network. The network node <NUM> comprises at least one processor <NUM> and at least one memory <NUM>, wherein the at least one memory <NUM> contains instructions executable by the at least one processor <NUM> such that the network node <NUM> is operable to carry out the method steps described herein below.

It will be understood that the network node <NUM> may be implemented as a physical computing unit as well as in the form of a function or a virtualized computing unit, such as a virtual machine, for example. It will further be appreciated that the network node <NUM> may not necessarily be implemented as a standalone computing unit, but may be implemented as components - realized in software and/or hardware - residing on multiple distributed computing units as well, such as in a cloud computing environment, for example.

<FIG> schematically illustrates an exemplary composition of a UE <NUM> for implementing UE mobility to a <NUM>/<NUM> network, wherein the UE <NUM> moves from a <NUM> network, optionally via a <NUM> network, to the <NUM>/<NUM> network. The UE <NUM> comprises at least one processor <NUM> and at least one memory <NUM>, wherein the at least one memory <NUM> contains instructions executable by the at least one processor <NUM> such that the UE <NUM> is operable to carry out the method steps described herein below.

<FIG> schematically illustrates an exemplary modular composition of the network node <NUM> and <FIG> illustrates a corresponding method which may be performed by the network node <NUM>. The basic operation of the network node <NUM> will be described in the following with reference to both <FIG> and <FIG>.

In step S302, a determining module <NUM> of the network node <NUM> may determine whether at least one condition for triggering providing one or more <NUM>/<NUM> QoS parameters to the UE <NUM> is satisfied when the UE <NUM> is in the <NUM> network. If it is determined that the at least one condition is satisfied, a triggering module <NUM> of the network node <NUM> may trigger, in step S304, providing the one or more <NUM>/<NUM> QoS parameters to the UE <NUM>, wherein providing the one or more <NUM>/<NUM> QoS parameters to the UE <NUM> is required to hand over at least one QoS flow established between the UE <NUM> and the <NUM> network to the <NUM>/<NUM> network when the UE <NUM> moves to the <NUM>/<NUM> network.

The UE <NUM> may move directly from the <NUM> network to the <NUM>/<NUM> network or the UE <NUM> may move to the <NUM>/<NUM> network via the <NUM> network. When the UE <NUM> moves directly from the <NUM> network to the <NUM>/<NUM> network, the at least one QoS flow may be handed over to at least one corresponding PDP context in the <NUM>/<NUM> network (e.g., for each QoS flow, a corresponding PDP context may be established in the <NUM>/<NUM> network) and, when the UE <NUM> moves from the <NUM> network to the <NUM>/<NUM> network via the <NUM> network, the at least one QoS flow may first be handed over to at least one corresponding bearer in the <NUM> network (e.g., for each QoS flow, a corresponding bearer may be established in the <NUM> network) and the at least one corresponding bearer may then be handed over to at least one corresponding PDP context in the <NUM>/<NUM> network when the UE <NUM> moves from the <NUM> network to the <NUM>/<NUM> network (e.g., for each bearer, a corresponding PDP context may be established in the <NUM>/<NUM> network). The at least one QoS flow may belong to a PDU session established between the UE <NUM> and the <NUM> network and the at least one bearer may belong to a corresponding PDN connection established between the UE <NUM> and the <NUM> network.

Since, when moving to the <NUM>/<NUM> network, a PDP context may not be activated for the at least one QoS flow (or the at least one corresponding bearer, respectively), providing the one or more <NUM>/<NUM> QoS parameters to the UE <NUM> prior to moving to the <NUM>/<NUM> network may enable transferring the at least one QoS flow (or the at least one corresponding bearer, respectively) into a PDP context of the <NUM>/<NUM> network, as described above. The one or more <NUM>/<NUM> QoS parameters may in other words be required to establish at least one PDP context in the <NUM>/<NUM> network which corresponds to the at least one QoS flow established between the UE <NUM> and the <NUM> network. Transferring (i.e., handing over or "moving") the respective QoS flow (or the at least one corresponding bearer, respectively) into a corresponding PDP context may involve mapping an IP address and an APN associated with the PDU session to which the at least one QoS flow belongs (or an IP address and an APN associated with the PDN connection to which the at least one corresponding bearer belongs, respectively) to a corresponding IP address and a corresponding APN associated with the newly established PDP context. IP address preservation may thus be enabled when moving between the <NUM> network and the <NUM>/<NUM> network (optionally, via the <NUM> network).

The at least one QoS flow established between the UE <NUM> and the <NUM> network may be allocated on at least one common network entity that supports interworking between the <NUM> network and the <NUM> network, such as an SMF+PGW-C acting as common gateway for both the <NUM> and the <NUM> network, for example. The network node <NUM> may in fact be the SMF+PGW-C, but it will be understood that the technique presented herein may be performed by any other appropriate network node of the <NUM> network as well, such as an AMF, for example. The common network entity, particularly the SMF+PGW-C, may have an interface to at least one of an SGSN of the <NUM>/<NUM> network (e.g., a Gn/Gp interface to the SGSN) and an SGW of the <NUM>/<NUM> network. In case of the SGW, the common network entity may have an S5/S8 interface to the SGW which, in turn, may have an S4 interface to the SGSN, for example. It will be understood that, even if the SMF+PGW-C supports such interfaces to the <NUM>/<NUM> network, the UE may only reuse QoS flows (or bearers) as PDP contexts when moving from the <NUM> (or <NUM>) network to the <NUM>/<NUM> network when the relevant <NUM>/<NUM> QoS parameters are available to the UE.

The network node <NUM> may be configured to keep track of the source access technology and the target access technology in the mobility scenario so that, depending on the particular source access technology and target access technology (e.g., respective RAT types), the network node <NUM> may decide on triggering providing the one or more <NUM>/<NUM> QoS parameters to the UE <NUM>, as described above. Mobility from the <NUM> network to the <NUM> network as well as from the <NUM> network to the <NUM>/<NUM> network may involve an IRAT handover, for example, but it will be understood that the technique presented herein may be employed in all other cases of UE mobility between the <NUM> network, the <NUM> network and the <NUM>/<NUM> network as well. In either case, mobility may take place in both idle mode and connected node. As an example, the technique may be applied to cases of idle mode mobility when the UE <NUM> reselects the RAT or to cases of redirects, e.g., when the RAN directs the UE <NUM> to a different RAN which employs a different RAT. An NG-RAN of a <NUM> network may direct the UE <NUM> to a GERAN of a <NUM> network, a UTRAN of a <NUM> network, or an E-UTRAN of a <NUM> network, for example.

The at least one condition for triggering providing the one or more <NUM>/<NUM> QoS parameters to the UE <NUM> determined in step S302 may refer to at least one of the following. In one variant, triggering providing the one or more <NUM>/<NUM> QoS parameters to the UE <NUM> may be conditionally performed when the UE <NUM> is determined to have <NUM>/<NUM> capabilities (e.g., when the UE <NUM> is capable of attaching to a <NUM>/<NUM> network). In other words, the presence of <NUM>/<NUM> capabilities of the UE <NUM> may be used as a condition for triggering providing the one or more <NUM>/<NUM> QoS parameters to the UE <NUM> so that triggering providing the one or more <NUM>/<NUM> QoS parameters to the UE <NUM> may only be performed when the UE <NUM> is determined to have <NUM>/<NUM> capabilities. An indication that the UE <NUM> has <NUM>/<NUM> capabilities may be obtained from the UE <NUM>. The network node <NUM> may obtain this indication directly from the UE <NUM> (e.g., in a signaling procedure involving both the UE <NUM> and the network node <NUM>) or in an indirect manner (e.g., from another network node which obtained the indication from the UE <NUM> previously). For example, the indication that the UE <NUM> has <NUM>/<NUM> capabilities may be obtained during an attach procedure performed by the UE <NUM> with the <NUM> network or during a PDU session configuration procedure performed by the UE <NUM> with the <NUM> network. The PDU session configuration procedure may correspond to a PDU session establishment procedure or a PDU session modification procedure, for example. The indication may be conveyed in the form of a network capability information element as part of the UE network capabilities provided from the UE <NUM> to the network, for example.

In another variant, the network node <NUM>, especially when the network node <NUM> is an AMF, may or may not trigger providing the one or more <NUM>/<NUM> QoS parameters to the UE <NUM> per area or per PLMN, depending on the operator deployment. Triggering providing the one or more <NUM>/<NUM> QoS parameters to the UE <NUM> may thus be conditionally performed depending on at least one of an area in which the UE <NUM> is located and a PLMN with which the UE <NUM> is associated.

Alternatively, triggering providing the one or more <NUM>/<NUM> QoS parameters to the UE <NUM> may be performed independently from whether the UE <NUM> has <NUM>/<NUM> capabilities as well as independently from the area or the PLMN. In such a case, the network node may always provide the one or more <NUM>/<NUM> QoS parameters to the UE <NUM> and, if the UE <NUM> is not <NUM>/<NUM> capable (e.g., if the UE <NUM> does not support <NUM>/<NUM> QoS parameters), the UE <NUM> may simply ignore the received <NUM>/<NUM> QoS parameters. The UE <NUM> may in other words only use the received <NUM>/<NUM> QoS parameters if the UE <NUM> understands them.

The one or more <NUM>/<NUM> QoS parameters may correspond to one or more R99 QoS parameters, for example, and may include at least one of a traffic class, a delivery order, an indication of delivery of erroneous SDUs, a maximum SDU size, a maximum bit rate for uplink, a maximum bit rate for downlink, a residual BER, an SDU error ratio, a transfer delay, a traffic handling priority, an ARP, a guaranteed bit rate for uplink, and a guaranteed bit rate for downlink. The one or more <NUM>/<NUM> QoS parameters may be mapped from one or more corresponding <NUM> QoS parameters, e.g., from one or more QoS parameters of the at least one QoS flow established between the UE <NUM> and the <NUM> network. More specifically, when the UE <NUM> moves directly from the <NUM> network to the <NUM>/<NUM> network, each of the one or more <NUM> QoS parameters of the at least one QoS flow may be mapped to a corresponding <NUM>/<NUM> QoS parameter among the one or more <NUM>/<NUM> QoS parameters and, when the UE <NUM> moves from the <NUM> network to the <NUM>/<NUM> network via the <NUM> network, each of the one or more <NUM> QoS parameters of the at least one QoS flow may first be mapped to a corresponding <NUM> QOS parameter, such as an EPS bearer QoS parameter, and each of the one or more <NUM> QoS parameters may then be mapped to a corresponding <NUM>/<NUM> parameter among the one or more <NUM>/<NUM> QoS parameters when the UE <NUM> moves from the <NUM> network to the <NUM>/<NUM> network. In one variant, the one or more <NUM>/<NUM> QoS parameters may be provided to the UE <NUM> in a single message together with the one or more <NUM> QoS parameters (or the <NUM> QoS parameters, respectively) and, in another variant, the one or more <NUM>/<NUM> QoS parameters may be provided to the UE <NUM> in a separate message, i.e., separate from the <NUM> QoS parameters (or the <NUM> QoS parameters, respectively). The one or more <NUM>/<NUM> parameters may be mapped during establishment of the at least one QoS flow in the <NUM> network, for example.

<FIG> schematically illustrates an exemplary modular composition of the UE <NUM> and <FIG> illustrates a corresponding method which may be performed by the UE <NUM>. The basic operation of the UE <NUM> will be described in the following with reference to both <FIG> and <FIG>. This operation may be complementary to the operation of the network node <NUM> described above in relation to <FIG> and <FIG> and, as such, aspects described above with regard to the operation of the UE <NUM> may be applicable to the operation of the UE <NUM> described in the following as well. Unnecessary repetitions are thus omitted.

In step S402, a receiving module <NUM> of the UE <NUM> may receive one or more <NUM>/<NUM> QoS parameters from a network node <NUM> of the <NUM> network. In step S404, a using module <NUM> of the UE <NUM> may use the one or more <NUM>/<NUM> QoS parameters to hand over at least one QoS flow established between the UE <NUM> and the <NUM> network to the <NUM>/<NUM> network when the UE <NUM> moves to the <NUM>/<NUM> network.

As described above, the one or more <NUM>/<NUM> QoS parameters may be required to establish at least one PDP context in the <NUM>/<NUM> network which corresponds to the at least one QoS flow established between the UE <NUM> and the <NUM> network. An indication that the UE <NUM> has <NUM>/<NUM> capabilities may be sent to the <NUM> network, wherein the indication that the UE <NUM> has <NUM>/<NUM> capabilities may be sent during an attach procedure performed by the UE <NUM> with the <NUM> network or during a PDU session configuration procedure performed by the UE <NUM> with the <NUM> network. The one or more <NUM>/<NUM> QoS parameters may be received from the network node <NUM> in a single message together with one or more <NUM> QoS parameters, for example.

<FIG> illustrates a signaling diagram of an exemplary PDU session establishment procedure performed by a UE with a <NUM> network. It will be understood that this procedure is merely exemplary and that the technique presented herein may be employed with other procedures as well. It will further be understood that the procedure shown in <FIG> is simplified and mainly focuses on those aspects which are relevant for understanding the technique presented herein.

The procedure assumes that the UE has already registered on the AMF. In step <NUM>, the UE initiates the PDU session establishment procedure by sending a PDU Session Establishment Request to the AMF. This request includes an indication that the UE has <NUM>/<NUM> capabilities (e.g., that the UE supports R99 QoS parameters), e.g., in the form of a new network capability information element or as additional information in an existing network capability information element. The AMF then selects, in step <NUM>, an SMF+PGW-C and invokes, in step <NUM>, the Nsmf_PDUSession__CreateSMContext Request operation, as part of which the SMF+PGW-C receives the indication of the UE <NUM>/<NUM> capabilities. The SMF+PGW-C then responds by invoking the Nsmf_PDUSession_CreateSMContext Response operation in step <NUM>. In step <NUM>, the SMF+PGW-C selects a corresponding User Plane Function + Packet Data Network Gateway-User (UPF+PGW-U) entity and may perform, in steps <NUM> and <NUM>, an N4 Session Establishment procedure with the selected UPF+PGW-U.

In step <NUM>, the SMF+PGW-C invokes the Namf_Communication_N1N2MessageTransfer operation, as part of which not only regular <NUM> QoS parameters for the QoS flows associated with the PDU session being established are sent to the AMF, but also corresponding <NUM>/<NUM> QoS parameters (e.g., R99 QoS parameters) which may be mapped from the <NUM> QoS parameters, as described above. In step <NUM>, the AMF sends this information to the NG-RAN within the N2 PDU Session Request, from where this information is then forwarded to the UE by an Access Network specific signaling exchange including a PDU Session Establishment Accept in step <NUM>. At this point, the UE receives the <NUM>/<NUM> QoS parameters and stores the received parameters for later use when moving to the <NUM>/<NUM> network, i.e., in order to be able to activate PDP contexts in the <NUM>/<NUM> network that correspond to the QoS flows associated with the PDU session being established, as described above. In step <NUM>, the NG-RAN sends an N2 PDU Session Request Acknowledgment to the AMF.

<FIG> illustrates a signaling diagram of an exemplary PDU session modification procedure performed by a UE with a <NUM> network. Similar to <FIG>, it will be understood that this procedure is merely exemplary and that the procedure is simplified and focuses on those aspects which are relevant for understanding the technique presented herein. The procedure may be performed when one or more regular <NUM> QoS parameters exchanged between the UE and the <NUM> network are modified.

In step <NUM>, the UE initiates the PDU session modification procedure by sending a PDU Session Modification Request to the AMF. This request includes an indication that the UE has <NUM>/<NUM> capabilities (e.g., that the supports R99 QoS parameters), e.g., in the form of a new network capability information element or as additional information in an existing network capability information element. The AMF then invokes, in step <NUM>, the Nsmf PDUSession_UpdateSMContext operation, as part of which the SMF+PGW-C receives the indication of the UE <NUM>/<NUM> capabilities. The SMF+PGW-C then responds by invoking the Nsmf_PDUSession_UpdateSMContext Response operation in step <NUM>. In step <NUM>, the SMF+PGW-C invokes the Namf Communication_N1-N2MessageTransfer operation, as part of which not only regularly updated <NUM> QoS parameters for the QoS flows associated with the PDU session are sent to the AMF, but also corresponding <NUM>/<NUM> QoS parameters (e.g., R99 QoS parameters) which may be mapped from the updated <NUM> QoS parameters, as described above. In step <NUM>, the AMF sends this information to the NG-RAN within the N2 PDU Session Request, from where this information is forwarded to the UE by an Access Network specific signaling exchange including a PDU Session Modification Command / Acknowledgment in step <NUM>. At this point, the UE receives the <NUM>/<NUM> QoS parameters and stores the received parameters for later use when moving to the <NUM>/<NUM> network, i.e., in order to be able to activate PDP contexts in the <NUM>/<NUM> network that correspond to the QoS flows associated with the PDU session being established, as described above. In step <NUM>, the NG-RAN sends an N2 PDU Session Response to the AMF.

As an alternative, the SMF+PGW-C (or the AMF) could include the <NUM>/<NUM> QoS parameters in a PDU session modification procedure even if the UE has not indicated that it has <NUM>/<NUM> capabilities (in accordance with step <NUM> above). A UE not supporting <NUM>/<NUM> QoS parameters may then simply ignore the received parameters.

As has become apparent from the above, the present disclosure provides a technique for preparing UE mobility to a <NUM>/<NUM> network for a UE moving from a <NUM> network, optionally via a <NUM> network, to the <NUM>/<NUM> network. According to the technique, one or more <NUM>/<NUM> QoS parameters may be provided to the UE which are required to hand over at least one QoS flow established between the UE and the <NUM> network to the <NUM>/<NUM> network when the UE moves to the <NUM>/<NUM> network. Handing over a respective QoS flow to a corresponding PDP context may involve mapping an IP address and an APN associated with the PDU session to which the at least one QoS flow belongs to a corresponding IP address and a corresponding APN associated with the newly established PDP context, so that IP address preservation may be enabled between the <NUM> network and the <NUM>/<NUM> network (optionally, via the <NUM> network). The UE may thus keep its IP address during mobility among the <NUM>, <NUM> and <NUM>/<NUM> networks and the need to re-initiate respective sessions (e.g., PDN or PDU sessions) each time the UE moves from one network to another, possibly including performing initial IMS registrations including full authentication, may be avoided. Corresponding load in the networks as well as session breaks including drop of packet connectivity may thus be prevented.

Claim 1:
A method for preparing User Equipment, UE, mobility to a <NUM>/<NUM> network for a UE (<NUM>) moving from a <NUM> network, optionally via a <NUM> network, to the <NUM>/<NUM> network, the method being performed by a network node (<NUM>) of the <NUM> network and being further characterized by: triggering (S304) providing one or more <NUM>/<NUM> Quality of Service, QoS, parameters to the UE (<NUM>) required to hand over at least one QoS flow established between the UE (<NUM>) and the <NUM> network to the <NUM>/<NUM> network when the UE (<NUM>) moves to the <NUM>/<NUM> network, wherein the one or more <NUM>/<NUM> QoS parameters are required to establish at least one Packet Data Protocol, PDP, context in the <NUM>/<NUM> network which corresponds to the at least one QoS flow established between the UE (<NUM>) and the <NUM> network, wherein the one or more <NUM>/<NUM> QoS parameters are mapped from one or more corresponding <NUM> QoS parameters.