Managing data transmission in a wireless network

Abstract

A method performed by a first network node, for managing data transmission in a wireless network, and an apparatus for a first network node, are disclosed. The method comprises: during or following a

Description

FIELD OF THE INVENTION The present invention generally relates to methods and apparatuses for managing data transmission in a wireless network. BACKGROUND Wireless communication systems are deployed to address a wide range of applications, including mobile broadband, massive machine type communications, and Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange different types of data content (e.g., video, voice, messaging...) over a radio access network (RAN) through one or more base stations. Examples of such wireless multiple-access communication systems include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourth generation (4G) Long Term Evolution (LTE) and (more recently) fifth-generation (5G) New Radio (NR) systems, or systems based on IEEE 802.11 standards, such as Wi-Fi. Among the requirements for5G NR, there are service requirements related to extended reality (XR). XR applications are defined in 3GPP document RP-2200285 as “various types of augmented, virtual, and mixed environments, where human-to-machine and human-to-human communications are performed with the assistance of handheld and wearable end user devices”. Various use cases can be found in 3GPP document TR-26.928. XR applications may involve interactions between a wearable device (e.g., a 3D helmet or augmented reality glasses) and an application server. The wearable device and the application server can be connected through a local Network (e.g., a wireless LAN) or cellular network (e.g., 3GPP 5G cellular network, the application server being connected to a 5G core network component of the network).XR applications (e.g., relating to cloud gaming) can require transferring compressed video data, audio data from the server to the UE and positioning information from the UE to the server. XR applications, such as those relating to virtual reality, can involve transferring compressed video data, audio data and various information from the server to the wearable device. XR applications, such as those relating to augmented reality (AR), may involve transferring compressed video data, audio data and various information exchanged to and from the wearable device and the server. The information exchanged to and from the UE (e.g., wearable device) and the server may be referred to as ‘application data’, and it may comprise one or more images, video data, audio data, and position information etc. The video and audio data are transferred between the UE (e.g., wearable device) and the server using media transport protocols such as RTP (Real Time Protocol, RFC 3550), SRTP (Secured RTP, RFC 3711), HTTP (Hyper Text Transfer Protocol, RFC 2616-7540) or QUIC (RFC 8999,9000, 9001 and 9002). Video encoding and decoding can be performed according to various formats including MPEG2, H.264, H.265, HEVC, etc. In particular, applications generate data (e.g., application data) in the form of encoded video, audio, or position information etc. The application data is primarily arranged in data packets by the application. For example, an application data packet representing one unit of information may be generated at the application level. The network used to transport the application data can experience perturbation and congestion. It is therefore possible that some PDUs of a PDU Set are missing, or are late, at the receiving side (e.g., at the UE PDU layer during downlink, and at the core network user plane function (UPF) during uplink). Some video decoder implementations require that a complete application data packet (e.g., complete PDU Set) is received on time in order to adequately decode a video. Some other implementations can tolerate late arrival of data packets, or partial delivery of a data packet. For example, these implementations rely on Forward Error Correction (FEC) technology or concealment techniques. The PDU Sets are mapped on QoS flows (SDAP layer), QoS flows are mapped on DRBs (PDCP layer), DRBs are mapped on RLC channels (RLC layer), RLC channels are mapped on logical channels (MAC layer). The MAC layer implements a reliability mechanism called hybrid automatic repeat request (ARQ), which provides a given level of reliability that can be improved by the RLC layer if needed. The RLC layer can be operated in an acknowledge mode, which implements an additional ARQ mechanism that further enhances the reliability of the transmission. Despite the reliability mechanisms implemented in lower layers, it may happen that the radio conditions become so degraded that the application decoders are no longer able to function properly. So, for an application that supports different encoder rates, the gNB is able to recommend a different bitrate to the UE, so that the UE may attempt to change the application encoder setting to follow the gNB recommendation, and therefore allow the application to function properly at lower bitrate. However, the UEs are mobile and may be handed over to different gNBs with different radio conditions during the lifetime of the application. Therefore, there is a need to provide UE bitrate related information to different gNBs as part of the mobility procedures. SUMMARY In general, the present disclosure is directed towards providing UE QoS flow related information to different gNBs, as part of or following mobility procedures. In accordance with a first aspect of the invention, there is provided a method, performed by a first network node, for managing data transmission in a wireless network. The method comprises, during or following a mobility procedure between a user equipment, UE, and the first network node, receiving information indicating whether one or more attributes of a Quality of Service, QoS, flow, that has been configured for the UE, are able to be adapted. In accordance with a second aspect of the invention, there is provided a method, performed by a user equipment, UE, for managing data 2 transmission in a wireless network. The method comprises following a mobility procedure between the UE and a first network node, adapting one or more attributes of a Quality of Service, QoS, flow that has been configured for the UE. In accordance with a third aspect of the invention, there is provided a method, performed by second network node, for managing data transmission in a wireless network. The method comprises, during or following a mobility procedure between a user equipment, UE, and a first network node, transmitting information, to the first network node, indicating whether one or more attributes of a Quality of Service, QoS, flow that has been configured for the UE, are able to be adapted. In accordance with a fourth aspect of the invention, there is provided a computer program. The computer program comprises instructions which, when the program is executed by at least one processor unit, cause the at least one processing unit to carry out a method according to any one of the first, second and third aspects. In accordance with a fifth aspect of the invention, there is provided a computer-readable medium carrying a computer program according to the first aspect. In accordance with a sixth aspect of the invention, there is provided an apparatus for a first network node. The apparatus comprises one or more processing units configured to perform a method according to the first aspect. In accordance with a seventh aspect of the invention, there is provided an apparatus for a user equipment. The apparatus comprises one or more processing units configured to perform a method according to the second aspect. In accordance with an eighth aspect of the invention, there is provided an apparatus for a second network node. The apparatus comprises one or more processing units configured to perform a method according to the third aspect. Further example features of the invention are described in other independent and dependent claims. Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus / device / unit aspects, and vice versa. Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other aspects of the invention, there are provided a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any aspect or example described above and a computer readable storage medium carrying the computer program. The preceding summary is provided for purposes of summarising some examples to provide a basic understanding of aspects of the subject matter described herein. Accordingly, the abovedescribed features should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Moreover, the above and / or proceeding examples may be combined in any suitable combination to provide further examples, except where such a combination is clearly 3 impermissible or expressly avoided. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following text and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Different aspects of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 is a schematic diagram of a communication system in which the present invention may be implemented according to one or more example embodiments; Figure 2 is a block schematic diagram of a UE device; Figures 3a, 3b, 3c and 3d show a simple example of how “XR rate control” works for a single UE, a single gNB, and a single QoS flow in the uplink direction; Figure 4 is a block schematic diagram of an example network node or base station in accordance with one or more embodiments of the invention; Figure 5 is a simplified schematic diagram showing an example of a network system; Figure 6 is a schematic and simplified diagram showing an example message flow for performing a Xn handover of a UE, in accordance with one or more embodiments of the invention; Figure 7 is a schematic and simplified diagram showing an example message flow for performing a NG handover of a UE, in accordance with one or more embodiments of the invention; Figure 8 is a schematic and simplified diagram showing an example message flow for establishing dual-connectivity at a UE, in accordance with one or more embodiments of the invention; Figure 9 is a schematic and simplified diagram showing an example message flow for connection reestablishment of a UE, in accordance with one or more embodiments of the invention; Figure 10a is a flowchart of an example method performed by a first network node for managing data transmission in a wireless network in accordance with one or more embodiments of the invention; Figure 10b is a flowchart of an example method, performed by a user equipment, UE, for managing data transmission in a wireless network in accordance with one or more embodiments of the invention; Figure 10c is a flowchart of an example method performed by a second network node for managing data transmission in a wireless network in accordance with one or more embodiments of the invention. DETAILED DESCRIPTION Aspects and embodiments of the present disclosure will now be discussed with reference to the accompanying figures. Further aspects and embodiments will be apparent to those skilled in the art. Figure 1 illustrates an example wireless communication system 100, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system supporting extended reality service (XR). Although in the following description, embodiments, and examples of 4 embodiments of the present disclosure will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present disclosure is limited to 5G NR systems and may be used in any wireless communication systems supporting XR or similar service. The system 100 comprises a User Equipment (UE) 101,151 which may be for instance virtual reality helmets or extended reality wearables like glasses, served by a base station 110 to communicate with a core network, such as the 5G core network 102. The UE may be any wireless device, such as a wireless communication device or apparatus or terminal, loT device, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, user device (e.g., smart phone, laptop, mobile phone, tablet, camera, game console, wearable device), capable of wireless communication with one or more core networks via one or more Radio Access Networks. The base station 110 is a network node which provides an access point to the core network for a UE and is part of the Radio Access Network (RAN) composed of the base stations 110, and 111. In NR, base stations are referred to as next-generation Node Bs (gNBs), the RAN is a Next Generation (NG) RAN and the core network is referred to as the 5GC. In the following, the terms RAN node, base station and gNB will be used interchangeably. The base stations 110 and 111 are interconnected by means of the Xn interface (e.g., as specified in the 3GPP document TS 38.423) implemented on the wired or wireless link 130. Each base station is connected to the core network 102 by means of the NG interface (e.g., as specified in the 3GPP document TS 38.413) implemented on the wired or wireless links 140 and 141. Each of these base stations controls one or multiple cells. For instance, the base station 110 controls the cell 120, and the base station 111 controls the cell 121. A cell is a geographical area of a radio network defined by the frequency used in the cell to transmit data. The cell can be uniquely identified by a UE from an identification that is broadcasted over a geographical area. Each base station 110, 111 can serve several UEs 101, 151. Once a UE has established a RRC connection with a base station, the base station, to which the UE is connected, is referred to as the serving base station (or source base station) of the UE and the cell which is controlled by the serving base station, and on which the UE camps, is referred to as the serving cell. The interface between a gNB and a UE is the Uu interface using the protocol sublayers Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), Physical (PHY) in the user plane, and the protocol sublayers Radio Resource Control (RRC), PDCP, RLC, MAC, PHY in the control plane. It is assumed that the UE 101 is receiving and / or sending XR data of one or more unicast, broadcast or multicast XR sessions generated and / or destinated to the XR application server 103. XR data is provided to the base station 111 (which is the base station controlling the cell 121 on which the UE 101 is attached) through the core network 102 (e.g., through the Data Network 160 and the User Plane Function 161) and the transport bearer (also known as a GTP-U tunnel) 106 over the link 141. Then, XR data is transmitted by the base station 111 to the UE 101 through the Data Radio Bearer (DRB) 154. Figure 1 also shows the UE 151 receiving data through DRB 153. A radio bearer is a set of PHY (layer 1) and MAC (layer 2) parameters allowing higher layer data connection between a UE 5 and a gNB. Multiple types of radio bearers are defined in 5G NR: the Signalling Radio Bearer (SRB) for the control plane, the Data Radio Bearer (DRB) allowing point-to-point communication with one UE in the user plane (e.g., unicast), and the MBS radio bearer (MRB) allowing point-to-point communication and point-to-multipoint communication with multiple UEs (e.g., multicast / broadcast), also in the user plane. Figure 2 is a block schematic diagram of a UE device 205, like the UE 101 or UE 151 in the Figure 1, in which the present disclosure may be implemented according to one or more embodiments of the disclosure. The UE includes components for transmitting and receiving communications, for example including at least one of a UE communication manager 220, an I / O controller 255, a transceiver 235, a set of antennas 245, a storage device (e.g., memory) 225, and a processor (CPU: Central Processing Unit) 215. All these elements may communicate with each other. The memory 225 includes Random Access Memory (RAM), Read Only Memory (ROM), or a combination of both. Alternatively, or additionally, the memory 225 may comprise a mass storage device, such as a disk, or a Solid-State Drive (SSD). Basic Input Output System (BIOS) Instructions may be stored within the memory 225. The processor 215 is configured to execute machine readable instructions. Execution of these machine-readable instructions causes the UE to perform various functions. These functions may relate to transmission and / or interaction with peripheral devices like for instance a keyboard, a screen, a mouse, etc. (not shown in Figure 2). The processor may run an operating system, such as iOS, Windows, Android, etc. The processor 215 may be a single processor or may comprise two or more processors carrying out the processing required for the operation of the UE 205. The I / O controller 255 allows these interactions with external peripherals by providing the hardware required and by managing input and output signals. The I / O controller 255 may for example interact with all or part of an image capture device, an image rendering device, an audio capture device, an audio rendering device, ora sensor device able to determine (e.g., identify) the use position. The transceiver 235 is configured to provide bi-directional wireless communication with other wireless devices. For example, it provides the necessary modems (e.g., routers) and frequency shifters necessary to connect to one or more wireless networks, such as Wi-Fi, Bluetooth, LTE, 5G NR, etc. The transceiver 235 may comprise a PDCP transmitter and a PDCP receiver. The PDCP transmitter and the PDCP receiver may be implemented by the processor 215. The PDCP transmitter and the PDCP receiver may be a software only function implemented by the processor 215. The radio communications use the antenna set 245 adapted to the spectrum of the frequency transposed signals, issued from the baseband modems. The antenna set 245 may be limited to one antenna, but preferably it contains several antennas, in order to provide beamforming capability. The UE communication manager 220 controls the communication establishment of the UE to a radio access network (RAN). It may also be configured to control the control and release of the UE from the RAN. The UE regularly receives from the base station (e.g., gNB) an indication of the slots which are available for communication between the UE and the base station. Accordingly, the 6 UE is able to determine when and at what frequency it should expect to receive incoming data (e.g., from the gNB). Further, the UE can identify when to send outgoing data, and at what frequency. The UE can determine the transmission / reception of data whether the data belongs to the control plane or the data plane. In one example implementation, the UE communication manager 220 implements the Uu interface. The CPU 215, and the I / O Controller 255 may provide means to control the bitrate of user application such as video codec, audio codec or haptic codec, the memory 255 may include information associated with UE bitrate such as “XR rate control”, “XR rate control status”, and “QoS Flow Level QoS Parameters” information elements. Specific program elements / sub-routines stored in program memory may include one or more of the following: elements for sending a query to a gNB or for receiving recommendation from a gNB (see, for example, the methods described below with reference to figures 6-9). Figures 3a, 3b, 3c and 3d showa simple example of how “XR rate control” works fora single UE, a single gNB, and a single QoS flow in the uplink direction. Firstly, Figure 3a shows the establishment of a PDU session (according to TS 23.502) between a UE 3000, a gNB 3010, a core network 3020 and an application server 3030. During the PDU session establishment (3031) an “allocated bitrate” is determined (e.g., identified) and shared among the core network 3020, the gNB 3010 and the UE 3000. The “allocated bitrate” corresponds to the bitrate that has been allocated to the UE fora dedicated QoS flow. It may be found in an information element, for example the “QoS Flow Level QoS Parameters”. Next, Figure 3b shows that UE 3000 has set its application encoder to deliver data at the “allocated bitrate” (3051). The gNB 3010 sends uplink scheduling requests 3050 allocating radio resources according to “allocated bitrate” forthe UE uplink communication. The UE sends the encoder generated data at the “allocated bitrate” on the uplink (3060). Since the uplink and application encoder have similar bitrates, the user 3040 experience is positive, and the user 3040 obtains good quality application data. Next, Figure 3c shows that gNB 3010 is experiencing congestion on the uplink radio. Thus, the gNB 3010 can only schedule UE uplink (3070) at an R1 bitrate, the value of R1 being less than the “allocated bitrate” value. The UE always follows the scheduling request from gNB, so the UE sends encoder generated data on the uplink at the R1 bitrate (3090), even if the application encoder is generating data at “allocated bitrate” (3051). The fact that the application encoder generates more data than the UE can handle in the uplink results in a degradation of the application quality at the user end 3041. As a result, data is discarded at UE, and some data arrives out of delay budget at the application. This may generate application stalling, frame loss, synchronization loss and degrade the experience of user 3041. To correct this, the gNB sends a “recommended bitrate” message 3080 to the UE with R1 as a bitrate target forthe application encoder. Next, Figure 3d, shows the case where the UE supports XR rate control, and the UE succeeds in changing the application encoder bitrate to R1 (3052). In this case the uplink and 7 application encoder have similar bitrates, and the experience of the user 3042 is improved in comparison to user 3041. The application bitrate is less than the “allocated bitrate”, so the perceived application quality is less than expected for user 3042, but application stalling, frame losses, synchronization loss no longer occur. This mechanism may be referred to as “graceful degradation”. Figure 4 is a block schematic diagram of an example network node or RAN node or base station 400, such as base stations or gNBs or WAB nodes shown in Figure 1, in accordance with one or more embodiments of the invention. Each of a WAB node 110, 120a, 120b, 130, 140, or 150 of figure 1 may comprise the elements of the base station of figure 4. Also, the satellite 160 of figure 1 may comprise the elements of the base station of figure 4. In the following description, the network node 400 will be referred to generally as a base station. As will be apparent to a skilled person, Figure 4 is a simplified schematic diagram and shows only some of the functional components of an example base station 400 for use in describing the one or more embodiments of the invention. The base station 400 includes components for transmitting and receiving communications. As shown in Figure 4, the base station 400 includes a processing unit 402, a wireless interface 404, one or more antennas 410, a network interface 432, and memory 418. The network interface 432 manages communications of the base station 400 with the core network, other base stations, local network functions (like UPF), or local servers. It may provide a standardized interface, wired (e.g. fiber) or wireless, to support these communications. Through this network interface 432, the base station 400 may implement the standardized interfaces N2 (based on NGAP protocol) and N3 (based on GPRS tunneling protocol) with the core network, and the standardized interface Xn (based on XnAP protocol) with other base station of the Radio Access Network (RAN), all defined by the 3GPP standard. The wireless interface 404 is configured to provide wireless communication via communication links (414) with other wireless devices, such as one or more UEs. The wireless interface 404 may be compliant with a fifth-generation (5G) New Radio (NR) system and thus implementing the Uu interface defined by 3GPP standard, or with other wireless communication system. The wireless interface 404 is coupled to the processing unit 402 and typically includes one or more antennas (such as the antenna 410), a receiving unit 406 and a transmitting unit 408. The configuration of the wireless interface 404 may be limited to connect to one antenna, but preferably several antennas are used, in order to provide beamforming capability. Although not shown in Figure 4, the receiving unit 406 typically includes elements such as a receiver, demodulator, decoder, and the transmitting unit 408 typically includes elements such as a transmitter, modulator, coder. The receiving unit 406 and transmitting unit 408 may together be referred to as a transceiver. The processing unit 402 is configured to carrying out processing for operation of the base station 400. The processing unit 402 may be a single processor (e.g. Central Processing Unit) or may comprise two or more processors. The number of processors and the allocation of processing functions to the processors is a matter of design choice for a skilled person. The base station 400 includes memory 418 for storing data and computer programs containing instructions for the operation 8 of the base station 400. Memory 418 includes RAM (Random Access Memory), ROM (Read Only Memory), or combination of both or as a non-limiting example a mass storage device such as a disk or a Solid-State Drive. Memory 418 includes a program memory in which are stored programs containing processor instructions for operation of the base station 400 and for implementing the methods in accordance with one or more embodiments of the invention. The programs may contain a number of different program elements or sub-routines containing processor instructions for a variety of different tasks, for example, for: establishing, controlling and releasing communications with the UEs (e.g. implementing the Uu interface); processing data and signalling received at the receiving unit 406; processing signalling (e.g., paging messages, System Information Blocks) and data for transmission by the transmitting unit 408. Memory 418 may further include memory (e.g. RAM) for storing information. For example, information stored in memory 418 may include information associated with a served UE (that is, a UE that is being served by the base station 400) bitrate, such as “XR rate control”, “XR rate control status”, and “QoS Flow Level QoS Parameters” information elements. Specific program elements / sub-routines stored in program memory may include one or more of the following: elements for sending a request for a RAN node to serve a UE, the request including information associated with the UE, elements for receiving a request for serving a UE and for receiving information associated with the UE, an element for accepting or rejecting the request for serving the UE based on the received information, an element for receiving a request to provide information related to the UE, an element forsending a response to the request to provide information, the response including information associated with the UE (see, for example, the methods described below with reference to figures 6-9). In an example arrangement, a communication bus 424 provides communication and interoperability between the various elements included in the base station 400 or connected to it. The representation of the bus is not limiting and in particular, the processing unit 402 is operable to communicate instructions to any element of the base station 400 directly or by means of another element of the base station 400. In an example implementation, the base station 400 may be or may include an apparatus comprising one or more processing units or processors for performing or implementing the methods in accordance with one or more embodiments of the invention. In otherwords, the apparatus is capable of performing one or more functions of the base station including performing the methods in accordance with one or more embodiments of the invention by means of the one or more processing units. For example, the one or more processing units uses software to implement the one or more embodiments of the invention as described above with reference to the processing unit 402 of Figure 4. Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, a CPU of a microcontroller Unit (MCU), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other equivalent integrated (e.g. on an Integrated Circuit) or discrete logic circuitry. However, alternatively, the one or more processing units for performing or implementing the methods may be implemented in hardware: for example, in the form of an Application Specific Integrated Circuit or ASIC or other 9 hardware comprising logic element (s). Accordingly, the term “processing unit” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. Figure 5 illustrates an example of a wireless communication system 500 in which embodiments and examples of embodiments of the present invention may be implemented. The network system of Figure 5, is composed of three base stations 501,502 and 503, two core networks 510 and 520, with the respective AMF entities 511a and 511b (for Core Network 510) and 521a and 521b (for Core Network 520) and the respective UPF entities 512a and 512b (for Core Network 510) and 522a and 522b (for Core Network 520). A wired backhaul IP network 590 interconnects the base stations 501,502 and 503 and the Core Networks 510 and 520. For instance, this wired link consists of optical fibre cable(s). UE 551 is connected to the serving base station referred to as gNB1, 501 through radio link 5301. UE 552 is connected to the serving base station referred to as gNB1, 501 through radio link 5302. UE 561 may be connected to the serving base station referred to as gNB2, 502 through radio link 5021 or to the serving base station referred to as gNB3, 503 through radio link 5031 or, in case of dual connectivity, to both the serving base station gNB2, 502 through radio link 5021 and the serving base station gNB3, 503 through radio link 5031. The processes and arrangements for managing one or more network connections in a wireless communication system to facilitate service continuity for UE(s) served by the one or more gNBs will now be described according to some embodiments of the present disclosure. Several scenarios are possible for the UEs 551,552 and 561. Such scenarios may arise due to mobility of the UEs 551,552, and 561. As a first scenario, and taking the example of UE 561, a dual-connectivity configuration may be applied to the UE 561, initially connected to gNB2 502 only through the link 5021. Indeed, the UE 561 periodically performs a cell search procedure, as defined in 3GPP TS 38.300, trying to detect PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal). The UE may report to gNB2 502 the presence of a new cell, for instance one cell managed by the gNB3 503, through a measurement report. Based on the analysis of the measurement report, the gNB2 502 may request to the gNB3 503 the establishment of a dual connectivity for the UE 561 with an additional connection through the link 5031. The gNB3 503 may accept the request and proceed to the connection of the UE 561 according to the procedure described in TS 37.340 section 10.2.2. As a result, the UE 561 is dual-connected. The gNB2 502 may take benefit of the dual connectivity of UE 561 to balance the traffic load by offloading some traffic (data / user traffic or control traffic) initially planned to be transmitted through the link 5021. Some or all the traffic associated to the UE 561 may be transmitted through the link 5031 and through the IP connectivity between gNB2 502 and gNB3 503. Such dualconnectivity procedure is further described below with reference to figure 8. As a second scenario, the radio link 5021 may experience radio link deficiency due to some unexpected interference or shadowing phenomena. For such reasons, the UE 561 may lose the connection with the gNB2 502 and declare a Radio Link Failure (RLF). Then, the UE 561 will try to reestablish the connection in the same or a different cell controlled by gNB2 502 or by another gNB. Thus, the UE 561 may try to connect to a cell controlled by gNB3 503 by requesting the establishment of the link 5031. In this case, the reestablishment procedure described in TS 38.300 section 9.2.3.3 may be applied, which enables a UE to maintain the RRC connection. With such procedure, the gNB3 503 sends to the gNB2 502 a request to retrieve the context of the UE 561. Based on the response from the gNB2 502, the gNB3 503 may accept the connection of the UE 561. Then, all the traffic related to the UE 561 will now transit through the gNB 503. If the reestablishment is rapidly performed after RLF, the service interruption at the UE 561 may be avoided or limited. Such reestablishment procedure is further described below with reference to figure 9. As a third scenario, the UE 561 may be handed over from the current serving cell to a new cell. Indeed, based on the measurement reports provided by the UE 561, the gNB2 502 may detect that the UE 561 would have a better connection through a cell managed by the gNB3 503. Then, the gNB2 502 may trigger a handover procedure described in TS 38.300 section 9.2.3.2. In this procedure, the gNB2 502 sends a handover request to the gNB3 503 along with information related to the UE 561. Based on this information, the gNB3 503 may accept the handover request and proceed to the admission of the UE 561. Then, all the traffic related to UE 561 will now transit through the gNB 503. Such handover procedure is further described below with reference to figure 6 (XN handover) and figure 7 (NG handover). In the scenarios discussed above, the source / MN / old gNB (gNB2) interreacted with UE prior to the mobility procedure. Among these interactions, the XR rate control procedure, if the UE supports it, may have been applied as described hereafter. Firstly, the source / MN / old gNB (gNB2) is required to schedule UE communications based on the UE aggregated maximum bitrate (“allocated bitrate”, upper bound) per QoS flow. “Allocated bitrate” is decided at PDU session establishment procedure, and may be modified during PDU session modification procedure. Secondly, if the UE supports it, the source / MN / old gNB (gNB2) may attempt to change the UE per QoS flow bitrate (by sending a signalling message to the UE with a “recommended bitrate” message). The trigger for sending a “recommended bitrate” message is determined (e.g., identified) by some conditions, for example if the available bitrate at the gNB is changed (increased or decreased) or if congestion condition is changed (resolved, increased, decreased). Based on these conditions, the gNB may attempt to increase or decrease the UEs per QoS flow bitrate. Per QoS flow “allocated bitrate” represents the maximum achievable bitrate and, if available, the per QoS flow Guaranteed bit rate, represents a lower bound. The target / secondary / new gNB (gNB3) decides whether to accept or reject a request for serving a UE based on various information and conditions. One condition consists of assessing if the target / secondary / new gNB (gNB 3) can sustain the bitrate of the UE (i.e. if there are enough radio 11 resources to schedule all the QoS flows of the UE). This condition is based at least on the gNB available bitrate and the UE aggregated maximum bitrate (“allocated bitrate”) per QoS flow. However, the target / secondary / new gNB (gNB3) does not know if the UE supports XR rate control. Thus, although the target / secondary / new gNB (gNB3) schedules the UE communications at the maximum bitrate (“allocated bitrate”), it does not know if the UE has configured each QoS flow to deliver the maximum bitrate, or if the UE had previously decreased its QoS flow bitrate. This represents a potential bitrate loss due to over scheduling by the gNB. Also, user satisfaction is impacted because the UE is not sending a maximum bitrate when it should have been possible. Moreover, if target / secondary / new gNB (gNB3) experiences a decrease in its available bitrate, or a congestion condition, then it will not know that it may attempt to decrease the UE QoS flow bitrate to improve the user experience by graceful degradation of the application quality. Figure 6 is a schematic and simplified diagram illustrating an example message flow for performing Xn handover of a UE according to embodiments of the invention. This figure shows a source base station or gNB 602 such as the gNB 502 of figure 5, a target base station or gNB 603 such as the gNB 503, a UE 610, and the AMF 604 of the UE 610 (UE AMF orgNB AMF) such as the AMF 521a, in a 5G core network (5GC) such as the core network 520 of figure 5. At the beginning of the message flow, the UE 610 is served by the gNB 602 through a cell (i.e. the serving or source cell) controlled by this gNB 602. The gNB 602 may be called source gNB . The user data in downlink are provided by the 5GC to the source gNB 602 through a UPF (not represented in the Figure 6), then the user data are transmitted to the UE 610 through a radio bearer. The user data in uplink are similarly transmitted in the opposite direction from the UE to the UPF in the 5GC. The source gNB 602 may have some information related to or associated with the UE 610 (which may be referred to as context information associated with the UE), for instance because it was informed, by the UE 610, at the RRC connection of the UE 610 to the gNB 602, with the message RRC setup complete, specified in TS 38.331, which information may include an Information Element (IE) indicating QoS flow(s) that can be rate controlled (e.g. XR rate control information). The UE 610 may send UE assistance information, which is a RRC message also defined in TS 38.331, including XR rate control information IE associated with the UE 610. Such information may be sent periodically or in response to a particular change. Alternatively or additionally, the source gNB 602 may have the same information related to or associated with the UE 610 (which may be referred to as context information associated with the UE), for instance because it was informed, by the AMF 604, at the PDU session setup of the UE 610 to the core network, with the message PDU SESSION RESOURCE SETUP REQUEST, specified in TS 38.413, which information may include an Information Element (IE) indicating QoS flow(s) that can be rate controlled (e.g. XR rate control information). The AMF may send PDU session resource modify or PDU session resource modify indication messages also defined in TS 38.413, including XR rate control information associated with the UE 610. In one example, the XR rate control information element (e.g. information for indicating QoS flow(s) that can be rate controlled) may include for each QoS flow of the UE at least one of the following criteria: A. a “QoS flow identifier “ field(QFI, TS 37.324) indicating the QoS flows of the UE that can be rate controlled by the gNB MAC; B. a “XR rate control request” field: For the QoS flow indicates to start, stop, apply uplink, apply downlink, apply both downlink and uplink; and C. a “Last recommended bitrate” field: This field indicates the last recommended bitrate that the UE have received. Also, as part of message PDU SESSION RESOURCE SETUP REQUEST, specified in TS 38.413, the source gNB knows for each QoS flow of the UE, the allocated bitrate that was configured or specified by the core network. The allocated bitrate of a QoS flow is the bitrate that was initially (or originally) configured for the QoS flow (for example at PDU session establishment as shown in Figure 3a). According to TS 23.502, the core Network allocates a bitrate to each QoS flow of a PDU session when said PDU session is established with the UE or modified by either the UE or the core network. For example, the bitrate can be expressed by the QoS parameter MBR (Maximum bitrate), representing the upper limit of the bitrate allocated to the UE. Another example is the QoS parameter GBR (Guaranteed bitrate) representing the lower limit of the bitrate allocated to the UE. The UE allocated bitrate may be comprised in various information elements (TS 38.413), including but not limited to GBR QoS Flow Information, QoS Flow Level QoS Parameters, Dynamic 5QI Descriptors, Non Dynamic 5QI descriptors, UE Aggregate Maximum Bitrate, PDU Session Aggregate Maximum Bitrate. When served by the source gNB 602, the UE 610 regularly performs measurement on signals received from the serving cell and one or more target cells (e.g. candidate cells), such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells. The target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell). Once the UE 610 discovers at least one SSB that meets predefined criteria (for instance a received power that exceeds a predefined threshold), the UE 610 may send a measurement report 621 to the source gNB 602 through a RRC message. The measurements provide radio link quality information for different cells in the vicinity of the UE 610. The identity of each cell is included in the measurement report to allow the source gNB 602 to identify the gNB(s) controlling the reported cell(s). Based on the received measurement report, the source gNB 602 may detect that the UE 610 receives radio signals in a cell controlled by the target gNB 603 with a better quality than in the current serving cell controlled by the source gNB 602. The source gNB 602 may then decide at step 620 the handover of the UE 610 to the target gNB 603. The source gNB 602 may execute a Xn handover when there is a Xn interface between the source gNB 602 and the target gNB 603. To trigger the handover, the source gNB 602, sends a handover request message 622 to the selected target gNB 603 including the information related to or associated with the UE 610 to be handed over. The handover request message may be the Handover Request message specified in the 3GPP document TS 38.423 section 9.1.1.1, which may in addition include information associated with the UE 610. The information associated with the UE 610 includes at least one of the information described above with respect to the XR rate control IE defined above. The target gNB 603 receiving this XR rate control IE can understand that the handover request is related to the handover of a UE that accepts XR rate control on designated QoS flows (“XR rate control request" field set to “on”). The handover request message 622 may also include information elements including information related to the UE allocated bitrate. The UE allocated bitrate may be comprised in various information elements (TS 38.413) including but not limited to the PDU Session Resource Setup List. The IE related to XR rate control information defined above, may also be used by the target gNB 603 in the admission control step 640 to decide whether the request is accepted or not. The decision may be based on criteria such as: A. The target gNB may reject the handover request because it does not support XR rate control. In response to this rejection, the UE may then be reconfigured with XR rate control set to “off’ before attempting a new handover to the target gNB; and / or B. The target gNB may accept the handover request despite that its available radio resources cannot accommodate the aggregated UE PDU session maximum bitrate, for example, if the aggregated “Last recommended bitrate” can be accommodated by the target gNB radio resources. If the target gNB 603 has rejected the handover request, it sends a Handover Request Failure message (not represented in the figure 6) as defined in TS 38.423 section 8.2.1.3. Upon reception of this message, the source gNB 602 may consider another cell to hand over the UE 610. The Handover Request Failure message may include a Cause Information Element (IE) to indicate the reason to reject a handover. The value of the Cause IE may be set to “No Radio Resources Available” as defined in TS 38.423 section 9.2.3.2. In case the target gNB 603 has rejected the handover because it does not support XR rate control, the value of the Cause IE may be set to a new value to indicate “XR rate control not supported” or “XR rate control not allowed”. This allows feedback to be provided to the source gNB, particularly in case of handover rejection. If the target gNB 603 has decided to accept the handover request, the handover procedure can be completed as defined in TS 38.300 section 9.2.3. Briefly, the target gNB 603 sends a handover request acknowledge message 623 to the source gNB 602. The handover request acknowledge message 623 may include a new information element called “XR rate control status”. The “XR rate control status” information element contains for each QoS flow a field named “Activation Status” that can be set at least to “active” or “inactive”. This allows feedback to be provided to the source gNB,. Then, the source gNB 602 sends a RRC Reconfiguration message 624 containing the necessary information for the UE 610 to connect to the target cell, such as radio bearer(s), measurement configuration, (information previously received by the source gNB 602 from the target 14 gNB 603 in the acknowledgment message 623). In case of conditional handover (CHO), the UE 610 is configured with a triggering condition to fulfil before switching to the target cell. After switching to the target cell as the new serving cell, the UE 610 performs a randomaccess channel (RACH) procedure 625 towards the target cell to acquire uplink synchronization. Once synchronization is established, the UE 610 sends a RRC Reconfiguration Complete message 626 to the target gNB 603, which is now the new source or serving gNB for the UE 610. In the meantime, the target gNB 603 may perform the path switch handshake procedure toward the UE AMF 604, with the exchange of Path Switch Request message 627 and Path Switch Request Acknowledge 628. It can be noted that the target gNB 603 knows the AMF of the UE 610 as the ID of this AMF is included in the Handover Request message 622. Then, the control and user data associated with the UE 610 will transit through the target gNB 603 and no more through the source gNB 602. Finally, the target gNB 603 sends a UE Context Release message 629 to the source gNB 602, to indicate that the handover procedure is completed, and that the source gNB 602 can delete the stored context information related to the UE 610. Before the UE 610 resumes data transfer, the target gNB 603 may attempt to reset the UE 610 QoS flow to the allocated bitrate. For each UE QoS flow with the “XR rate control request” field of the XR rate control IE set to “on”, the target gNB 603 may attempt to reset the UE bitrate to the UE allocated bitrate. If the information was available in the “PDU Session Resource Setup List” information element, the target gNB 603 may send a recommended bitrate message 631 to the UE. The recommended bitrate message includes bitrate fields for each QoS flow that the target gNB is attempting to control. By setting the bitrate field of the recommended bitrate message to the corresponding UE allocated bitrate, the target gNB resets the corresponding QoS flow to its allocated bitrate. The target gNB will schedule the allocated bitrate for each UE QoS flow. After some time, the target gNB may then adjust all or some of the UE QoS flows by adjusting the recommended bitrate depending on radio or congestion conditions. In these embodiments, the target gNB is able to ensure that its scheduling matches each QoS flow bitrate. Alternatively, the target gNB 603 may not attempt to reset the UE QoS flow to the allocated bitrate. In this case, the target gNB 603 will just schedule the allocated bitrate for each UE QoS flow, then, .After some time, the target gNB may then adjust all or some of the UE QoS flows by adjusting the recommended bitrate depending on radio or congestion conditions. In this case, the UE 610 is responsible for setting all its QoS flows to the allocated bitrate after or as part of the RRC reconfiguration (626). This reduces the signalling overhead. Alternatively, the target gNB may attempt to set the UE 610 QoS flows to a determined bitrate. For each UE QoS flow with “XR rate control request” field of the XR rate control IE set to “on”, the target gNB may attempt to set the UE bitrate to a bitrate value determined (e.g., identified) based on one ora combination of the following: A. the radio conditions; B. the congestion conditions; C. the “Last recommended bitrate” field of the XR rate control IE; and D. a Bitrate Query message 630 received from UE 610 (as part of last message of the handover procedure). The bitrate query message 630 includes bitrate fields for each QoS flow to be communicated to the gNB. By setting the bitrate field of the bitrate query message to the corresponding UE actual QoS flow bitrate, the UE informs the target gNB of the current bitrate setting for each QoS flow. The determined target bitrate may be less or equal to the allocated bitrate, if the allocated bitrate is known (for example, if the information was available in the “PDU Session Resource Setup List” information element). The determined bitrate is sent to the UE in a recommended bitrate message 630. The recommended bitrate message includes bitrate fields for each QoS flow that the target gNB is attempting to control. By setting the bitrate field of the recommended bitrate message to the corresponding determined bitrate, the target gNB sets the corresponding QoS flow to the determined bitrate. In this manner, the target gNB reduces the risks of congestion due to the acceptance of the UE 610 in its cell. In this figure, the messages 622, 623, 629 may correspond to the messages with the same name described in TS 38.423, the messages 621,624, 626 may correspond to the messages with the same name described in TS 38.331, the messages 627, 628 may correspond to the messages with the same name described in TS 38.413, and the RACH procedure 625 may correspond to the RACH procedure described in TS 38.321. Figure 7 is a schematic and simplified diagram illustrating an example message flow for performing the NG handover of a UE according to embodiments of the invention. This figure shows a source base station or gNB 702 like the gNB 502 of figure 5, a target base station or gNB 703 like the gNB 703, a UE 710, and the AMF 704 of the UE 710 like the AMF 521a, in a 5G core network (5GC) like the core network 520. The beginning of the message flow is similar to the message flow described above with reference to figure 6. The UE 710 is served by the source gNB 702 through a cell (serving or source cell) controlled by this gNB. The source gNB 702 may have some information related to the UE 710, in particular a part or all of the “XR rate control” and “QoS Flow Level QoS Parameters” lEs defined above with reference to figure 6. The UE 710 regularly performs measurement on signals received at the UE 710 from the serving cell and one or more target cells (e.g. neighbouring candidate cells). Based on the received measurement reports, the source gNB 702 may detect that the UE 710 receives radio signals in a cell controlled by the target gNB 703 with a better quality than in the current serving cell controlled by the source gNB 702. The source gNB 702 may then decide at step 720 the handover of the UE 710. The source gNB 702 may execute a NG handover, for instance when there is no Xn interface between the source gNB 702 and the target gNB 703. To trigger the handover, the source gNB 702, sends a handover required message 722 to the AMF 704 indicating the target cell for the handover (and thus indicating the selected target gNB 16 703). Then the AMF 704 sends a Handover Request message 723 to the target gNB 703 including the information related to or associated with the UE 710 to be handed over. In particular, the information associated with the UE 710 includes at least one of the “QoS Flow level parameters” IE associated with the UE 710 and may also include the “XR rate control” IE associated with the UE 710 defined above with reference to figure 6. The information associated with the UE 710 may be included in the message 722 and message 723. The AMF 704 may already know the “QoS Flow level parameters” IE from the PDU session establishment of the UE 710 to the network. The AMF 704 may already know the “XR rate control” IE through a NAS protocol message transmitted by the UE 710 (for instance through the UL NAS transport message defined in TS 24.501 section 8.2.10). Thus, the Handover Required message 722 may not need to include the lEs “QoS Flow level parameters” and “XR rate control” related to the UE 710. The target gNB 703 receiving the handover request with the information related to the UE 710 performs the admission control step 740, similar to the step 640 of the figure 6, to decide whether the request is accepted or not. Thus, by providing the information associated with the UE 710 to the target gNB 703, the target gNB 703 can know that the UE related to the request supports XR rate control and can make an informed decision based on the received information as to whether to accept or reject the handover request. If the target gNB 703 has rejected the handover request, it sends a Handover Failure message (not represented in the figure 7) as defined in TS 38.413 section 9.2.3.6. A Cause IE indicates the reason of rejection. Upon reception of this message, the AMF 704 sends to the source gNB 702 a Handover Preparation Failure (not represented in the figure 7) as defined in TS 38.413 section 9.2.3.3, and the source gNB 702 may consider another cell to hand over the UE 710. The Cause IE in the Handover Preparation Failure message corresponds to the Cause IE in the Handover Failure message. The value of the Cause IE may be set to a value as discussed above with respect to the Handover Request Failure message. If the target gNB 703 has decided to accept the handover request, the handover procedure can be completed. Briefly, the target gNB 703 sends a handover request acknowledge message 724 to the AMF 704. The handover request acknowledge message 724 may include a new information element called “XR rate control status” as defined earlier with respect to figure 6. Then the AMF 704 sends a Handover Command message 725 to the source gNB 702. Then, the source gNB 702 sends a RRC Reconfiguration message 726 containing the necessary information for the UE 710 to connect to the target cell, such as radio bearer(s), measurement configuration, (information previously received by the source gNB 702 from the target gNB 703 via the acknowledgment message 724 and the Handover Command message 725). In case of conditional handover (CHO), the UE 710 is configured with a triggering condition to fulfil before switching to the target cell. After switching to the target cell as the new serving cell, the UE 710 performs a randomaccess channel (RACH) procedure 727 towards the target cell to acquire uplink synchronization. Once synchronization is established, the UE 710 sends a RRC Reconfiguration Complete message 728 to the target gNB 703, which is now the new source or serving gNB for the UE 710. 17 The target gNB 703 can then send a Handover Notify message 729 to the AMF 704 to indicate that the handover procedure is completed. Finally, the UE 710 sends a UE Context Release Command message 733 to the source gNB 702, to indicate that the handover procedure is completed, and that the source gNB 702 can delete the stored context information related to the UE 710. The source gNB 702 may send a UE Context Release Complete message 732 to the AMF 704 to acknowledge this operation. It can be noted that the target BH gNB 703 does not need to execute the path switch handshake procedure toward the AMF 704, as the AMF 704 already knows the target gNB 703 as the new serving gNB for the UE 710. Before the UE 710 resumes data transfer, the target gNB 703 may attempt to reset the UE 710 QoS flow to the allocated bitrate by sending a “recommended bit rate” message 731. Alternatively, the target gNB 703 may not attempt to reset the UE QoS flow to the allocated bitrate. In this case, the UE 710 is responsible for setting all its QoS flows to the allocated bitrate after or as part of the RRC reconfiguration (626). Alternatively, the target gNB may attempt to set the UE 710 QoS flows to a determined bitrate. For each UE QoS flow with the “XR rate control request” field of the XR rate control IE set to “on”, the target gNB may attempt to set the UE bitrate to a bitrate value determined (e.g., identified) based on one ora combination of the following: A. the radio conditions; B. the congestion conditions; C. the “Last recommended bitrate” field of the XR rate control IE; and D. a Bitrate Query message 730 received from UE 710. In this figure, the messages 721, 726, 728 may correspond to the messages with the same name described in TS 38.331, the messages 722, 723, 724, 725, 729, 733, 732 may correspond to the messages with the same name described in TS 38.413, and the RACH procedure 727 may correspond to the RACH procedure described in TS 38.321. Figure 8 is a schematic and simplified diagram illustrating an example message flow for performing dual-connectivity of a UE according to embodiments of the invention. This figure shows a master base station or gNB 802 like the gNB 502 of figure 5, a secondary base station or gNB 803 like the gNB 803, a UE 810, and the AMF 804 of the UE 810 like the AMF 521a, in a 5G core network (5GC) like the core network 520 of figure 5. At the beginning of the message flow, the UE 810 is served by the gNB 802 through a cell controlled by this gNB 802. The gNB 802 may be called the master gNB or MN gNB. The user data in downlink are provided by the 5GC to the MN gNB 802 through a UPF (not represented in the figure 6), then the user data are transmitted to the UE 810 through a radio bearer. The user data in uplink are similarly transmitted in the opposite direction from the UE(s) to the UPF in the 5GC. The MN gNB 802 may have some information related to or associated with the UE 810, for instance because it was informed, by the UE 810, at the RRC connection of the UE 810, with the 18 message RRC setup complete, specified in TS 38.331, which information may include an Information Element (IE) “QoS Flow Level QoS Parameters” indicating the “allocated bitrate” of the QoS flows of the UE. Additional lEs (e.g. “XR rate control”) may be provided with this RRC connection message sent by the UE 810. The UE 810 may also send UE assistance information including lEs such as “XR rate control” or “QoS Flow Level QoS Parameters”, which is a RRC message also defined in TS 38.331. The “XR rate control” or “QoS Flow Level QoS Parameters” lEs correspond to the ones described above with reference to figure 6. Alternatively, the MN gNB 802 may have received the two lEs “XR rate control” or / and “QoS Flow Level QoS Parameters” from the core network (AMF). When served by the MN gNB 802, UE 810 regularly performs measurement on signals received at the UE 810 from the serving cell and one or more target cells, such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells. The target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell). Once the UE 810 discovers at least one SSB that meets predefined criteria (for instance a received power that exceeds a predefined threshold), the UE 810 may send a measurement report 821 to the MN gNB 802 through a RRC message. The measurements provide radio link quality information for different cells in the vicinity of the UE 810. The identity of each cell is included in the measurement report to allow the MN gNB 802 to identify the gNB controlling the reported cell. Based on the received measurement reports, the MN gNB 802 may detect that the UE 810 receives radio signals in a cell controlled by a secondary gNB 803 with a quality good enough for the UE 810 to establish a radio link with the SN gNB 803. The MN gNB 802 may then decide at step 820 to setup a dual-connectivity configuration at the UE 810, and thus to dual-connect the UE 810 with the secondary gNB 803. To trigger the dual-connectivity procedure, the MN gNB 802, sends a SN Addition Request message 822 to the selected SN gNB 803 including information related to or associated with the UE 810 to dual-connect. The SN Addition Request message may be the S-Node Addition Request message specified in the 3GPP document TS 38.423 section 9.1.2.1, which may include at least one of the information associated with UE 810 described above (with reference to figure 6) with respect to the “QoS flow Level QoS parameter” and “XR rate control” dynamic lEs. The SN gNB 803 receiving this “XR rate control” IE can understand that the request is related to a UE that allows rate control to be applied to some or all of its QoS flows. All or part of the “QoS flow Level QoS parameter” and “XR rate control” lEs related to UE information may also be used by the SN gNB 803 in the admission control step 840 to decide whether the request is accepted or not. The decision may be based on the same criteria as for the handover case described with reference to figure 6. Thus, by providing the information associated with the UE to the SN gNB 803, the SN gNB 803 can know that the UE related to the request is capable of XR rate control and can make an informed decision based on the received information as to whether to accept or reject the SN addition request. If the SN gNB 803 has rejected the handover request, it sends a S-Node Addition Request Reject message (not represented in the figure 8) as defined in TS 38.423 section 9.1.2.3. Upon reception of this message, the MN gNB 802 will stop the dual-connectivity procedure. If the SN gNB 803 has decided to accept the request, the procedure can be completed as defined in TS 37.340 section 10.2.2. Briefly, the SN gNB 803 sends a SN Addition Request Acknowledge message 823 to the MN gNB 802. The SN addition Request acknowledge message 823 may include a new information element called “XR rate control status” as defined earlier with respect to figure 6. Then, the MN gNB 802 sends a RRC Reconfiguration message 824 containing the necessary information for the UE 812 to connect to the target cell, such as radio bearer(s), measurement configuration, (information previously received by the MN gNB 802 from the SN gNB 803 in the acknowledgment message 823). Finally, the UE 810 sends a RRC Reconfiguration Complete message 825 to the MN gNB 802, which will forward the information to the SN gNB 803 through the message SN Reconfiguration Complete 826. Before the UE 810 resumes data transfer, the SN gNB 803 may attempt to reset the UE 810 QoS flow to the allocated bitrate by sending a “recommended bit rate” message 831. Alternatively, the SN gNB 803 may not attempt to reset the UE QoS flow to the allocated bitrate. In that case, the UE 810 or MN gNB 802 are responsible for setting all the UE QoS flows to the allocated bitrate after or as part of the RRC reconfiguration (825). Alternatively, the target gNB may attempt to set the UE 810 QoS flows to a determined bitrate. For each UE QoS flow with the “XR rate control request” field of the XR rate control IE set to “on”, the target gNB may attempt to set the UE bitrate to a bitrate value determined (e.g., identified) based on one ora combination of the following: A. the radio conditions; B. the congestion conditions; C. the “Last recommended bitrate” field of the XR rate control IE; and D. a Bitrate Query message 830 received from UE 810. In this figure, the messages 821,824, 825 may correspond to the messages with the same name described in TS 38.331, the message SN Addition Request Acknowledge 823 may be the message S-Node Addition Request Acknowledge described in TS 38.423 section 9.1.2.2, and the message SN Reconfiguration Complete 826 may be the message S-Node Reconfiguration Complete described in TS 38.423 section 9.1.2.4. Figure 9 is a schematic and simplified diagram illustrating an example message flow for performing connection reestablishment at a UE, in accordance with one or more embodiments of the invention. This figure shows a gNB 902 like the gNB 502 of figure 5, a gNB 903 like the gNB 503, a UE 910, and the AMF 904 of the UE 910 like the AMF 521a, in a 5G core network (5GC) like the core network 520 of figure 5. At the beginning of the message flow, the UE 910 is served by the gNB 902 through a cell controlled by this gNB 902. The UE 910 may serve one or several UEs (not represented in the Figure 20 9). The user data in downlink are provided by the 5GC to the gNB 902 through a UPF (not represented in the figure 9), then the user data are transmitted to the UE through a radio bearer. The user data in uplink are similarly transmitted in the opposite direction from the UE(s) to the UPF in the 5GC. The gNB 902 may have some information related to or associated with the UE 910, for instance because it was informed, by the UE 910, at the RRC connection of the UE 910, with the message RRC setup complete, specified in TS 38.331, which may include an Information Element “QoS Flow Level QoS Parameters” (IE) indicating the “allocated bitrate" of the QoS flows of the UE . Additional lEs (e.g. “XR rate control”) may be provided with this RRC connection message sent by the UE 910. The UE 910 may also send UE assistance information including lEs such as “XR rate control” or “QoS Flow Level QoS Parameters”, which is a RRC message also defined in TS 38.331. The “XR rate control” or “QoS Flow Level QoS Parameters” lEs correspond to the ones described above with reference to figure 6. Alternatively, the gNB 902 may have received the two lEs “XR rate control” or / and “QoS Flow Level QoS Parameters” from the core network (AMF). When served by the gNB 902, the UE 910 regularly performs measurement on signals received at the UE 910 from the serving cell and one or more target cells, such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells. The target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell). It may happen that the SSB signal in the serving cell meets predefined criteria (for instance a received power that is below a predefined threshold) during a sufficient time to declare, at step 920, a Radio Link Failure (RLF) for the link between the UE 910 and the gNB 902. Besides, the UE 910 may have detected a SSB signal that meets predefined criteria (for instance a received power that is above a predefined threshold) sufficient to attempt a new connection in the corresponding target cell. In that case, the UE 910 triggers a reestablishment procedure as described in TS 38.300 section 9.2.3.3. It first consists in performing a random-access channel (RACH) procedure 921 to obtain uplink resources, and then to transmit a RRC Reestablishment Request message 922 in the target cell. This RRC message is received by gNB 903 controlling the target cell. The RRC Reestablishment Request message 922 includes information to identify the gNB 902 (i.e. the last serving gNB for the UE 910), also this message includes information related to or associated with the UE 910. The information includes at least one of the information described above with respect to the “XR rate control” or “QoS Flow Level QoS Parameters” lEs. Upon the reception of the RRC Reestablishment Request message 922, and in case this message includes information related to the UE 910, the gNB 903 may execute an admission control step 935 to decide to accept or to reject the connection request. The decision may be based on the same criteria as for the handover case described above with reference to figure 6. If the gNB 903 has rejected the request at step 935, it will not respond to the UE 910 and the UE 910 will have to find another cell to try another reestablishment procedure. If the gNB 903 has accepted the request or if it has not executed the step 935, the gNB 903 sends a Retrieve UE Context Request message 923 to the gNB 902 to retrieve the context of the requesting UE 910. In response, the gNB 902 sends to the gNB 903 a Retrieve UE Context Response message 924 including the context information related to the UE 910. In the case 21 where the gNB 903 has not executed step 935 (e.g. because gNB 903 has not received the information related to or associated with the MWAB node 910) or in the case where the request does include the information related to or associated with the UE 910, the Retrieve UE Context Response message 924 may include information related to or associated with the UE 910 which includes at least one of the information described above with respect to the “XR rate control” and “QoS Flow Level QoS Parameters” lEs. Based on the information related to the UE 910, the gNB 903 may execute the admission control step 940 to decide to accept or to reject the connection request. The decision may be based on the same criteria as for the handover case described above with reference to figure 6. Thus, by providing the information associated with the UE to the new gNB 903 in a RRC Reestablishment request or in a Retrieve UE Context response, the new gNB 903 can know that the UE related to the request is capable of implementing XR rate control on its QoS flows, and can make an informed decision based on the received information as to whether to accept or reject the RRC Reestablishment request. If the gNB 903 has rejected the request at step 940, it will not respond to the UE 910 and the UE 910 will have to find another cell to try another reestablishment procedure. If the gNB 903 has accepted the request, the gNB 903 performs the path switch handshake procedure toward the AMF 904, with the exchange of Path Switch Request message 925 and Path Switch Request Acknowledge 926. It can be noted that the gNB 903 knows the AMF of the UE 912 as the ID of this AMF is included in the Retrieve UE Context Response message 924. Then, the control and user data associated with the UE 910 and will transit through the gNB 603 (considered as the new serving gNB) and no more through the gNB 902 (considered as the old serving gNB). The gNB 903 may send to the gNB 902, an indication of the reconnection of the UE 910 through the UE Context Release message 929. The gNB 902 can then delete the stored context information related to the MWAB node 910. In the meantime, the gNB 903 may send a RRC Reconfiguration message 927 containing the necessary information forthe UE 910 to be served in the new cell, such as radio bearer(s), measurement configuration. The UE 910 then responds with a RRC Reconfiguration Complete message 928 to the gNB 903. Before the UE 910 resumes data transfer, the gNB 903 may attempt to reset the UE 910 QoS flow to the allocated bitrate by sending a “recommended bit rate” message 931. Alternatively, the gNB 903 may not attempt to reset the UE QoS flow to the allocated bitrate. In that case, the UE 910 is responsible for setting all its QoS flows to the allocated bitrate after or as part of the RRC reconfiguration (927). Alternatively, the new gNB 903 may attempt to set the UE 910 QoS flows to a determined bitrate. For each UE QoS flow with the “XR rate control request” field of the XR rate control IE set to “on”, the target gNB may attempt to set the UE bitrate to a bitrate value determined (e.g., identified) based on one ora combination of the following: A. the radio conditions; B. the congestion conditions; C. the “Last recommended bitrate” field of the XR rate control IE; and 22 D. a Bitrate Query message 930 received from UE 910. In this figure, the messages the messages 922, 927, 928 may correspond to the messages with the same name described in TS 38.331, the messages 923, 924, 929 may correspond to the messages with the same name described in TS 38.423, the messages 925, 926 may correspond to the messages with the same name described in TS 38.423, and the RACH procedure 921 may correspond to the RACH procedure described in TS 38.321. Figures 10a to 10c are examples of methods for use in managing data transmission in a wireless network. Briefly, at a first network node (e.g. a target base station or gNB 603, a target base station or gNB 703, a secondary base station or gNB 803, a gNB 903), a method for managing data transmission in a wireless network comprises, during or following a mobility procedure between a user equipment, UE (e.g. a UE 610, a UE 710, a UE 810, a UE 910) and the first network node, receiving information indicating whether one or more attributes of a QoS flow, that has been configured for the UE, are able to be adapted. See, for example, step 1001 of figure 10a. The first network node gNB (e.g. a target base station or gNB 603, a target base station or gNB 703, a secondary base station or gNB 803, a gNB 903) may be a base station or a RAN node. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the first network node may be the gNB3 503. The UE may be the UE 561. The method may be performed by software elements and / or hardware elements. The first network node may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the first network node including one or more processing units, such as the processing unit 402. More details of the method are described below with reference to the example method described with reference to figure 10a. The information indicating whether the one or more attributes of the QoS, flow, that has been configured for the UE 561, are able to be adapted, may be associated with the UE 561. The one or more attributes of the QoS flow may comprise a bitrate of the QoS flow. In these embodiments, the information indicating whether one or more attributes of a QoS flow, that has been configured for the UE 561, are able to be adapted, may be an IE indicating one or more QoS flow(s) that shall be, or can be, rate controlled (for example, the XR rate control information described above). It will be appreciated that providing such information relating to a bitrate of a QoS flow to the first network node 503 will inform the first network node 503 that the UE 561 is able to apply rate control on the QoS flow. This information may inform the first network node 503 that it is able to initiate rate adaption for the QoS flow, if required, for example to compensate for different radio conditions at the first network node 503. Providing the first network node 503 with this information allows the first network node 503 to recommend a different bitrate to the UE 561 (for example, in response to a decrease in the available bitrate of the first network node, or a congestion condition), as the first network node 503 is aware that the UE 561 is able to apply rate control on the QoS flow. This may improve the user experience by gracefully degrading the application quality in these scenarios. The information may further identify the QoS flow (for example, the QoS flow identifier described above). In these embodiments, the information may indicate that a bitrate of the QoS flow has been adapted from an originally configured bitrate for the QoS flow. This may be indicated generally by the “XR rate control request” field being set to “on” in a XR rate control information IE. Additionally or alternatively, a value of the “Last recommended bitrate” field may indicate both that the bitrate of the QoS flow has been adapted, and the value of the adapted bitrate. Additionally or alternatively, the information may indicate that rate adaption has been applied to the bitrate of the QoS flow. This may be indicated generally by the “XR rate control request” field being set to “on” in a XR rate control information IE. Additionally or alternatively, a value of the “Last recommended bitrate” field may indicate both that rate adaption has been applied, and the value of the adapted bitrate. Additionally or alternatively, the information may indicate a bitrate of the QoS flow, where the bitrate has been adapted from an originally configured bitrate for the QoS flow. As described above, this may be indicated by the “Last recommended bitrate” field. The mobility procedure may comprise a handover procedure (for example, the Xn handover procedure described with reference to Figure 6, or the NG handover procedure described with reference to Figure 7) of the UE 561 to the first network node 503, from a second network node (for example, gNB 502) that served the UE 561 prior to the handover procedure. In these embodiments, the first network node 503 may comprise a target base station (for example, the target base station or gNB 603 in a Xn handover procedure, or the target base station or gNB 703 in a NG handover procedure), and the second network node 502 may comprise a source base station (for example, the source base station or gNB 602 in a Xn handover procedure, or the source base station or gNB 702 in a NG handover procedure). Alternatively, the mobility procedure may comprise a reestablishment procedure (for example, the reestablishment procedure described with reference to Figure 9) between the UE 561 and the first network node 503, wherein the second network node 502 served the UE 561 prior to the reestablishment procedure. In these embodiments, the first network node 503 may be a first base station (for example, gNB 903), and the second network node 502 may be a second base station (for example, gNB 902). Alternatively, the mobility procedure may comprise a procedure to configure dual connectivity for the UE 561 for both the first network node 503 and the second network node 502 (for example, the procedure to perform dual connectivity described with reference to Figure 8). In these embodiments, the first network node 503 may be a secondary network node (for example, the secondary base station or gNB 803), and the second network node 502 may be a master network node for example, the master base station or gNB 802). In some embodiments, the information may be received from either an Access and Mobility Management Function, AMF, network node (for example, the AMF 704), or the second network node 502. For example, during a handover procedure (for example, the NG handover procedure described with reference to Figure 7), the AMF 704 may send a Handover Request message 723 to the target gNB 703 including the “XR rate control” IE defined above. In these embodiments, the information may therefore be received in a handover request message. For example, during a handover procedure (for example, the XR handover procedure described with reference to Figure 6), the source gNB 602, may send a handover request message 622 to the target BH gNB 603 including the XR rate control IE defined above. In these embodiments, the information may therefore be received in a handover request message. For example, during a reestablishment procedure (for example, the reestablishment procedure described with reference to Figure 9), the gNB 902 may send to the gNB 903 a Retrieve UE Context Response message 924 including at least one of the information described above with respect to the “XR rate control” and “QoS Flow Level QoS Parameters” lEs. In these embodiments, the information may therefore be received in a retrieve UE context response message. Alternatively, during a reestablishment procedure (for example, the reestablishment procedure described with reference to Figure 9), the gNB 902 may send to the gNB 903 RRC Reestablishment Request message 922 including at least one of the information described above with respect to the “XR rate control” and “QoS Flow Level QoS Parameters” lEs. In these embodiments, the information may therefore be received in a RRC Reestablishment request message. For example, during a procedure to configure dual connectivity for the UE 561 (for example, the procedure to perform dual connectivity described with reference to Figure 8), the MN gNB 802, may send a SN Addition Request message 822 to the selected SN gNB 803 including at least one of the static “QoS flow Level QoS parameter” and “XR rate control” dynamic lEs. In these embodiments, the information may therefore be received in a secondary node addition request message. In some embodiments, the method may further comprise, in response to receiving the message (that is, a handover request message, a secondary node addition request message, a retrieve UE context response message, or a RRC Reestablishment request message), determining whether to continue executing the mobility procedure, or to stop executing the mobility procedure, based on the information indicating whether the one or more attributes of the QoS flow are able to be adapted. For example, with reference to Figure 6, the IE related to XR rate control information may be used by the target gNB 603 in the admission control step 640 to decide whether the to accept the handover request message 622, or not. For example, with reference to Figure 7, the IE related to XR rate control information may be used by the target gNB 703 in the admission control step 740 to decide whether the to accept the handover request message 722, or not. For example, with reference to Figure 8, the IE related to XR rate control information may be used by the SN gNB 803 in the admission control step 840 to decide whether the to accept the SN Addition Request message 822, or not. For example, with reference to Figure 9, the IE related to XR rate control information may be used by the gNB 903 in the admission control step 935 to decide whether the to accept the RRC Reestablishment Request message 922, or not. For example, with reference to Figure 9, the IE related to XR rate control information may be used by the gNB 903 in the admission control step 940 to decide whether the to accept the Retrieve UE Context Response message 924, or not. Thus, by providing this information to the first network node 503, the first network node 503 is informed whether the UE 561 (to which the mobility procedure relates) is able to adapt the bitrate of the QoS flow. Thus, the first network node 503 can make an informed decision based on the received information as to whether to accept or reject the handover request. The first network node 503 may determine (e.g., identify) to stop executing the mobility procedure in response to the information indicating that the UE 561 is able to adapt the bitrate of the QoS flow, when the first network node 503 itself is not configured to initiate adaption of the bitrate of the QoS flow (for example, when the first network node 503 does not support XR rate control). The first network node 503 may determine to continue executing the mobility procedure in response to the information indicating that the UE 561 is able to adapt the bitrate of the QoS flow. For example, in a situation in which the radio resources available at the first network node 503 are not able to accommodate the aggregated UE PDU session maximum bitrate, the first network node 503 may still determine to continue executing the mobility procedure in response to determining that the aggregated “Last recommended bitrate” can be accommodated by the first network node 503 radio resources. In some embodiments, in response to determining to stop executing the mobility procedure, the method may further comprise transmitting, to the network node that transmitted the message, an indication that the execution of the mobility procedure has been stopped based on whether the one or more attributes of the QoS flow are able to be adapted. This allows feedback to be provided to the entity in the case that execution of the mobility procedure is stopped. For example, with reference to Figure 6, upon rejecting the handover request, the target gNB 603 may send a Handover Request Failure message including a Cause Information Element (IE) that indicates that handover has been rejected as the first network node 503 itself is not configured to initiate adaption of the bitrate of the QoS flow. In some embodiments, in response to determining to continue executing the mobility procedure, the method may further comprise transmitting, to the entity that transmitted the message, an indication that the execution of the mobility procedure is being continued based on whether the one or more attributes of the QoS flow are able to be adapted. This allows feedback to be provided to the entity. For example, with reference to Figure 6, upon accepting the handover request, the target gNB 603 may send a handover request acknowledge message 623 including a “XR rate control status” information element. In some embodiments, the method may further comprise initiating adaption of the bitrate of the QoS flow, to an updated bitrate. In some embodiments, initiating adaption of the bitrate of the QoS flow, to an updated bitrate may comprise transmitting, to the UE 561, a message comprising the updated bitrate (or a message indicating an updated value of the bitrate). It will be appreciated that this updated bitrate may be the allocated bitrate described with reference to Figure 6, or may be the determined bitrate described with reference to Figure 6. For example, with reference to Figs. 6, 7, 8 and 9, the first network node 503 may send a recommended bitrate message 731 to the UE 561. The recommended bitrate message 731 may indicate to the UE 561 that the first network node 503 has reset the QoS flow to its originally configured (or allocated) bitrate. Alternatively, the recommended bitrate message 731 may indicate to the UE 561 that the first network node 503 has set the QoS flow to a determined bitrate (e.g., a bitrate that the first network node 503 has determined / identified). Resetting the QoS flow to its originally configured (or allocated) bitrate (in circumstances where this bitrate is able to be supported, for example, due to improved radio conditions at the first network node 503 in comparison to the radio conditions at the second network node 502) may improve user satisfaction where the QoS flow bitrate is increased. In some embodiments, the method may further comprise detecting a change in congestion conditions associated with the QoS flow (such as the congestion conditions described above), and / or detecting a change in available radio resources. Detecting a change in available radio resources may be based on the radio conditions described above. In response to such a detection, the method may further comprise initiating adaption of the bitrate of the QoS flow, to an updated bitrate. As described above, this may comprise sending a recommended bitrate message to the UE 561 that indicates to the UE 561 that the first network node 503 has set the QoS flow to an updated (or determined) bitrate. For example, in response to detecting an increase in the congestion conditions (that may indicate increasing or worsening congestion), and / or in response to detecting a decrease in the available radio resources, the method may comprise initiating a decrease of the bitrate of the QoS flow. In these embodiments, the updated (or determined) bit rate may be determined to compensate for a decrease in the available bitrate of the first network node 503, or worsening or increasing congestion as indicated by the congestion condition. Implementing such an updated (or determined) bitrate may then improve the user experience, by gracefully degrading the application quality in these scenarios. In response to detecting a decrease in the congestion conditions (that may indicate decreasing or improving congestion), and / or in response to detecting an increase in the available radio resources, the method may comprise initiating an increase of the bitrate of the QoS flow. 27 In these embodiments, the updated (or determined) bit rate may be determined to due to an increase in the available bitrate of the first network node 503, or improving or decreasing congestion as indicated by the congestion condition. Implementing such an updated (or determined) bitrate may then improve the user experience, by increasing the application quality when an increased bitrate of the QoS flow is able to be supported. In some embodiments, the method may comprise determining the updated bitrate based on an originally configured bitrate for the QoS flow. For example, as described with reference to Figure 6, a target gNB 603 may attempt to reset a UE 610 QoS flow to the allocated bitrate. In these embodiments, the target gNB is able to ensure that its scheduling matches each QoS flow bitrate. In some embodiments, the method may further comprise obtaining information indicating the bitrate of the QoS flow. This may be performed prior to initiating adaption of the bitrate of the QoS flow, to an updated bitrate. Obtaining the information indicating the bitrate of the QoS flow may comprise obtaining UE 561 traffic information, and determining the bitrate of the QoS flow based on the obtained UE 561 traffic information (forexample, based on the radio and / or congestion conditions). Alternatively, obtaining the information indicating the bitrate of the QoS flow may comprise receiving, from the UE 561, information indicating the bitrate (for example, the Bitrate Query message 630, 730, 830, 930 described with reference to Figures 6, 7, 8 and 9). Alternatively, obtaining the information indicating the bitrate of the QoS flow may comprise or receiving, from the second network node 502 information indicating the bitrate (for example, the “Last recommended bitrate” field of the XR rate control IE). Alternatively, obtaining the information indicating the bitrate of the QoS flow may comprise or receiving, from an AMF 704, information indicating the bitrate (for example, the “Last recommended bitrate” field of the XR rate control IE). The method may then further comprises determining the updated bitrate based on the obtained information indicating the bitrate of the QoS flow. Additionally or alternatively, determining the updated bitrate may be further based on an originally configured bitrate for the QoS flow. Additionally or alternatively, the updated bitrate may be further determined based on the radio and / or congestion conditions. In these embodiments, the updated (or determined) bit rate may have been determined to compensate for a decrease in the available bitrate of the first network node 503, or a congestion condition. Implementing such an updated (or determined) bitrate may then improve the user experience by gracefully degrading the application quality in these scenarios. It will also be appreciated that determining the updated bitrate in this manner (as opposed to scheduling the UE 561 to return to the originally configured bitrate, regardless of the change in radio and / or congestion conditions) may prevent over scheduling by the first network node 503 and / or prevent user dissatisfaction as a result of severe degradation in application quality, should the QoS flow not be able to support the originally configured bitrate. Briefly, at a user equipment, UE (e.g. a UE 610, a UE 710, a UE 810, a UE 910), a method for managing data transmission in a wireless network comprises, following a mobility procedure between the UE and a first network node (e.g. a target base station or gNB 603, a target base station or gNB 703, a secondary base station or gNB 803, a gNB 903), adapting one or more attributes of a QoS flow that has been configured for the UE. See, for example, step 1011 of figure 10b. For example, the UE (e.g. a UE 610, a UE 710, a UE 810, a UE 910) with reference to the communication system 500 shown in and described with respect to figure 5, may be the UE 561. The method may be performed by software elements and / or hardware elements. The first network node may be the gNB3 503. The UE may be implemented in a UE device 205 as shown in and described with reference to figure 2 with the method being performed by an apparatus for the UE including one or more processing units, such as the processor 215. More details of the method are described below with reference to the example method described with reference to figure 10b. The one or more attributes of the QoS flow may comprise a bitrate of the QoS flow. It will be appreciated that this updated bitrate may be the allocated bitrate described with reference to Figure 6, or may be the determined bitrate described with reference to Figure 6. In some embodiments, the bitrate of the QoS flow may be adapted in response to receiving, from the first network node 503, a message comprising an updated bitrate. For example, with reference to Figs. 6, 7, 8 and 9, the first network node 503 may send a recommended bitrate message 631, 731, 831,931 to the UE 561. The recommended bitrate message may indicate to the UE 561 that the first network node 503 has reset the QoS flow to its originally configured (or allocated) bitrate. Alternatively, the recommended bitrate message 631,731,831, 931 may indicate to the UE 561 that the first network node 503 has set the QoS flow to a determined bitrate, as described above. In these embodiments, adapting the bitrate of the QoS flow may comprise adapting the bitrate of the QoS flow to the updated bitrate. As noted above, resetting the QoS flow to its originally configured (or allocated) bitrate (in circumstances where this bitrate is able to be supported, for example, due to improved radio conditions at the first network node 503 in comparison to the radio conditions at the second network node 502) may improve user satisfaction by due to the increase in the QoS flow bitrate in these scenarios. In these embodiments, the updated (or determined) bit rate may have been determined to compensate for a decrease in the available bitrate of the first network node 503, or a congestion condition. Implementing such an updated (or determined) bitrate may improve the user experience by gracefully degrading the application quality in these scenarios. In some embodiments, the UE 561 may adapt the bitrate of the QoS flow prior to receiving a message comprising an updated bitrate from the first network node 503. For example, as described with reference to Figure 6, the UE 610 may be responsible for setting all its QoS flows to the allocated bitrate after or as part of the RRC reconfiguration 626. In these embodiments, the signalling overhead may be reduced. In some embodiments, the method may further comprise, prior to adapting the bitrate of the QoS flow, transmitting, to the first network node 503, information indicating the bitrate of the QoS flow (for example, the Bitrate Query message 630, 730, 830, 930 described with reference to Figures 6, 7, 8 and 9). The first network node 503 may then determine the updated bitrate based on the obtained 29 information 630, 730, 830, 930 indicating the bitrate of the QoS flow. Implementing such an updated (or determined) bitrate may improve the user experience by gracefully degrading the application quality in these scenarios. It will also be appreciated that determining the updated bitrate in this manner (as opposed to the first network node 503 scheduling the UE 561 to return to the originally configured bitrate, regardless of the change in radio and / or congestion conditions) may prevent over scheduling by the first network node 503 and / or prevent user dissatisfaction as a result of severe degradation of the application quality should the QoS flow not be able to support the originally configured bitrate. The mobility procedure may comprise a handover procedure (for example, the Xn handover procedure described with reference to Figure 6, or the NG handover procedure described with reference to Figure 7) of the UE 561 to the first network node 503, from a second network node (for example, gNB2 502) that served the UE 561 prior to the handover procedure. In these embodiments, the first network node 503 may comprise a target base station (for example, the target base station or gNB 603 in a Xn handover procedure, or the target base station or gNB 703 in a NG handover procedure), and the second network node 502 may comprise a source base station (for example, the source base station or gNB 602 in a Xn handover procedure, or the source base station or gNB 702 in a NG handover procedure). Alternatively, the mobility procedure may comprise a reestablishment procedure (for example, the reestablishment procedure described with reference to Figure 9) between the UE 561 and the first network node 503, wherein the second network node 502 served the UE prior to the reestablishment procedure. In these embodiments, the first network node 503 may be a first base station (for example, gNB 903), and the second network node 502 may be a second base station (for example, gNB 902). Alternatively, the mobility procedure may comprise a procedure to configure dual connectivity for the UE 561 for both the first network node 503 and the second network node 502 (for example, the procedure to perform dual connectivity described with reference to Figure 8). In these embodiments, the first network node 503 may be a secondary network node (for example, the secondary base station or gNB 803), and the second network node 502 may be a master network node for example, the master base station or gNB 802). In some embodiments, the method may further comprise, prior to adapting the one or more attributes of the QoS flow, transmitting, to the second network node 502 or the first network node 503, first information indicating whether the one or more attributes of a QoS flow are able to be adapted. For example, as described with reference to Figure 6, the UE 610 may send UE assistance information to the gNB 602, that includes the XR rate control information IE described above. For example, with reference to Figure 9, the UE 561 may transmit a Reestablishment Request message 922 to the first network node 503, including at least one of the information described above with respect to the “XR rate control” or “QoS Flow Level QoS Parameters” lEs. The first information indicating whether the one or more attributes of the QoS, flow, that has been configured for the UE 561, are able to be adapted, may be associated with the UE 561. The one or more attributes of the QoS flow may comprise a bitrate of the QoS flow. In these embodiments, the first information indicating whether one or more attributes of a QoS flow, that has been configured for the UE 561, are able to be adapted, may be an IE indicating one or more QoS flow(s) that shall be, or can be, rate controlled (for example, the XR rate control information described above). The information may further identify the QoS flow (for example, the QoS flow identifier described above). In these embodiments, the information may indicate that a bitrate of the QoS flow has been adapted from an originally configured bitrate for the QoS flow. This may be indicated generally by the “XR rate control request” field being set to “on” in a XR rate control information IE. Additionally or alternatively, a value of the “Last recommended bitrate” field may indicate both that the bitrate of the QoS flow has been adapted, and the value of the adapted bitrate.. Additionally or alternatively, the information may indicate that rate adaption has been applied to the bitrate of the QoS flow. This may be indicated generally by the “XR rate control request” field being set to “on” in a XR rate control information IE. Additionally or alternatively, a value of the “Last recommended bitrate” field may indicate both that rate adaption has been applied, and the value of the adapted bitrate. Additionally or alternatively, the information may indicate a bitrate of the QoS flow, where the bitrate has been adapted from an originally configured bitrate for the QoS flow. As described above, this may be indicated by the “Last recommended bitrate” field. Briefly, at a second network node (e.g. a source base station or gNB 602, a source base station or gNB 702, a master base station or gNB 802, a gNB 902), a method for managing data transmission in a wireless network comprises, during or following a mobility procedure between a user equipment, UE (e.g. a UE 610, a UE 710, a UE 810, a UE 910), and a first network node (e.g. a target base station or gNB 603, a target base station or gNB 703, a secondary base station or gNB 803, a gNB 903), transmitting information, to the first network node, indicating whether one or more attributes of a Quality of Service, QoS, flow that has been configured for the UE, are able to be adapted. See, for example, step 1021 of figure 10c. For example, second network node (e.g. a source base station or gNB 602, a source base station or gNB 702, a master base station or gNB 802, a gNB 902) with reference to the communication system 500 shown in and described with respect to figure 5, may be the gNB2 502, the first network node may be the gNB3 503, and the UE may be the UE 561. The method may be performed by software elements and / or hardware elements. The second network node may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the second network node including one or more processing units, such as the processing unit 402. More details of the method are described below with reference to the example method described with reference to figure 10c. The information indicating whether the one or more attributes of the QoS, flow, that has been configured for the UE 561, are able to be adapted, may be associated with the UE 561 The one or more attributes of the QoS flow may comprise a bitrate of the QoS flow. In these embodiments, the information indicating whether one or more attributes of a QoS flow, that has been configured for the UE 561, are able to be adapted, may be, an IE indicating one or more QoS flow(s) that shall be, or can be, rate controlled (for example, the XR rate control information described above). It will be appreciated that providing such information relating to a bitrate of a QoS flow to the first network node 503 will inform the first network node 503 that the UE 561 is able to apply rate control on the QoS flow. This information may inform the first network node 503 that it is able to initiate rate adaption for the QoS flow, if required, for example to compensate for different radio conditions at the first network node 503. Providing the first network node 503 with this information allows the first network node 503 to recommend a different bitrate to the UE 561 (for example, in response to a decrease in the available bitrate of the first network node 503, or a congestion condition), as the first network node 503 is aware that the UE 561 is able to apply rate control on the QoS flow. This may improve the user experience by gracefully degrading the application quality in these scenarios. The information may further identify the QoS flow (for example, the QoS flow identifier described above). In these embodiments, the information may indicate that a bitrate of the QoS flow has been adapted from an originally configured bitrate for the QoS flow. This may be indicated generally by the “XR rate control request” field being set to “on” in a XR rate control information IE. Additionally or alternatively, a value of the “Last recommended bitrate” field may indicate both that the bitrate of the QoS flow has been adapted, and the value of the adapted bitrate. Additionally or alternatively, the information may indicate that rate adaption has been applied to the bitrate of the QoS flow. This may be indicated generally by the “XR rate control request” field being set to “on” in a XR rate control information IE. Additionally or alternatively, a value of the “Last recommended bitrate” field may indicate both that rate adaption has been applied, and the value of the adapted bitrate. Additionally or alternatively, the information may indicate a bitrate of the QoS flow, where the bitrate has been adapted from an originally configured bitrate for the QoS flow. As described above, this may be indicated by the “Last recommended bitrate” field. The mobility procedure may comprise a handover procedure (for example, the Xn handover procedure described with reference to Figure 6, or the NG handover procedure described with reference to Figure 7) of the UE 561 to the first network node 503, where the second network node 502 served the UE 561 prior to the handover procedure. In these embodiments, the first network node 503 may comprise a target base station (for example, the target base station or gNB 603 in a Xn handover procedure, or the target base station or gNB 703 in a NG handover procedure), and the second network node 502 may comprise a source base station (for example, the source base station or gNB 602 in a Xn handover procedure, or the source base station or gNB 702 in a NG handover procedure). Alternatively, the mobility procedure may comprise a reestablishment procedure (for example, the reestablishment procedure described with reference to Figure 9) between the UE 561 and the first network node 503, where the second network node 502 served the UE prior to the reestablishment procedure. In these embodiments, the first network node 503 may be a first base station (for example, gNB 903), and the second network node 502 may be a second base station (for example, gNB 902). Alternatively, the mobility procedure may comprise a procedure to configure dual connectivity for the UE 561 for both the first network node 503 and the second network node 502 (for example, the procedure to perform dual connectivity described with reference to Figure 8). In these embodiments, the first network node 503 may be a secondary network node (for example, the secondary base station or gNB 803), and the second network node 502 may be a master network node for example, the master base station or gNB 802). In some embodiments, the second network node 502 may comprise an Access and Mobility Management Function, AMF, network node 704. For example, during a handover procedure (for example, the NG handover procedure described with reference to Figure 7), the AMF 704 may send a Handover Request message 723 to the target gNB 703 including the “XR rate control” IE defined above with reference to figure 6. In these embodiments, the information may therefore be transmitted in a handover request message. For example, during a handover procedure (for example, the XR handover procedure described with reference to Figure 6), the source gNB 602, may send a handover request message 622 to the target BH gNB 603 including the XR rate control IE defined above with reference to figure 6. In these embodiments, the information may therefore be transmitted in a handover request message. For example, during a reestablishment procedure (for example, the reestablishment procedure described with reference to Figure 9), the gNB 902 may send to the gNB 903 a Retrieve UE Context Response message 924 including at least one of the information described above with respect to the “XR rate control” and “QoS Flow Level QoS Parameters” lEs. In these embodiments, the information may therefore be transmitted in a retrieve UE context response message. Alternatively, during a reestablishment procedure (for example, the reestablishment procedure described with reference to Figure 9), the gNB 902 may send to the gNB 903 RRC Reestablishment Request message 922 including at least one of the information described above with respect to the “XR rate control” and “QoS Flow Level QoS Parameters” lEs. In these embodiments, the information may therefore be transmitted in a RRC Reestablishment request message. For example, during a procedure to configure dual connectivity for the UE (for example, the procedure to perform dual connectivity described with reference to Figure 8), the MN gNB 802, may send a SN Addition Request message 822 to the selected SN gNB 803 including at least one of the static “QoS flow Level QoS parameter” and “XR rate control” dynamic lEs. In these embodiments, the information may therefore be transmitted in a secondary node addition request message. In some embodiments, the method further comprises receiving, from the first network node 503, an indication that the execution of the mobility procedure has been stopped based on whether the one or more attributes of the QoS flow are able to be adapted. This allows feedback to be provided to the second network node in the case that execution of the mobility procedure is stopped. For example, with reference to Figure 6, upon rejecting the handover request, the target gNB 603 may send a Handover Request Failure message including a Cause Information Element (IE) tot the second network node 502, that indicates that handover has been rejected as the first network node 503 itself is not configured to initiate adaption of the bitrate of the QoS flow. Alternatively, the method may further comprise receiving, from the first network node 503, an indication that the execution of the mobility procedure is being continued based on whether the one or more attributes of the QoS flow are able to be adapted. This allows feedback to be provided to the second network node. For example, with reference to Figure 6, upon accepting the handover request, the target gNB 603 may send a handover request acknowledge message 623 including a “XR rate control status” information element to the second network node 502. In some embodiments, the method may further comprise receiving, from the UE 561, the information indicating whether the one or more attributes of a QoS flow are able to be adapted. For example, as described with reference to Figure 6, the UE 610 may send UE assistance information to the gNB 602, that includes the XR rate control information IE described above. In some embodiments, in response to determining to stop executing the mobility procedure, the method may further comprise transmitting, to the network node that transmitted the message, an indication that the execution of the mobility procedure has been stopped based on whether the one or more attributes of the QoS flow are able to be adapted. For example, with reference to Figure 6, upon rejecting the handover request, the target gNB 603 may send a Handover Request Failure message including a Cause Information Element (IE) that indicates that handover has been rejected as the first network node 503 itself is not configured to initiate adaption of the bitrate of the QoS flow. In some embodiments, in response to determining to continue executing the mobility procedure, the method may further comprise transmitting, to the entity that transmitted the message, an indication that the execution of the mobility procedure is being continued based on whether the one or more attributes of the QoS flow are able to be adapted. For example, with reference to Figure 6, upon accepting the handover request, the target gNB 603 may send a handover request acknowledge message 623 including a “XR rate control status” information element. Figure 10a is a flowchartofan example method 1000 performed by a first network node (e.g. a target base station or gNB 603, a target base station or gNB 703, a secondary base station or gNB 803, a gNB 903), for managing data transmission in a wireless network in accordance with one or more embodiments of the present invention. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the first network node performing the method 1000 may be the gNB3 503. The method 1000 as shown in and described with respect to figure 10a may be performed by software elements and / or hardware elements. The first network node may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the first network node including one or more processing units, such as the processing unit 402. At step 1001, during or following a mobility procedure between a user equipment, UE 561, and the first network node 503, the first network node 503 receives information indicating whether one or more attributes of a QoS flow, that has been configured for the UE 561, are able to be adapted. For example, the first network node 503 may receive the XR rate control information IE described above. Figure 10b is a flowchartofan example method 1010, performed by a user equipment, UE (e.g. a UE610, a UE 710, a UE 810, a UE 910), formanaging data transmission in awireless network in accordance with one or more embodiments of the present invention. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the UE performing the method 1010 may be the UE 561. The method 1010 as shown in and described with respect to figure 10b may be performed by software elements and / or hardware elements. The UE may be implemented in a UE device 205 as shown in and described with reference to figure 2 with the method being performed by an apparatus for the UE including one or more processing units, such as the processor 215. At step 1011, following a mobility procedure between the UE 561 and the first network node 503, the UE 561 adapts one or more attributes of a QoS flow that has been configured for the UE 561. Figure 10c is a flowchart of an example method 1020 performed by a second network node (e.g. a source base station or gNB 602, a source base station or gNB 702, a master base station or gNB 802, a gNB 902), for managing data transmission in a wireless network in accordance with one or more embodiments of the present invention. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the second network node performing the method 1020 may be the gNB2 502. The method 1020 as shown in and described with respect to figure 10c may be performed by software elements and / or hardware elements. The second network node may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the second network node including one or more processing units, such as the processing unit 402. At step 1021, during or following a mobility procedure between a user equipment, UE 561, and a first network node 503, the second network node 502,704 transmits information, to the first network node 503, indicating whether one or more attributes of a QoS flow, that has been configured for the UE 561, are able to be adapted. For example, the first network node 503 may receive the XR rate control information IE described above. In legacy systems, lEs are exchanged between the CN and the NGRAN carrying L4S configuration information. Similar to what RAN2 wants to implement for XR rate control, the L4S lEs provide per QoS flow configuration information. See for example, clauses 9.3.1.266 and 9.3.1.267 of TS 38.413. Thus, an example arrangement may create new lEs, similar to ECN marking lEs, to handle XR rate control configuration from CN to NGRAN. By taking a similar approach forXR rate control configuration information, specification efforts can be saved. ECN marking lEs can be added to PDU SESSION RESOURCE SETUP REQUEST and PDU SESSION RESOURCE MODIFY REQUEST. Similarly, these two PDU sessions management messages may include news lEs indicating XR rate control configuration. Thus, an example arrangement may add XR rate control information element to the PDU SESSION RESOURCE SETUP REQUEST message. At handover it is necessary to provide the same level of information to the target gNB. By applying the same concept as defined for L4S / ECN marking, specification efforts can be saved. Thus in this case, rate control information shall be provided to target gNB during handover. Similar to L4S, handover request (Xn or NG) received at target gNB shall contain information about which QoS flow can be subject to rate adaptation. The target gNB receiving this XR rate control IE can understand that the handover request is related to the handover of a UE that accepts XR rate control on designated QoS flows. Thus, when triggering the handover, the source gNB, sends a handover request (or required) message to the target gNB (or AMF) including an information element related to XR rate control. Thus, in this case, XR rate control lEs are added in (Xn) handover request message and (NG) handover required message. While the present invention has been described with reference to examples and embodiments, it is to be understood that the invention is not limited to the disclosed examples and embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the invention, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. Unless otherwise defined herein, scientific and technical terms used in connection with the presently disclosed inventive concept(s) shall have the meanings that are commonly understood by those of ordinary skill in the art, and known techniques and procedures may be performed according to conventional methods well known in the art and as described in various general and more specific references that may be cited and discussed in the present specification. 36 As used in this specification and claim(s), the words “comprising, “having,” “including,” or “containing” (and any forms thereof, such as “comprise” and “comprises,” “have” and “has,” “includes” and “include,” or “contains” and “contain,” respectively) are inclusive or open-ended and do not exclude additional, unrecited elements or method steps. The use of the term “a” or “an” in the claims and / or the specification may mean “one,” as well as “one or more,” “at least one,” and “one or more than one.” As such, the terms “a,” “an,” and “the,” as well as all singular terms, include plural referents unless the context clearly indicates otherwise. Likewise, plural terms shall include the singular unless otherwise required by context. The use of the term “or” in the present disclosure (including the claims) is used to mean an inclusive “and / or” unless explicitly indicated to refer to alternatives only or unless the alternatives are mutually exclusive. Unless otherwise explicitly stated as incompatible, or the physics or otherwise of the embodiments, examples, or claims prevent such a combination, the features of examples disclosed herein, and of the claims, may be integrated together in any suitable arrangement, especially ones where there is a beneficial effect in doing so. This is not limited to only any specified benefit, and instead may arise from an “ex post facto” benefit. This is to say that the combination of features is not limited by the described forms, particularly the form (e.g., numbering) of example(s), embodiment(s), or dependency of claim(s). In the preceding embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium. By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave may be included in the definition of medium. It should be understood, 37 however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data 5 magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. A method performed by a first network node, for managing data transmission in a wireless network, the method comprising:during or following a mobility procedure between a user equipment, UE, and the first network node, receiving information indicating whether one or more attributes of a Quality of Service, QoS, flow, that has been configured for the UE, are able to be adapted.

