Bearer reconfiguration

By enabling dynamic reconfiguration of DRBs between APS and FPS based on AI/ML predictions and buffer status, the solution addresses inefficient bearer reconfiguration issues, optimizing data rates and reliability in communication systems.

GB2642193APending Publication Date: 2026-01-07NOKIA TECHNOLOGIES OY
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
GB2024009097
Authority / Receiving Office
GB · GB
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-06-25
Publication Date
2026-01-07

AI Technical Summary

Technical Problem

Existing communication systems struggle with inefficient bearer reconfiguration, particularly in scenarios involving Anchor Protocol Stack (APS) and Fast Protocol Stack (FPS), as initial radio resource control (RRC) configurations often become unsuitable or suboptimal due to changing QoS profiles and network capabilities, leading to subpar data rates and reliability.

Method used

The proposed solution involves UE-initiated or network-assisted dynamic reconfiguration of data radio bearers (DRBs) between APS and FPS, utilizing AI/ML predictions and buffer status to switch between DRB configurations autonomously or upon request, optimizing data rates and reliability through efficient DRB switching.

Benefits of technology

This approach enhances data communication efficiency by adapting DRB configurations based on real-time conditions, ensuring optimal data rates and reliability, thereby improving overall network performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

There is provided a method performed by a user equipment, the method comprising: receiving, from a network node, information for establishing a first data radio bearer, DRB, and a second DRB, wherein
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD Various example embodiments relate generally to reconfiguration of a data radio bearer. BACKGROUND It may happen that an initial radio resource control (RRC) configuration becomes unsuitable or suboptimal for communication, and this may require bearer reconfiguration. BRIEF DESCRIPTION According to some aspects, there is provided the subject matter of the independent claims. Some further aspects are defined in the dependent claims. The embodiments that do not fall under the scope of the claims are to be interpreted as examples useful for understanding the disclosure. LIST OF THE DRAWINGS In the following, the invention will be described in greater detail with reference to the embodiments and the accompanying drawings, in which Figure 1 presents a network to which one or more embodiments are applicable; Figure 2 shows an example of a dual APS and FPS radio protocol stack, according to an embodiment; Figures 3 to 5 depict some example embodiments for reconfiguration triggered by UE; Figures 6 to 8 depict some example embodiments for UE’s autonomous bearer profile switching; Figures 9 to 11 depict some example embodiments for UE’s autonomous traffic flow relocation between APS and FPS bearers; and Figure 12 illustrate an apparatus, according to some embodiments. DESCRIPTION OF EMBODIMENTS The following embodiments are exemplary. Although the specification may refer to "an", "one”, or "some" embodiment's] in several locations of the text, this does not necessarily mean that each reference is made to the same embodiment's], or that a particular feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments. Further, when a particular feature, structure, or characteristic is described in connection of an embodiment, it is within the knowledge of one skilled in the art to apply such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. It shall be understood that although the terms “first," "second” and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For the purposes of the present disclosure, the phrases "at least one of A or B”, "at least one of A and B", and "A and / or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). Embodiments described may be implemented in a communication network, such as any of the following radio access technologies (RATs): Worldwide Interoperability for Micro-wave Access (WiMAX), Global System for Mobile communications (GSM, 2G), GSM EDGE radio access Network (GERAN), General Packet Radio Service (GRPS), Universal Mobile Telecommunication System (UMTS, 3G) based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), Long Term Evolution (LTE), LTE-Advanced, and enhanced LTE (eLTE), 5G (also called NR), or any future RAT such as 6G. Moreover, communication within the communication network may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Frequency Division Duplex (FDD), Time Division Duplex (TDD), Multiple-Input Multiple-Output (MIMO), Orthogonal Frequency Division Multiple (OFDM), and / or Discrete Fourier Transform spread OFDM (DFT-s-OFDM). As used herein, the term "network device" or "network node” refers to a node in a communication network via which user equipment may access the network and / or which is capable of controlling radio communication and managing radio resources within a cell. The network node or network device may be referred to as a base station (BS), an access point (AP) or an access node. The network device may be, depending on the applied technology, for example, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), an NR NB (also referred to as a gNB), a Remote Radio Unit (RRU), a radio head (RH), a remote radio head (RRH), a relay, an Integrated Access and Backhaul (IA B) node, a low power node, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, or an aircraft network device. Moreover, in connection of split radio access network (RAN), the network device may refer to a centralised unit (CU) of a base station and / or a distributed unit (DU) of a base station. An interface between CU and DU may be referred to as an Fl interface in NR. In the split RAN architecture, node operations may be carried out, at least partly, in the central / centralized unit, CU, (e.g. server, host or node) operationally coupled to the DU, (e.g. a radio head / node). One CU may control one or more DUs, acting at least as transmit / receive (Tx / Rx) nodes. In some embodiments, the DUs may comprise e.g. a radio link control (RLC), medium access control (MAC) layer and a physical (PHY) layer, whereas the CU may comprise the layers above RLC layer, such as a packet data convergence protocol (PDCP) layer, a radio resource control (RRC) and an internet protocol (IP) layers. Other functional splits are possible too. In practice, any processing task may be performed in either the CU or the DU and the boundary where the responsibility is shifted between the CU and the DU may depend on the applied implementation. The term "terminal device" refers to any end device that may be capable of wireless communication. By way of example, a terminal device may be referred to as a communication device, user equipment (UE), a Subscriber Station (SS), or a Mobile Station (MS). The terminal device may include a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, USB dongles, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. A term “resource”, as used herein, may refer to radio resources in time domain, in frequency domain, in space domain, and / or in code domain. Some examples of resources include e.g. a physical resource block (PRB), a radio frame, a subframe, a time slot, a subband, a frequency region, a sub-carrier, a beam, etc. The term "transmission” and / or "reception” may refer to wirelessly transmitting and / or receiving via a wireless propagation channel on radio resources. Figure 1 illustrates an example of a communication network to which examples disclosed herein may be applied. The communication network or a cellular communication network may comprise a network node 110 providing one or more cells, such as cell 100, and a network node 112 providing one or more other cells, such as cell 102. Each cell may be, e.g., a macro cell, a micro cell, femto, or a pico cell, for example. The cell may define a coverage area or a service area of the corresponding access node. The network node 110 may provide a user equipment (UE) 120 (one or more UEs) with wireless access to the communication network. The wireless access may comprise downlink (DL) communication from the network node to the UE 120 and uplink (UL) communication from the UE 120 to the network node. Examples of uplink channels comprise physical uplink control channel (PUCCH) for transmitting control information and physical uplink shared channel (PUSCH) for transmitting data towards the network. Examples of downlink channels comprise physical downlink control channel (PDCCH) for transmitting control information and physical downlink shared channel (PDSCH) for transmitting data towards the user equipment. There may be a plurality of UEs 120, 122 in the system. Each of them may be served by the same or by different control nodes 110, 112. The UEs 120, 122 may communicate with each other, in case device-to-device (D2D) communication interface is established between them via a so-called sidelink (SL). Such D2D communications may be referred to as machine-to-machine, peer-to-peer (P2P) communications, or vehicle-to-vehicle (V2V), for example. In the case of multiple network nodes in the communication network, the network nodes may be connected to each other via an interface. LTE specifications call such an interface as X2 interface. An interface between an LTE node and a 5G node, or between two 5G nodes may be called Xn interface. The network nodes 110 and 112 may be further connected via another interface to a core network 116 of the communication network. The LTE specifications specify the core network as an evolved packet core (EPC), and the core network may comprise e.g. a mobility management entity (MME) and a gateway node. The MME may handle mobility of terminal devices in a tracking area encompassing a plurality of cells and handle signalling connections between the terminal devices and the core network. The gateway node may handle data routing in the core network and to / from the terminal devices. The 5G specifications specify the core network as a 5G core (5GC). The 5G core may comprise e.g. an access and mobility management function (AMF) and a user plane function / gateway (UPF) and other functions. The AMF may handle termination of non-access stratum (NAS) signalling, NAS ciphering &integrity protection, registration management, connection management, mobility management, access authentication and authorization, security context management. The UPF node may support packet routing and forwarding, packet inspection and quality of service (QoS) handling, for example. A design of 6G radio protocols may vary from legacy architecture. For example, one suggested approach relies on two stacks: • One radio protocol stack - called an Anchor Protocol Stack (APS) - designed for low bitrate services, coverage (e.g., bit-level optimizations) and reliability (e.g., with RLC ARQ); and • A second radio protocol stack - called a Fast Protocol Stack (FPS) - designed for high bitrate services, where the focus is on a processing-friendly and implementation-friendly design employing the concept of radio processing units (RPU, shown with dashed boxes in Figure 2), enabling parallel processing of the radio functions. An example of such a structure is depicted on Figure 2, assuming data splitting in PDCP layer at transmitter. With such an approach, the complex mechanisms that are justified for low bitrate services need not be used for very high bitrate services. The APS may be seen as a logical host for the control plane signalling such as idle mode, connect mode and related configurations of the radio resource control (RRC). The APS may act in a similar way as 5G NR, providing reliable and spectral efficient UP processing. By containing all control plane (CP) signalling within the APS, not only is the FPS free to focus on user plane transfer for a simplified design, but it need not be active when the bitrate requirements are low. FPS may be characterized with at least one of: no RLC AM, no RoHC, fixed header structures for SDAP / PDCP / RLC, fixed PDCP / RLC SN length. As shown in Figure 2, signaling radio bearers (SRBs), which carry RRC signalling and / or NAS messages, may in an embodiment be mapped to APS only, due to requirements on high reliability. On the other hand, data radio bearers (DRBs #1....N), at least for some DRBs, can be mapped to either APS and / or FPS. In an embodiment, not to both APS and FPS simultaneously. The APS and FPS configured bearers may have different properties. For instance, with APS configuration lower loss rate can be achieved due to support of for example RLC AM, whereas FPS configuration supports higher data rates due to possibility for parallel processing. When determining DRB configuration for a certain QoS How, whether it would be APS or FPS, these properties need to be considered and evaluated against QoS requirement of the QoS flow. Scenarios exist when the initial RRC configuration (configuring either APS or FPS bearer) becomes unsuitable or suboptimal, and APS to FPS or FPS to APS -reconfiguration may be beneficial. Below are some example scenarios: • QoS flow does not behave as assumed based on QoS profile. o For instance, a high priority non-GBR QoS flow is mapped to DRB with APS profile (called APS DRB), but the flow data rate suddenly rises high. Or the high peak data rate requirement becomes clear only from the data packet metadata (e.g. the PDU set size together with PDU set delay budget (PSDB). • QoS profile of a QoS flow changes o The characteristics of the application flow may change radically during the application session and therefore also QoS profile need to be changed (e.g. by the core network). o If alternative QoS profiles are configured to the gNB, the gNB may decide to start using the alternative QoS profile. • Handover o Target BS may have different capabilities in terms of APS and FPS processing. It is also noted that the need for APS / FPS reconfiguration may arise either on the UE or network side. The UE may determine, for instance, that it is not able to support the data rate with the existing (e.g. APS) configuration or the QoS profile of the data flow is changed, and the network decides the reconfigure the DRB accordingly. Current 3GPP mechanisms do not support such change and reconfiguration well, especially considering APS / FPS is relatively new concept which is targeted for 6G. Therefore, there is a need to optimize bearer reconfiguration in connection of 6G, and especially in connection of APS / FPS multiprotocol stack scenarios. To at least partially tackle this problem, there is proposed a solution for efficient data radio bearer (DRB) reconfiguration, e.g. for triggering reconfiguration of a DRB based on APS or FPS. Although APS and FPS are used as examples in the description, the reconfiguration can be based on any other protocol stack or protocol configurations. There are various manners for performing the proposed DRB reconfiguration procedure efficiently, as will be shown below. Figure 3 depicts an example method (let us call this option 1). The method may be computer-implemented. The method may be performed by a UE, such as UE 120 of Figure 1. As shown in Figure 3, the UE in step 300 obtains a first DRB configuration for communication of a data flow with a network node, such as with the gNB HOofFigure 1. This first DRB configuration may be pre-configured in the memory of the UE, or the UE may receive the configuration from the gNB, e.g. in connection of the establishment of the DRB. In step 302, the UE determines to switch to a second DRB configuration, different than the first DRB configuration. This can happen before communication of the data flow has started or during the communication. For example, the UE may determine already from the QoS parameters received in a session setup that it can handle the QoS flow better with the second DRB configuration. Or the UE may have configured the DRB with the first DRB configuration, started communicating and then realize that the second DRB configuration would likely work better for this data flow. In an embodiment, the determination maybe based on determining that requirements for the communication of the data flow cannot be met with the first DRB configuration. For example, the first DRB configuration may be based on and / or may apply the APS, but the data flow requirements (e.g. QoS for the data flow) requires higher data rates. In such case the UE may decide to switch to another DRB configuration (such as to FPS DRB). Alternatively, the reliability may need to be increased, in which case the APS DRB may be better. In an embodiment, the determination is based on an indication received from a protocol layer above radio protocol layers. In an embodiment, the radio protocol layers comprise at least a Service Data Adaptation Protocol (SDAP) layer. For example, the upper layer may indicate to the SDAP layer that QoS cannot be met with the current DRB configuration. In an embodiment, the determination is based on a buffer status associated with the DRB. For example, the buffer becomes loaded over a predetermined threshold and this serves as an indication to the UE to change the DRB configuration from the first DRB configuration to the second DRB configuration. In an embodiment, the determination is based on expected or experienced transmission error rate of the data flow communication. For example, if current configuration results (e.g. during communication) or is expected to result (e.g. based on empirical data and / or simulations and / or prediction based on e.g. AI / ML) in an error rate that is higher than preconfigured error threshold, then the UE may determine to change the DRB configuration. In an embodiment, the determination is based on expected or experienced data rate of the data flow communication. For example, if current configuration results (e.g. during communication) or is expected to result (e.g. based on empirical data and / or simulations and / or prediction based on e.g. AI / ML) in data rate that is lower than required for the data flow (i.e. does not meet the QoS requirements), then the UE may determine to change the DRB configuration. In an embodiment, the determination is based on expected or experienced processing load at the UE. For example, if current configuration results (e.g. during communication) or is expected to result (e.g. based on empirical data and / or simulations and / or prediction based on e.g. AI / ML) in a processing load that is higher than preconfigured load threshold, then the UE may determine to change the DRB configuration. In step 304, the UE may transmit, to the gNB, a request for reconfiguring the DRB based on the second DRB configuration. Alternatively, if the UE is in possession of the parameters required for performing the reconfiguration, the UE may do that in an embodiment autonomously without asking for gNB’s permission. In an embodiment, the request is transmitted as a radio resource control, RRC, message to the gNB. In another embodiment, the request is transmitted as a medium access control, MAC, control element or as a physical layer signalling, both of which may benefit from lower latency compared to RRC signaling. In an embodiment, the gNB allows the request. Then, based on transmitting the request, the UE obtains from the gNB instructions for reconfiguring the DRB based on the second DRB configuration. This may include e.g. parameters of the second DRB configuration. In an embodiment, if the second DRB configuration is already prestored / configured to the UE (indeed one, both or none of the first and second DRB configurations may be preconfigured to the UE), then the instructions may comprise a 1-bit indication on whether the reconfiguration is allowed or not. In an embodiment, the instructions are comprised in at least one: a radio resource control, RRC, reconfiguration request message, a MAC control element, or a physical layer signalling. Consequently, the UE may reconfigure, based on the instructions, the DRB from the first DRB configuration to the second DRB configuration. After this, the communication of the data flow may start or continue on the DRB that is now configured with the second DRB configuration. In an embodiment the gNB may decline the request, in which case the communication of the data flow may stop or still continue based on the (possibly suboptimal) first DRB configuration. In one embodiment, a high network load, which may not be visible to the UE, may be a reason to reject the request. This may be because requested high reliability cannot be achieved together with high data rate. In an embodiment, one of the two DRB configurations is adapted to low or lower bitrate services and the other of the two bearer configurations is adapted to high or higher bitrate services. For example, one of the two DRB configurations is based on an Anchor Protocol Stack, APS, profile and the other of the two DRB configurations is based on a Fast Protocol Stack, FPS, profile. In some cases, the first DRB configuration is the one based on the APS and the second DRB configuration is the one based on the FPS. In some other cases, the first DRB configuration is the one based on the FPS and the second DRB configuration is the one based on the APS. Looking this embodiment (option 1) of Figure 3 from the network node point of view, Figure 4 provides a method that is performed by a network node, such as the gNB 110. The method may be computer-implemented. In step 400, the gNB establishes a DRB, based on a first DRB configuration for communication of a data flow with the UE. The gNB may establish the DRB with the first DRB configuration based on a QoS profile of the data flow. That is the gNB may determine that the first DRB configuration fulfils the QoS requirements for the data flow. The first DRB configuration may be based on APS or FPS. In step 402, the gNB may receive from the UE a request for reconfiguring the DRB based on a second DRB configuration (as explained in connection of figure 3), and in step 404 determine whether or not to allow the requested bearer reconfiguration. In case the gNB determines that the requested bearer reconfiguration is to be allowed, the gNB may transmit instructions to the UE for reconfiguring the DRB from the first DRB configuration to the second DRB configuration (as explained above). Figure 5 depicts a signaling flow diagram for option 1 between UE and gNB for UE triggered bearer profile change (bearer reconfiguration). In step 1, the gNB establishes a radio bearer. Radio bearer configuration may initially be based on the QoS profiles of the QoS flows received from the core network in a session establishment- or session modification procedures. In step 2 the UE determines a need for bearer profile change. For example, the UE determines that the data flow cannot be served with the existing bearer profile (APS or FPS). Determination may be based, for example, on the indication from the upper layers, DRB’s buffer status, experienced packet error rate, experienced data rate, processing load within UE, etc. In step 3, the UE sends a bearer profile change request to the gNB. For example, the UE sends the request to the gNB requesting bearer profile reconfiguration from APS to FPS or FPS to APS. The request may be sent in a RRC-protocol message or in a MAC protocol's control element (CE). If MAC CE (or PHY signalling) is used, a 1 bit indication may be enough, where the 1 bit indication indicates whether the APS or FPS profile is requested, or whether the profile needs to be changed or not. In step 4, the gNB verifies if the bearer profile change is possible and if so, gNB issues a RRC re-configuration procedure for changing the bearer profile. Figure 6 depicts an example method (let us call this option 2). The method may be computer-implemented. The method may be performed by a UE, such as UE 120 of Figure 1. In this option 2, it is assumed that one QoS flow or multiple QoS flows mapped to a DRB (data flow) can be delivered either with APS or FPS, i.e., the DRB carrying the data can be configured based on either APS of FPS. In this option, the UE may change the DRB configuration, as the UE is configured by gNB to trigger reconfiguration when a certain at least one condition matches (e.g. data arrival, NAS indication, etc.). In step 600, the UE receives, from a network node such as gNB 110, a first DRB configuration and a second DRB configuration for configuring a DRB for communication of a data flow. For example, the gNB configures for one traffic flow a DRB with two alternative configurations, one with APS and another with FPS profile. This option 2 may be useful when the gNB determines that the traffic profile of the QoS flow can vary a lot. Alternatively, the DRB configurations can be prestored at the UE. In step 602, the UE configures the DRB based on the first DRB configuration. This may be based on gNB instruction to initially configure the DRB based on the first DRB configuration. In step 604, the UE detects that a condition for switching the first DRB configuration to the second DRB configuration is fulfilled. This can happen before the communication has started or during the communication. The UE monitors the condition(s) for triggering bearer profile / configuration switching. For example, the UE may determine already from the QoS parameters received in a session setup that it can handle the QoS flow better with the second DRB configuration. Or the UE may have configured the DRB with the first DRB configuration, started communicating and then realize (i.e. detect one or more of the predefined condition(s)) that the second DRB configuration would likely work better for this data flow. In an embodiment, the UE obtains information indicating at least one condition to be monitored for switching the configuration of the DRB. The gNB may send information indicating the at least one condition, or the condition may be preconfigured to the UE. In an embodiment, detecting the condition comprises detecting that signal quality associated with the DRB meets a predetermined threshold. For example, if signal quality is higher than a threshold, the UE may decide that switching to a DRB configuration providing higher data rates is advisable. If the signal quality is low, then keeping lower data rate (and hence more robust) communication may be beneficial. In an embodiment, detecting the condition comprises detecting an indication received from a protocol layer above radio protocol layers. In an embodiment, the radio protocol layers comprise at least a Service Data Adaptation Protocol (SDAP) layer. For example, the upper layer may indicate to the SDAP layer that QoS cannot be met with the current DRB configuration. In an embodiment, detecting the condition comprises detecting a condition of a buffer status associated with the DRB. For example, the buffer becomes loaded over a predetermined threshold, and this serves as an indication to the UE to change the DRB configuration from the first DRB configuration to the second DRB configuration. In an embodiment, detecting the condition comprises detecting a condition associated with expected or experienced transmission error rate of the data flow communication. For example, if current configuration results or is expected to result (e.g. based on empirical data and / or simulations and / or prediction based on e.g. AI / ML) in an error rate that is higher than preconfigured error threshold, then the UE may determine to change the DRB configuration. In an embodiment, detecting the condition comprises detecting a condition associated with expected or experienced data rate of the data flow communication. For example, if current configuration results or is expected to result (e.g. based on empirical data and / or simulations and / or prediction based on e.g. AI / ML) in data rate that is lower than required (than a preconfigured threshold) for the data flow (i.e. does not meet the QoS requirements), then the UE may determine to change the DRB configuration. In an embodiment, detecting the condition comprises detecting a condition associated with expected or experienced processing load at the UE For example, if current configuration results or is expected to result (e.g. based on empirical data and / or simulations and / or prediction based on e.g. AI / ML) in a processing load that is higher than preconfigured load threshold, then the UE may determine to change the DRB configuration. In step 606, the UE, based on detecting the condition, reconfigures the DRB based on the second DRB configuration. In an embodiment, the UE can do this reconfiguration without asking for permission about reconfiguration from the gNB. For example, the UE starts mapping UL packets of the QoS flow to the alternative bearer profile and the gNB reflectively change the DL mapping accordingly. However, in another embodiment, the UE, based on detecting the condition, transmits, to the gNB, an indication for reconfiguring the DRB based on the second DRB configuration, and then receives, from the gNB, an acknowledgment for the reconfiguration, after which the reconfiguration is done by the UE. Such request may be transmitted as one of: a radio resource control, RRC, message, a medium access control, MAC, control element or a physical layer signalling. In an embodiment, one of the two DRB configurations is adapted to low bitrate services and the other of the two bearer configurations is adapted to high bitrate services. For example, one of the two DRB configurations is based on an Anchor Protocol Stack, APS, profile and other of the two DRB configurations is based on a Fast Protocol Stack, FPS, profile. In some cases, the first DRB configuration is the one based on the APS and the second DRB configuration is the one based on the FPS. In some other cases, the first DRB configuration is the one based on the FPS and the second DRB configuration is the one based on the APS. Looking this embodiment (option 2) of Figure 6 from the network node point of view, Figure 7 provides a method that is performed by a network node, such as the gNB 110. The method may be computer-implemented. In step 700, the gNB establish a DRB for communication of a data flow with the UE. In step 702, which may be simultaneous with step 700, the gNB transmits, to the UE, a first DRB configuration and a second DRB configuration for configuring the DRB. In step 704, which may be simultaneous with step 702, the gNB may instruct the user equipment to configure the DRB based on the first DRB configuration. That is, during bearer establishment, only one bearer profile / configura-tion is activated. The establishment of the DRB initially with the first DRB configuration may be based on a QoS profile of the data flow. In step 706, the gNB detects that the DRB has been or should be reconfigured based on the second DRB configuration. There are couple of ways for the gNB to detect this. In an embodiment, the gNB may receive, from the UE, an indication for reconfiguring the DRB based on the second DRB configuration. As a response, the gNB transmits, to the UE, an acknowledgment for the reconfiguration. The acknowledgement is comprised in at least one: a radio resource control, RRC, reconfiguration request message, a MAC control element or a physical layer signalling. After this, the UE may reconfigure the bearer based on the second DRB configuration. Similarly, the gNB may reconfigure the bearer based on the second DRB configuration. In this way the gNB is aware that the DRB will be reconfigured. In another embodiment, the UE autonomously reconfigures the bearer based on the pre-obtained second DRB configuration. The gNB may monitor data based on the two DRB configurations, detect data based on the second DRB configuration that has not been instructed to be currently applied, and determine that the DRB has been reconfigured by the user equipment based on the second DRB configuration. The gNB may then reflectively change the DL configuration accordingly, i.e. reconfigure the DRB based on the second DRB configuration for DL transmissions. Figure 8 depicts a signaling flow diagram for option 2 between UE and gNB for UE autonomous bearer profile switching (bearer reconfiguration). In step 1, within the procedure of radio bearer establishment for one QoS flow / DRB, both APS and FPS bearer profiles / configurations are configured to the UE, but only one profile is selected / activated (e.g. the first DRB configuration). In addition, the UE may be configured with the at least one condition for the UE initiated bearer profile switching. Examples of the condition triggering bearer profile switching could be at least one of: buffer status (incl. buffer size over a threshold, buffer size changes over a threshold, etc.), buffering time (PDCP discarding), error rate, RLC retransmission rate, activity indication from upper layers, or received signalling quality, etc. In step 2, the UE monitors the configured condition(s) for potential bearer profile switching. In step 3, once the condition(s) are fulfilled, the UE determines a need to switch bearer profile. This may be because the other DRB configuration (also called profile) could potentially serve the requirements for the data flow better. Consequently, in step 4, the UE may send a “Bearer Switching indication” to gNB via RRC signalling or MAC CE, for example. In step 5, the gNB acknowledges the indication by sending "Bearer Switching ACK" to UE. As such, with this example procedure, UE can determine and indicate bearer profile switching. Alternatively, as the UE is already aware of both DRB configurations, the UE can perform the bearer profile switch autonomously, as explained above. Compared to option 1, the UE in option 1 has only one DRB configuration and a reconfiguration change is based on UE’s own criteria (see step 2 of Figure 5), while in option 2 it is proposed that the UE has both DRB configurations and the UE is also configured with predetermined one or more conditions to monitor. Figure 9 depicts an example method (let us call this option 3). The method may be computer-implemented. The method may be performed by a UE, such as UE 120 of Figure 1. In this option 3, an UE initiated traffic flow re-mapping is provided. In step 900, the UE receives, from a network node such as gNB 110, information for establishing a first DRB and a second DRB, wherein the first DRB is associated with a first DRB configuration and the second DRB is associated with a second DRB configuration. That is, one difference to the option 2 is that NW configures to the UE two alternative DRBs, one with APS and other with FPS bearer profiles, for a traffic flow, instead of one DRB with two alternative configurations (as in option 2). In step 902, the UE determines that the first DRB is to be applied for communication of a data flow with the network node. This can be based on network indication (e.g. RRC configuration includes the initial mapping of traffic flow to one of the two DRBs), or based on UE detecting that QoS is likely better met with the first DRB (that is associated with the first DRB configuration). In step 904, the UE detects a condition for switching from the first DRB to the second DRB. The condition(s) to monitor may be received from network, or may be preconfigured to the UE. The condition(s) and how UE behaves with respect to the condition(s) may be the same as explained above in connection of option 2 (see Figures 6 to 8). In step 906, the UE, based on detecting the condition, apply the second DRB for the communication of the data flow with the network node. In an embodiment, based on detecting the condition, the UE transmits, to the gNB, a request for switching the DRB. The request may be transmitted as a radio resource control, RRC, message, as a medium access control, MAC, control element or as a physical layer signalling. The UE may then receive an acknowledgment for switching the bearer. The acknowledgement is comprised in at least one: a radio resource control, RRC, reconfiguration request message, a MAC control element or a physical layer signalling. Then, the UE may switch the bearer from the applied first DRB to the second DRB (which is associated with the second DRB configuration). In another embodiment, based on detecting the condition, the UE changes the bearer without asking for permission from the gNB. In an embodiment, one of the two DRB configurations is adapted to low bitrate services and the other of the two bearer configurations is adapted to high bitrate services. For example, one of the two DRB configurations is based on an Anchor Protocol Stack, APS, profile and other of the two DRB configurations is based on a Fast Protocol Stack, FPS, profile. In some cases, the first DRB configuration is the one based on the APS and the second DRB configuration is the one based on the FPS. In some other cases, the first DRB configuration is the one based on the FPS and the second DRB configuration is the one based on the APS. Looking this embodiment (option 3) of Figure 9 from the network node point of view, Figure 10 provides a method that is performed by a network node, such as the gNB 110. The method may be computer-implemented. In step 1000, the gNB transmits, to the UE, information for establishing a first DRB and a second DRB, wherein the first DRB is associated with a first DRB configuration and the second DRB is associated with a second DRB configuration. The decision to establish two bearers with the first and second DRB configuration, respectively, may be based on a QoS profile of the data flow. For example, if it is expected that data rate requirements vary a lot, it may be beneficial to establish two bearers for quick remapping of data flow. In step 1002, the gNB determines that the first DRB is to be applied for communication of a data flow with the user equipment. This may be based on e.g. QoS requirements for the data flow. The gNB may instruct the UE to use the first DRB, at least initially. Or the gNB may detect based on incoming data that the first DRB is being applied currently. In step 1004, the gNB determines that the first DRB has been or should be switched to the second DRB for the communication of the data flow. As said, in an embodiment, the gNB may be in control of the switch by ACKing / NACKing a request for changing the bearer for the data flow. For example, the gNB may receive from the user equipment a request for switching the DRB, determine whether or not to allow the requested bearer switch, and transmit, to the user equipment, an acknowledgment for the switch, and then apply the second DRB for communication of the data flow. However, in another embodiment, the gNB monitors data based on the two DRBs. In this way, the gNB may detect data based on the second DRB that has not been instructed to be currently applied. Based on this detection, the gNB may determine that the DRB has been switched from the first DRB to the second DRB by the user equipment. In step 1006, the gNB may then apply the second DRB for communication of the data flow. Figure 11 depicts an example signaling flow diagram for option 3 (UE autonomous traffic flow relocation between APS and FPS bearers) between UE and gNB. In step 1, the NW establishes two separate DRBs, one with APS configuration and another with FPS configuration. The traffic flow is associated with both DRBs and initial effective mapping is configured to one DRB and alternative mapping to another. The QoS flow has effective mapping to only single DRB at one time. The NW may also configure conditions for UE to determine which one of the alternative DRBs shall be used for a flow or when the UE should initiate the traffic flow re-mapping to the alternative DRB. In step 2, the UE monitors the configured conditions for potential bearer switching, i.e. for initiating traffic flow remapping. In step 3, the UE determines the need for traffic flow re-mapping due to fulfilment of the configured condition(s). This may happen in various manners, e.g. either by sending re-mapping request to NW, or by start sending UL traffic through the alternative DRB to the gNB. In step 4a, the UE changes mapping of UL direction of the traffic flow to the alternative DRB (i.e. to the second DRB), i.e. makes alternative mapping as an effective mapping instead of the first DRB. In this embodiment of step 4, the UE sends re-mapping request to the gNB requesting the change to the alternative mapping (i.e. to map the data to the second DRB which is associated with the second DRB configuration and which has been already established based on the information received in step 1). The gNB decides to change mapping of the DL part of the traffic flow to the alternative DRB and sends an ACK to the UE. In step 4b (alternative to the Step 4a), the UE changes mapping of UL direction of the traffic flow to the alternative DRB, i.e. makes the alternative mapping to be the effective mapping, and starts sending UL packets through this alternative DRB. The gNB detects that UL packets are arriving through alternative DRB and determines that UE has changed the mapping. The gNB changes DL mapping accordingly. That is, the gNB detects that the UL traffic flow is remapped to the alternative DRB and re-maps DL flow accordingly. It is worth to note that "bearer profile" is used in the discussion above. Other terminologies for example "bearer configuration" or "bearer type" can be used as well. One point is that the two profiles of the same radio bearer are sufficiently different and lead to different processing in RAN. One benefit of the presented embodiments include that instead of core network or RAN, the UE may trigger the APS / FPS reconfiguration. This leads to more optimal DRB reconfiguration, because it is the UE which is more processing power restricted than the network side, and thus it may be beneficial for the UE to determine or at least suggest when to make DRB configuration switch. An embodiment, as shown in Figure 12, provides an apparatus 10 com prising a control circuitry (CTRL) 12, such as at least one processor, and at least one memory 14 storing instructions that, when executed by the at least one processor, cause the apparatus at least to carry out any one of the above-described processes. In an example, the at least one memory and the computer program code (software), are configured, with the at least one processor, to cause the apparatus to carry out any one of the above-described processes. The control circuitry 12 may comprise relevant circuitry / ies for performing the functions, according to any of the embodiments. The memory may be implemented using any suitable data storage tech nology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The memory may comprise a database for storing data. In an embodiment, the apparatus 10 is or is comprised in a UE, such as the UE 120. The apparatus may be caused to execute some of the functionalities of the above described processes, such as the steps of Figures 3, 6 or 9. In another embodiment, the apparatus 10 is or is comprised in a net work node, such as the gNB 110. The apparatus may be caused to execute some of the functionalities of the above described processes, such as the steps of Figures 4, 7 or 10, for example. The apparatus may further comprise a radio interface (TRX) 16 comprising hardware and / or software for realizing communication connectivity according to one or more communication protocols. The TRX may provide the apparatus with communication capabilities to a user equipment and / or to other entities of the base station, for example. The apparatus may also comprise a user interface 18 comprising, for example, at least one keypad, a microphone, a touch display, a display, a speaker, etc. The user interface may be used to control the apparatus by the user. The control circuitry 12 may comprise relevant circuitry / ies for performing the functions, according to any of the embodiments. OR From SAMSON application (328742, also boiler plate): The processor 220 executes instructions to provide some or all of the functionalities described herein as being provided by a wireless device / entity or UE, and the memory 230 stores the instructions executed by the processor 220. In some embodiments, the processor 220 and the memory 230 form a processing circuitry. As used in this application, the term 'circuitry' refers to all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and / or digital circuitry, and (b) combinations of circuits and soft-ware (and / or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processor(s) / software including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus to perform various functions, and (c) circuits, such as a microprocessor(s) or a portion of a micropro-cessor(s), that require software or firmware for operation, even if the software or firmware is not physically present This definition of 'circuitry' applies to all uses of this term in this application. As a further example, as used in this application, the term ‘circuitry’ would also cover an implementation of merely a processor (or multiple processors) or a portion of a processor and its (or their) accompanying software and / or firmware. The term 'circuitry' would also cover, for example and if applicable to the particular element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or another network device. In an embodiment, at least some of the processes described may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the processes may include at least one of the following: detector, processor (including dual-core and multiple-core processors), digital signal processor, controller, receiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, antenna, antenna circuitry, and circuitry. A term non-transitory, as used herein, is a limitation of the medium itself (i.e. tangible, not a signal) as opposed to a limitation on data storage persistency (e.g. RAM vs. ROM). As used herein the term "means” is to be construed in singular form, i.e. referring to a single element, or in plural form, i.e. referring to a combination of single elements. Therefore, terminology "means for [performing A, B, C]", is to be interpreted to cover an apparatus in which there is only one means for performing A, B and C, or where there are separate means for performing A, B and C, or partially or fully overlapping means for performing A, B, C. Further, terminology “means for performing A, means for performing B, means for performing C" is to be interpreted to cover an apparatus in which there is only one means for performing A, B and C, or where there are separate means for performing A, B and C, or partially or fully overlapping means for performing A, B, C. The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the appa-ratus(es) of embodiments may be implemented within one or more applicationspecific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be carried out through modules of at least one chip set (e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems described herein may be rearranged and / or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art. Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example. The computer program medium may be a non-transitory medium. Coding of software for cariying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art. Following is a list of some aspects of option 1. According to a first aspect, there is provided a method performed by a user equipment, comprising: obtaining a first data radio bearer, DRB, configuration for communication of a data flow with a network node; determining to switch to second DRB configuration; and transmitting, to the network node, a request for reconfiguring the DRB based on the second DRB configuration. Various embodiments of the first aspect may comprise at least one feature from the following bulleted list: • based on transmitting the request, obtaining from the network node instructions for reconfiguring the DRB based on the second DRB configuration; and reconfiguring, based on the instructions, the DRB from the first DRB configuration to the second DRB configuration. • wherein the determining comprises determining that requirements for the communication of the data flow cannot be met with the first DRB configuration. • wherein the determination is based at least one of the following: an indication received from a protocol layer above radio protocol layers, a buffer status associated with the DRB, expected or experienced transmission error rate of the data flow communication, expected or experienced data rate of the data flow communication, or expected or experienced processing load at the user equipment. • wherein the request is transmitted as a radio resource control, RRC, message, as a medium access control, MAC, control element or as a physical layer signalling. • wherein one of the two DRB configurations is adapted to low bitrate services and the other of the two bearer configurations is adapted to high bitrate services. • wherein one of the two DRB configurations is based on an Anchor Protocol Stack, APS, profile and other of the two DRB configurations is based on a Fast Protocol Stack, FPS, profile. According to a second aspect, there is provided a method performed by a network node, comprising: establishing a data radio bearer, DRB, based on a first DRB configuration for communication of a data flow with a user equipment; receiving from a user equipment a request for reconfiguring the DRB based on a second DRB configuration; and determining whether or not to allow the requested bearer reconfiguration. Various embodiments of the second aspect may comprise at least one feature from the following bulleted list: • based on determining that the requested bearer reconfiguration is allowed, transmit instructions to the user equipment for reconfiguring the DRB from the first DRB configuration to the second DRB configuration. • wherein the instructions are comprised in at least one: a radio resource control, RRC, reconfiguration request message, a MAC control element or as a physical layer signalling. • wherein one of the two DRB configurations is based on an Anchor Protocol Stack, APS, profile and other of the two DRB configurations is based on a Fast Protocol Stack, FPS, profile. • establish the DRB with the first DRB configuration based on a QoS profile of the data flow. According to a third aspect, there is provided a user equipment, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the user equipment at least to: obtain a first data radio bearer, DRB, configuration for communication of a data flow with a network node; determine to switch to second DRB configuration; and transmit, to the network node, a request for reconfiguring the DRB based on the second DRB configuration. Various embodiments of the third aspect may comprise at least one feature from the bulleted list under the first aspect. According to a fourth aspect, there is provided a network node, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network node at least to: establish a data radio bearer, DRB, based on a first DRB configuration for communication of a data flow with a user equipment; receive from a user equipment a request for reconfiguring the DRB based on a second DRB configuration; and determine whether or not to allow the requested bearer reconfiguration. Various embodiments of the fourth aspect may comprise at least one feature from the bulleted list under the second aspect. According to a fifth aspect, there is provided a computer program product embodied on a distribution medium and comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the first aspect or according to the second aspect. According to a sixth aspect, there is provided a computer program product comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the first aspect or according to the second aspect. According to a seventh aspect, there is provided an apparatus, comprising means for performing the method according to the first aspect or according to the second aspect, and / or means configured to cause the apparatus to perform the method according to the first aspect or according to the second aspect. Following is a list of some aspects of option 2. According to a first aspect, there is provided a method performed by a user equipment, comprising: receiving, from a network node, a first data radio bearer, DRB, configuration and a second DRB configuration for configuring a DRB for communication of a data flow; configuring the DRB based on the first DRB configuration; detecting a condition for switching the first DRB configuration to the second DRB configuration; based on detecting the condition, reconfiguring the DRB based on the second DRB configuration. Various embodiments of the first aspect may comprise at least one feature from the following bulleted list: • wherein the user equipment is further cause to: based on detecting the condition, transmit, to the network node, an indication for reconfiguring the DRB based on the second DRB configuration; receiving, from the network node, an acknowledgment for the reconfiguration. • wherein the request is transmitted as a radio resource control, RRC, message, as a medium access control, MAC, control element or as a physical layer signalling. • Obtaining information indicating at least one condition to be monitored for switching the configuration of the DRB, wherein the at least one condition comprises at least one of the following: signal quality associated with the DRB meeting a predetermined threshold, an indication received from a protocol layer above radio protocol layers, a buffer status associated with the DRB meeting a predetermined threshold, expected or experienced transmission error rate of the data flow communication meeting a predetermined threshold, expected or experienced data rate of the data flow communication meeting a predetermined threshold, or expected or experienced processing load at the user equipment meeting a predetermined threshold. • wherein one of the two DRB configurations is adapted to low bitrate services and the other of the two bearer configurations is adapted to high bitrate services. • wherein one of the two DRB configurations is based on an Anchor Protocol Stack, APS, profile and other of the two DRB configurations is based on a Fast Protocol Stack, FPS, profile. According to a second aspect, there is provided a method performed by a network node, comprising: establishing a data radio bearer, DRB, for communication of a data flow with a user equipment; transmitting, to the user equipment, a first DRB configuration and a second DRB configuration for configuring the DRB; instructing the user equipment to configure the DRB based on the first DRB configuration; determining that the DRB has been or should be reconfigured based on the second DRB configuration. Various embodiments of the second aspect may comprise at least one feature from the following bulleted list: • receiving from the user equipment an indication for reconfiguring the DRB based on the second DRB configuration; transmitting, to the user equipment, an acknowledgment for the reconfiguration. • wherein the acknowledgement is comprised in at least one: a radio resource control, RRC, reconfiguration request message, a MAC control element or as a physical layer signalling. • transmitting, to the user equipment, information indicating at least one condition to be monitored for switching the configuration of the DRB, wherein the at least one condition comprises at least one of the following: signal quality associated with the DRB meeting a predetermined threshold, an indication received from a protocol layer above radio protocol layers, a buffer status associated with the DRB meeting a predetermined threshold, expected or experienced transmission error rate of the data flow communication meeting a predetermined threshold, expected or experienced data rate of the data flow communication meeting a predetermined threshold, or expected or experienced processing load at the user equipment meeting a predetermined threshold. • establishing the DRB with the first DRB configuration based on a QoS profile of the data flow. • monitoring data based on the two DRB configurations; detecting data based on the second DRB configuration that has not been instructed to be currently applied; determining that the DRB has been reconfigured by the user equipment based on the second DRB configuration. • wherein one of the two DRB configurations is based on an Anchor Protocol Stack, APS, profile and other of the two DRB configurations is based on a Fast Protocol Stack, FPS, profile. According to a third aspect, there is provided a user equipment, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the user equipment at least to: receive, from a network node, a first data radio bearer, DRB, configuration and a second DRB configuration for configuring a DRB for communication of a data flow; configure the DRB based on the first DRB configuration; detect a condition for switching the first DRB configuration to the second DRB configuration; based on detecting the condition, reconfigure the DRB based on the second DRB configuration. Various embodiments of the third aspect may comprise at least one feature from the bulleted list under the first aspect. According to a fourth aspect, there is provided a network node, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network node at least to: establish a data radio bearer, DRB, for communication of a data flow with a user equipment; transmit, to the user equipment, a first DRB configuration and a second DRB configuration for configuring the DRB; instruct the user equipment to configure the DRB based on the first DRB configuration; determine that the DRB has been or should be reconfigured based on the second DRB configuration. Various embodiments of the fourth aspect may comprise at least one feature from the bulleted list under the second aspect. According to a fifth aspect, there is provided a computer program product embodied on a distribution medium and comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the first aspect or according to the second aspect. According to a sixth aspect, there is provided a computer program product comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the first aspect or according to the second aspect. According to a seventh aspect, there is provided an apparatus, comprising means for performing the method according to the first aspect or according to the second aspect, and / or means configured to cause the apparatus to perform the method according to the first aspect or according to the second aspect. Following is a list of some aspects of option 3. According to a first aspect, there is provided a method performed by a user equipment, comprising: receiving, from a network node, information for establishing a first data radio bearer, DRB, and a second DRB, wherein the first DRB is associated with a first DRB configuration and the second DRB is associated with a second DRB configuration; determining that the first DRB is to be applied for communication of a data flow with the network node; detecting a condition for switching from the first DRB to the second DRB; based on detecting the condition, applying the second DRB for the communication of the data flow with the network node. Various embodiments of the first aspect may comprise at least one feature from the following bulleted list: • based on detecting the condition, transmitting, to the network node, a request for switching the DRB; receiving, from the network node, an acknowledgment for switching the bearer. • wherein the request is transmitted as a radio resource control, RRC, message, as a medium access control, MAC, control element or as a physical layer signalling. • obtaining information indicating at least one condition to be monitored for switching the configuration of the DRB, wherein the at least one condition comprises at least one of the following: signal quality associated with the DRB meeting a predetermined threshold, an indication received from a protocol layer above radio protocol layers, a buffer status associated with the DRB meeting a predetermined threshold, expected or experienced transmission error rate of the data flow communication meeting a predetermined threshold, expected or experienced data rate of the data flow communication meeting a predetermined threshold, or expected or experienced processing load at the user equipment meeting a predetermined threshold. • wherein one of the two DRB configurations is adapted to low bitrate services and the other of the two bearer configurations is adapted to high bitrate services. • wherein one of the two DRB configurations is based on an Anchor Protocol Stack, APS, profile and other of the two DRB configurations is based on a Fast Protocol Stack, FPS, profile. According to a second aspect, there is provided a method performed by a network node, comprising: transmitting, to a user equipment, information for establishing a first data radio bearer, DRB, and a second DRB, wherein the first DRB is associated with a first DRB configuration and the second DRB is associated with a second DRB configuration; determining that the first DRB is to be applied for communication of a data flow with the user equipment; determining that the first DRB has been or should be switched to the second DRB for the communication of the data flow; applying the second DRB for communication of the data flow. . Various embodiments of the second aspect may comprise at least one feature from the following bulleted list: • receiving from the user equipment a request for switching the DRB; determining to allow the requested bearer switch; transmitting, to the user equipment, an acknowledgment for the switch. • wherein the acknowledgement is comprised in at least one: a radio resource control, RRC, reconfiguration request message, a MAC control element or as a physical layer signalling. • transmitting, to the user equipment, information indicating at least one condition to be monitored for switching the configuration of the DRB, wherein the at least one condition comprises at least one of the following: signal quality associated with the DRB meeting a predetermined threshold, an indication received from a protocol layer above radio protocol layers, a buffer status associated with the DRB meeting a predetermined threshold, expected or experienced transmission error rate of the data flow communication meeting a predetermined threshold, expected or experienced data rate of the data flow communication meeting a predetermined threshold, or expected or experienced processing load at the user equipment meeting a predetermined threshold. • establishing the first and second DRBs based on the first and second DRB configurations, respectively, based on a QoS profile of the data flow. • monitoring data based on the two DRBs; detecting data based on the second DRB that has not been instructed to be currently applied; determining that the DRB has been switched from the first DRB to the second DRB by the user equipment. • wherein one of the two DRB configurations is based on an Anchor Protocol Stack, APS, profile and other of the two DRB configurations is based on a Fast Protocol Stack, FPS, profile. According to a third aspect, there is provided a user equipment, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the user equipment at least to: receive, from a network node, information for establishing a first data radio bearer, DRB, and a second DRB, wherein the first DRB is associated with a first DRB configuration and the second DRB is associated with a second DRB configuration; determine that the first DRB is to be applied for communication of a data flow with the network node; detect a condition for switching from the first DRB to the second DRB; based on detecting the condition, apply the second DRB for the communication of the data flow with the network node. Various embodiments of the third aspect may comprise at least one feature from the bulleted list under the first aspect. According to a fourth aspect, there is provided a network node, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network node at least to: transmit, to a user equipment, information for establishing a first data radio bearer, DRB, and a second DRB, wherein the first DRB is associated with a first DRB configuration and the second DRB is associated with a second DRB configuration; determine that the first DRB is to be applied for communication of a data flow with the user equipment; determine that the first DRB has been or should be switched to the second DRB for the communication of the data flow; apply the second DRB for communication of the data flow. Various embodiments of the fourth aspect may comprise at least one feature from the bulleted list under the second aspect. According to a fifth aspect, there is provided a computer program product embodied on a distribution medium and comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the first aspect or according to the second aspect. According to a sixth aspect, there is provided a computer program product comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the first aspect or according to the second aspect. According to a seventh aspect, there is provided an apparatus, comprising means for performing the method according to the first aspect or according to the second aspect, and / or means configured to cause the apparatus to perform the method according to the first aspect or according to the second aspect. Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.

Claims

1. A user equipment, comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the user equipment at least to:receive, from a network node, information for establishing a first data radio bearer, DRB, and a second DRB, wherein the first DRB is associated with a first DRB configuration and the second DRB is associated with a second DRB configuration;determine thatthe first DRB is to be applied for communication of a data flow with the network node;detect a condition for switching from the first DRB to the second DRB;based on detecting the condition, apply the second DRB for the communication of the data flow with the network node.

2. The user equipment of claim 1, wherein the user equipment is further cause to:based on detecting the condition, transmit, to the network node, a request for switching the DRB;receive, from the network node, an acknowledgment for switching the bearer.

3. The user equipment of claim 2, wherein the request is transmitted as a radio resource control, RRC, message, as a medium access control, MAC, control element or as a physical layer signalling.

4. The user equipment of any of claim 1 to 3, wherein the user equipment is further cause to:obtain information indicating at least one condition to be monitored for switching the DRB, wherein the at least one condition comprises at least one of the following:signal quality associated with the currently applied DRB meeting a predetermined threshold,an indication received from a protocol layer above radio protocol layers,a buffer status associated with the currently applied DRB meeting apredetermined threshold,expected or experienced transmission error rate of the data flow communication meeting a predetermined threshold,expected or experienced data rate of the data flow communication meeting a predetermined threshold, orexpected or experienced processing load at the user equipment meeting a predetermined threshold.

5. The user equipment of any of claims 1 to 4, wherein one of the first and second DRB configurations is adapted to low bitrate services and another of the first and second DRB configurations is adapted to high bitrate services.

6. The user equipment of any of claims 1 to 5, wherein one of the first and second DRB configurations is based on an Anchor Protocol Stack, APS, profile and another of the first and second DRB configurations is based on a Fast Protocol Stack, FPS, profile.

7. A network node, comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the network node at least to:transmit, to a user equipment, information for establishing a first data radio bearer, DRB, and a second DRB, wherein the first DRB is associated with a first DRB configuration and the second DRB is associated with a second DRB configuration;determine that the first DRB is to be applied for communication of a data flow with the user equipment;determine that the first DRB has been or should be switched to the second DRB for the communication of the data flow;apply the second DRB for communication of the data flow.

8. The network node of claim 7, wherein the network node is further cause to:receive from the user equipment a request for switching the DRB;determine to allow the requested bearer switch;transmit, to the user equipment, an acknowledgment for the switch.

9. The network node of claim 8, wherein the acknowledgement is comprised in at least one: a radio resource control, RRC, reconfiguration request message, a MAC control element or as a physical layer signalling.

10. The network node of any of claim 7 to 9, wherein the network node is further cause to:transmit, to the user equipment, information indicating at least one condition to be monitored for switching the configuration of the DRB, wherein the at least one condition comprises at least one of the following:signal quality associated with the currently applied DRB meeting a predetermined threshold,an indication received from a protocol layer above radio protocol layers,a buffer status associated with the currently applied DRB meeting a predetermined threshold,expected or experienced transmission error rate of the data flow communication meeting a predetermined threshold,expected or experienced data rate of the data flow communication meeting a predetermined threshold, orexpected or experienced processing load at the user equipment meeting a predetermined threshold.

11. The network node of any of claims 7 to 10, wherein the network node is further caused to:establish the first and second DRBs based on the first and second DRB configurations, respectively, based on a QoS profile of the data flow.

12. The network node of any of claims 7 to 11, wherein the network node is further caused to:monitor data based on the two DRBs;detect data based on the second DRB that has not been instructed to be currently applied;determine that the DRB has been switched from the first DRB to the second DRB by the user equipment.

13. The network node of any of claims 7 to 12, wherein one of the first and second DRB configurations is based on an Anchor Protocol Stack, APS, profile and another of the first and second DRB configurations is based on a Fast Protocol Stack, FPS, profile.

14. A method performed by a user equipment, comprising:receiving, from a network node, information for establishing a first data radio bearer, DRB, and a second DRB, wherein the first DRB is associated with a first DRB configuration and the second DRB is associated with a second DRB configuration;determining that the first DRB is to be applied for communication of a data flow with the network node;detecting a condition for switching from the first DRB to the second DRB;based on detecting the condition, applying the second DRB for the communication of the data flow with the network node.

15. A method performed by a network node, comprising:transmitting, to a user equipment, information for establishing a first data radio bearer, DRB, and a second DRB, wherein the first DRB is associated with a first DRB configuration and the second DRB is associated with a second DRB configuration;determining that the first DRB is to be applied for communication of a data flow with the user equipment;determining that the first DRB has been or should be switched to the second DRB for the communication of the data flow;applying the second DRB for communication of the data flow.

16. A computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when the program is executed by an apparatus, cause the apparatus to carry out the method according to any of claims 14 or 15.

17. A computer program product comprising program instructions which, when the program is executed by an apparatus, cause the apparatus to carry out the method according to any of claims 14 or 15.

18. An apparatus, comprising means for performing the method according to any of claims 14 or 15.5

Citation Information

Patent Citations

  • NR UDC -flexible DRB switch

    WO2023082035A1

  • Higher layer influence on QOS flow to DRB mapping

    WO2024035697A1

  • Data transfer using data radio bearers

    WO2024156415A1