2. The method of claim 1, wherein the information further identifies the QoS flow.

3. The method of claim 1 or 2, wherein the one or more attributes of the QoS flowcomprise a bitrate of the QoS flow.

4. The method of claim 3, wherein the information indicates that a bitrate of the QoS flow has been adapted from an originally configured bitrate for the QoS flow.

5. The method of claim 3 or 4, wherein the information indicates that rate adaptation has been applied to the bitrate of the QoS flow.

6. The method of any one of claims 3 to 5, wherein the information indicates a bitrate of the QoS flow, where the bitrate has been adapted from an originally configured bitrate for the QoS flow.

7. The method of any one of the proceeding claims, wherein the mobility procedure comprises at least one of:a handover procedure of the UE to the first network node, from a second network node that served the UE prior to the handover procedure;a reestablishment procedure between the UE and the first network node, wherein a second network node served the UE prior to the reestablishment procedure; anda procedure to configure dual connectivity for the UE for both the first network node and the second network node.

8. The method of claim 7, wherein the mobility procedure comprises the handover procedure, wherein the first network node comprises a target base station, and wherein the second network node comprises a source base station.

9. The method of claim 7, wherein the mobility procedure comprises the procedure to configure dual connectivity, wherein first network node comprises a secondary network node, and wherein the second network node comprises a master network node.

10. The method of claim 7, wherein the mobility procedure comprises the reestablishment procedure, wherein the first network node comprises a first base station, and the second network node comprises a second base station.

11. The method of any one of claims 7 to 10, wherein the information is received from at least one of:an Access and Mobility Management Function, AMF, network node;the second network node; andthe UE.

12. The method of any one of the preceding claims, wherein the information is received in a message, wherein the message is at least one of:a handover request message;a secondary node addition request message;a retrieve UE context response message; anda RRC Reestablishment request message.

13. The method of claim 12, the method further comprising:in response to receiving the message, identifying whether to continue executing the mobility procedure, or to stop executing the mobility procedure, based on the information indicating whether the one or more attributes of the QoS flow are able to be adapted.

14. The method of claim 13, wherein, in response to identifying to stop executing the mobility procedure, the method further comprises:transmitting, to the entity that transmitted the message, an indication that the execution of the mobility procedure has been stopped based on whether the one or more attributes of the QoS flow are able to be adapted.

15. The method of claim 13, wherein, in response to identifying to continue executing the mobility procedure, the method further comprises:transmitting, to the entity that transmitted the message, an indication that the execution of the mobility procedure is being continued based on whether the one or more attributes of the QoS flow are able to be adapted.

16. The method of any one of the preceding claims, the method further comprising initiating adaption of the bitrate of the QoS flow, to an updated bitrate.

17. The method of any one of the preceding claims, the method further comprising:detecting a change in congestion conditions associated with the QoS flow, and / or detecting a change in available radio resources; andin response to this detection, initiating adaption of the bitrate of the QoS flow, to an updated bitrate.

18. The method of claim 17, the method further comprising:in response to detecting an increase in the congestion conditions, and / or in response to detecting a decrease in the available radio resources, initiating a decrease of the bitrate of the QoS flow, andin response to detecting a decrease in the congestion conditions, and / or in response to detecting an increase in the available radio resources, initiating an increase of the bitrate of the QoS flow.

19. The method of claim 16, wherein the method further comprises identifying the updated bitrate based on an originally configured bitrate for the QoS flow.

20. The method of claim 16, the method further comprising obtaining information indicating the bitrate of the QoS flow.

21. The method of claim 20, wherein obtaining the information indicating the bitrate of the QoS flow comprises:obtaining UE traffic information, andidentifying the bitrate of the QoS flow based on the obtained UE traffic information; or receiving, from the UE, information indicating the bitrate; or receiving, from a second base station, information indicating the bitrate.

22. The method of claim 20 or claim 21, the method further comprising:identifying the updated bitrate based on the obtained information indicating the bitrate of the QoS flow.

23. The method of claim 22, wherein identifying the updated bitrate is further based on an originally configured bitrate for the QoS flow.

24. The method of any one of claims 16 to 23, wherein initiating adaption of the bitrate of the QoS flow, to an updated bitrate, comprises transmitting, to the UE, a message comprising the updated bitrate.

25. A method performed by a user equipment, UE, for managing data transmission in a wireless network, the method comprising following a mobility procedure between the UE and a first41network node, adapting one or more attributes of a Quality of Service, QoS, flow that has been configured for the UE.

26. The method of claim 25, wherein the one or more attributes of the QoS flow comprise a bitrate of the QoS flow.

27. The method of claim 26, wherein the bitrate of the QoS flow is adapted in response to receiving, from the first network node, a message comprising an updated bitrate, and adapting the bitrate of the QoS flow comprises adapting the bitrate of the QoS flow to the updated bitrate.

28. The method of claim 26 or claim 27, wherein the method further comprises prior to adapting the bitrate of the QoS flow, transmitting, to the first network node, information indicating the bitrate of the QoS flow.

29. The method of any one of claims 25 to 28, wherein the mobility procedure comprises at least one of:a handover procedure of the UE to the first network node, from a second network node that served the UE prior to the handover procedure;a reestablishment procedure between the UE and the first network node, wherein a second network node served the UE prior to the reestablishment procedure; anda procedure to configure dual connectivity for the UE for both the first network node and a second network node.

30. The method of claim 29, wherein the mobility procedure comprises the handover procedure, wherein the first network node comprises a target base station, and wherein the second network node comprises a source base station.

31. The method of claim 29, wherein the mobility procedure comprises the procedure to configure dual connectivity, wherein first network node comprises a secondary network node, and wherein the second network node comprises a master network node.

32. The method of claim 29, wherein the mobility procedure comprises the reestablishment procedure, wherein the first network node comprises a first base station, and the second network node comprises a second base station.

33. The method of any one of claims 29 to 32, wherein the method further comprises: prior to adapting the one or more attributes of the QoS flow, transmitting, to the second network node or the first network node, first information indicating whether the one or more attributes of a QoS flow are able to be adapted.

34. The method of claim 33, wherein the first information further identifies the QoS flow.

35. The method of claim 33 or claim 34, wherein the first information indicates that a bitrate of the QoS flow has been adapted from an originally configured bitrate for the QoS flow.

36. The method of any one of claims 33 to 35, wherein the first information indicates that rate adaption has been applied to the bitrate of the QoS flow.

37. The method of any one of claims 33 to 36, wherein the first information indicates a bitrate of the QoS flow, where the bitrate has been adapted from an originally configured bitrate for the QoS flow.

38. A method performed by a second network node, for managing data transmission in a wireless network, the method comprising during or following a mobility procedure between a user equipment, UE, and a first network node, transmitting information, to the first network node, indicating whether one or more attributes of a Quality of Service, QoS, flow that has been configured for the UE, are able to be adapted.

39. The method of claim 38, wherein the information further identifies the QoS flow.

40. The method of claim 38 or claim 39, wherein the one or more attributes of the QoS flow comprise a bitrate of the QoS flow.

41. The method of claim 40, wherein the information indicates that a bitrate of the QoS flow has been adapted from an originally configured bitrate for the QoS flow.

42. The method of claim 40 or claim 41, wherein the information indicates that rate adaption has been applied to the bitrate of the QoS flow.

43. The method of any one of claims 40 to 42, wherein the information indicates a bitrate of the QoS flow, where the bitrate has been adapted from an originally configured bitrate for the QoS flow.

44. The method of any one of claims 38 to 43, wherein the mobility procedure comprises at least one of:a handover procedure of the UE to the first network node, from the second network node, wherein the second network node served the UE prior to the handover procedure;a reestablishment procedure between the UE and the first network node, wherein the second network node served the UE prior to the reestablishment procedure; anda procedure to configure dual connectivity for the UE for both the first network node and the second network node.

45. The method of claim 44, wherein the mobility procedure comprises the handover procedure, wherein the first network node comprises a target base station, and wherein the second network node comprises a source base station.

46. The method of claim 44, wherein the mobility procedure comprises the procedure to configure dual connectivity, wherein first network node comprises a secondary network node, and wherein the second network node comprises a master network node.

47. The method of claim 44, wherein the mobility procedure comprises the reestablishment procedure, wherein the first network node comprises a first base station, and the second network node comprises a second base station.

48. The method of claim 44, wherein the second network node comprises an Access and Mobility Management Function, AMF, network node.

49. The method of any one of claims 38 to 48, wherein the information is transmitted in a message, wherein the message is at least one of:a handover request message;a secondary node addition request message;a RRC Reestablishment Request message; anda retrieve UE context response message.

50. The method of claim 49, wherein the method further comprises:receiving, from the first network node, an indication that the execution of the mobility procedure has been stopped based on whether the one or more attributes of the QoS flow are able to be adapted; orreceiving, from the first network node, an indication that the execution of the mobility procedure is being continued based on whether the one or more attributes of the QoS flow are able to be adapted.

51. The method of any one of claims 38 to 50, wherein the method further comprises receiving, from the UE, the information indicating whether the one or more attributes of a QoS flow are able to be adapted.

52. A computer program comprising instructions which, when the program is executed by at least one processor unit, cause the at least one processing unit to carry out the method according to any one of claims 1 to 51.5 53. A computer-readable medium carrying a computer program according to claim 52.

54. An apparatus for a first network node, the apparatus comprising one or more processing units configured to perform the method as recited in any one of claims 1 to 24.10 55. An apparatus for a user equipment, UE, the apparatus comprising one or moreprocessing units configured to perform the method as recited in any one of claims 25 to 37.

56. An apparatus for a second network node, the apparatus comprising one or more processing units configured to perform the method as recited in any one of claims 38 to 51.

Images