Flows

TECHNICAL FIELD

[0001] This invention relates generally to wireless communications and, more specifically, relates to improving, e.g., reliability of communications for services such as ultrareliable low latency communications (URLLC).

BACKGROUND

[0002] Ultra-reliable low latency communications (URLLC) is a service category including services for latency-sensitive devices for applications like factory automation, autonomous driving, and remote surgery. These applications require, e.g., sub-millisecond latency with error rates that are lower than one packet loss in 10 ⁵ packets.

[0003] In order to support these types of ultra-reliable communications, various techniques are being explored. For a user equipment (UE), which is a wireless, typically mobile device that accesses a wireless (e.g., cellular) network, a typical uplink access to the wireless network requires quite a few steps and requires a relatively long time period. For instance, these steps require a grant from the network to the UE for the UE to use resources. To enable faster uplink communications, a configuration has been proposed to allow the UE to send data via a “grant-free” transmission. This improves latency.

[0004] Another area that can be improved is reliability, such as providing some type of redundancy for communications. This redundancy might involve two paths such that if one path fails, the other path is still available. The two paths can also be used for transmission duplication. In this situation, the paths may be used both at the same time and if a packet is lost on one path, the packet may still go through on the other path.

[0005] Regardless, these types of communications could still be improved upon.

BRIEF SUMMARY

[0006] This section is intended to include examples and is not intended to be limiting.

[0007] In an exemplary embodiment, a method is disclosed that includes, in a node in a wireless network, where a first data flow is transferred via a first path between two endpoints, l buffering a second data flow. At least one of the two endpoints is in the wireless network. The first and second data flows comprise a same data, and the node is in a second path between the two endpoints. The method further includes, in response to receiving indication the second data flow should be activated, sending by the node at least some of the buffered second data flow through the second path.

[0008] An additional exemplary embodiment includes a computer program, comprising code for performing the method of the previous paragraph, when the computer program is run on a processor. The computer program according to this paragraph, wherein the computer program is a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer. Another example is the computer program according to this paragraph, wherein the program is directly loadable into an internal memory of the computer.

[0009] An exemplary apparatus includes one or more processors and one or more memories including computer program code. The one or more memories and the computer program code are configured to, with the one or more processors, cause the apparatus to: in a node in a wireless network, where a first data flow is transferred via a first path between two endpoints, buffer a second data flow, wherein at least one of the two endpoints is in the wireless network, wherein the first and second data flows comprise a same data, and wherein the node is in a second path between the two end; and in response to receiving indication the second data flow should be activated, send by the node at least some of the buffered second data flow through the second path.

[0010] An exemplary computer program product includes a computer-readable storage medium bearing computer program code embodied therein for use with a computer. The computer program code includes: code, in a node in a wireless network, where a first data flow is transferred via a first path between two endpoints, for buffering a second data flow, wherein at least one of the two endpoints is in the wireless network, wherein the first and second data flows comprise a same data, and wherein the node is in a second path between the two endpoints; and code, in response to receiving indication the second data flow should be activated, for sending by the node at least some of the buffered second data flow through the second path.

[0011] In another exemplary embodiment, an apparatus comprises means for performing: in a node in a wireless network, where a first data flow is transferred via a first path between two endpoints, buffering a second data flow, wherein at least one of the two endpoints is in the wireless network, wherein the first and second data flows comprise a same data, and wherein the node is in a second path between the two endpoints; and in response to receiving indication the second data flow should be activated, sending by the node at least some of the buffered second data flow through the second path.

[0012] In an exemplary embodiment, a method is disclosed that includes, in a first node in a wireless network, setting up first and second data flows between two endpoints. At least one of endpoints is in the wireless network, and the first data flow is communicated via a first path through the wireless network between the two endpoints. The second data flow is sent via a second path through the wireless network between the two endpoints. The method includes selecting by the first node a second node in the second path to buffer the second data flow. The method further includes indicating by the first node to the second node that the second node is to buffer the second data flow and to send data through the second data flow in response to receiving indication the second data flow should be activated.

[0013] An additional exemplary embodiment includes a computer program, comprising code for performing the method of the previous paragraph, when the computer program is run on a processor. The computer program according to this paragraph, wherein the computer program is a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer. Another example is the computer program according to this paragraph, wherein the program is directly loadable into an internal memory of the computer.

[0014] An exemplary apparatus includes one or more processors and one or more memories including computer program code. The one or more memories and the computer program code are configured to, with the one or more processors, cause the apparatus to: in a first node in a wireless network, set up first and second data flows between two endpoints, wherein at least one of endpoints is in the wireless network, wherein the first data flow is communicated via a first path through the wireless network between the two endpoints, the second data flow is sent via a second path through the wireless network between the two endpoints; select by the first node a second node in the second path to buffer the second data flow; and indicate by the first node to the second node that the second node is to buffer the second data flow and to send data through the second data flow in response to receiving indication the second data flow should be activated.

[0015] An exemplary computer program product includes a computer-readable storage medium bearing computer program code embodied therein for use with a computer. The computer program code includes: code, in a first node in a wireless network, for setting up first and second data flows between two endpoints, wherein at least one of endpoints is in the wireless network, wherein the first data flow is communicated via a first path through the wireless network between the two endpoints, the second data flow is sent via a second path through the wireless network between the two endpoints; code for selecting by the first node a second node in the second path to buffer the second data flow; and code for indicating by the first node to the second node that the second node is to buffer the second data flow and to send data through the second data flow in response to receiving indication the second data flow should be activated.

[0016] In another exemplary embodiment, an apparatus comprises means for performing: in a first node in a wireless network, setting up first and second data flows between two endpoints, wherein at least one of endpoints is in the wireless network, wherein the first data flow is communicated via a first path through the wireless network between the two endpoints, the second data flow is sent via a second path through the wireless network between the two endpoints; selecting by the first node a second node in the second path to buffer the second data flow; and indicating by the first node to the second node that the second node is to buffer the second data flow and to send data through the second data flow in response to receiving indication the second data flow should be activated.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In the attached Drawing Figures:

[0018] FIG. 1 is a block diagram of one possible and non-limiting exemplary system in which the exemplary embodiments may be practiced;

[0019] FIG. 2 is a block diagram illustrating redundant user plane paths with multi- UE devices;

[0020] FIG. 3 is a block diagram illustrating utilization of redundant user plane paths with an IEEE Time Sensitive Networking (TSN) Frame Replication and Elimination for Reliability (FRER) function (where the source of the figure is 3 GPP TS 23.725); [0021] FIG. 4 is a schematic of (QoS flow-based) QoS framework in 5G;

[0022] FIG. 5 illustrates a fully duplicated network with overlaid radio cell coverage for a GSM-R system, from Hyeon Yeong Choi, et al, “Standards of Future Railway Wireless Communication in Korea”, Recent Advances in Computer Engineering, Communications and Information Technology, Tenerife, Spain (2014);

[0023] FIG. 6A is an illustration of a multi-UE device with a connection to a single gNB, in accordance with an exemplary embodiment;

[0024] FIG. 6B is an illustration of a multi-UE device with a connection to a multiple gNBs, in accordance with an exemplary embodiment;

[0025] FIG. 7 is a block diagram of an exemplary illustration with normal and buffered QoS flows in a multi-UE device case, in an exemplary embodiment;

[0026] FIG. 7A is a block diagram of an exemplary illustration with normal and buffered QoS flows in a single-UE device case, in an exemplary embodiment;

[0027] FIG. 8 is a signaling flow diagram showing embodiments for a multi-UE device example;

[0028] FIG. 9 illustrates an exemplary implementation in a multi-UE device scenario; [0029] FIG. 10 illustrates an exemplary implementation in case of DL buffering at a

UPF;

[0030] FIG. 11 illustrates an exemplary implementation in case of DL buffering at the gNB; and

[0031] FIG. 12 illustrates an exemplary implementation in case of UL buffering at the UE.

DETAILED DESCRIPTION OF THE DRAWINGS

[0032] Abbreviations that may be found in the specification and/or the drawing figures are defined below, at the end of the detailed description section.

[0033] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. All of the embodiments described in this Detailed Description are exemplary embodiments provided to enable persons skilled in the art to make or use the invention and not to limit the scope of the invention which is defined by the claims.

[0034] The exemplary embodiments herein describe techniques for resource efficient user plane redundancy control method with selective buffered QoS flows. Additional description of these techniques is presented after a system into which the exemplary embodiments may be used is described.

[0035] Turning to FIG. 1, this figure shows a block diagram of one possible and nonlimiting exemplary system in which the exemplary embodiments may be practiced. Two user equipment devices 110 and 112 are illustrated, as are a radio access network (RAN) node 170 (such as gNB), and network element(s) 190. In FIG. 1, the devices 110 and 112 are nodes in a wireless network 100 and communicate via respective wireless links 111, 113. These devices 110, 112 are wireless, typically mobile devices that can access and be part of a wireless network 100. The multi-UE device 110 implements two UEs 80-1 and 80-2, while the single-UE device 112 implements a single UE1 80-1. For ease of explanation, it is assumed that the single-UE device 112 is designed similarly to the multi-UE device 110, so only the possible internal configuration of the multi-UE device 110 is mainly described herein.

[0036] The multi-UE device 110 includes one or more processors 120, one or more memories 125, and one or more transceivers 130 interconnected through one or more buses 127. Each of the one or more transceivers 130 includes a receiver, Rx, 132 and a transmitter, Tx, 133. The one or more buses 127 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The one or more transceivers 130 are connected to one or more antennas 128. The one or more memories 125 include computer program code 123. The multi-UE device 110 includes a device controller 140, comprising one of or both parts 140-1 and/or 140-2. The multi-UE device 110 also two UEs, UE1 80-1 and UE2 80-2. UE1 80-1 comprises one of or both parts 80-11 and/or 80-12. UE2 80- 2 comprises one of or both parts 80-21 and/or 80-22. Each of these may be implemented in one or both of hardware or software. The device controller 140 may be implemented in hardware as device controller 140-1, the UE1 80-1 as UE1 80-11, and the UE2 80-2 as UE2 80-21, such as being implemented as part of the one or more processors 120. One or more of these may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the device controller 140 may be implemented as device controller 140-2, the UE1 80-1 implemented as UE 80-12, the UE2 80-2 implemented as UE 80-22, which may be implemented as computer program code 123 and executed by the one or more processors 120. For instance, the one or more memories 125 and the computer program code 123 may be configured to, with the one or more processors 120, cause the user equipment 110 to perform one or more of the operations as described herein. The multi-UE device 110 communicates with RAN node 170 via a wireless link 111.

[0037] The single-UE device 112 is assumed to be similar to multi-EiE device 110. The single-UE device 112 communicates via link 113 to the RAN node 170. The single-UE device 112 contains only one UE, UE1 80-1, which includes one or both of UE1 80-11 (e.g., implemented in hardware) and/or UE1 80-12 (e.g., implemented in software).

[0038] The RAN node 170 is a base station that provides access by wireless devices such as the multi-UE device 110 or single-UE device 112 to portions of the wireless network 100. The RAN node 170 may be, for instance, a base station for 5G, also called New Radio (NR). In 5G, the RAN node 170 may be a NG-RAN node, which is defined as either a gNB or an ng-eNB. A gNB is a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to a 5GC (e.g., the network element(s) 190). The ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC. The NG-RAN node may include multiple gNBs, which may also include a central unit (CU) (gNB-CU) 196 and distributed unit(s) (DUs) (gNB-DUs), of which DU 195 is shown. Note that the DU may include or be coupled to and control a radio unit (RU). The gNB-CU is a logical node hosting RRC, SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the FI interface connected with the gNB-DU. The FI interface is illustrated as reference 198, although reference 198 also illustrates a link between remote elements of the RAN node 170 and centralized elements of the RAN node 170, such as between the gNB-CU 196 and the gNB-DU 195. The gNB-DU is a logical node hosting RLC, MAC and PHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU. One gNB-CU supports one or multiple cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the FI interface 198 connected with the gNB- CU. Note that the DU 195 is considered to include the transceiver 160, e.g., as part of an RU, but some examples of this may have the transceiver 160 as part of a separate RU, e.g., under control of and connected to the DU 195. The RAN node 170 may also be an eNB (evolved NodeB) base station, for LTE (long term evolution), or any other suitable base station.

[0039] Although the various embodiments for the RAN node 170 have been described above, most of the time, this network node will be referred to as a gNB 170. This is just illustrative, however.

[0040] The RAN node 170 includes one or more processors 152, one or more memories 155, one or more network interfaces (N/W I/F(s)) 161, and one or more transceivers 160 interconnected through one or more buses 157. Each of the one or more transceivers 160 includes a receiver, Rx, 162 and a transmitter, Tx, 163. The one or more transceivers 160 are connected to one or more antennas 158. The one or more memories 155 include computer program code 153. The CU 196 may include the processor(s) 152, memories 155, and network interfaces 161. Note that the DU 195 may also contain its own memory/memories and processor(s), and/or other hardware, but these are not shown.

[0041] The RAN node 170 includes a control module 150, comprising one of or both parts 150-1 and/or 150-2, which may be implemented in a number of ways. The control module 150 may be implemented in hardware as control module 150-1, such as being implemented as part of the one or more processors 152. The control module 150-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the control module 150 may be implemented as control module 150-2, which is implemented as computer program code 153 and is executed by the one or more processors 152. For instance, the one or more memories 155 and the computer program code 153 are configured to, with the one or more processors 152, cause the RAN node 170 to perform one or more of the operations as described herein. Note that the functionality of the control module 150 may be distributed, such as being distributed between the DU 195 and the CU 196, or be implemented solely in the DU 195.

[0042] The one or more network interfaces 161 communicate over a network such as via the links 176 and 131. Two or more RAN nodes 170 communicate using, e.g., link 176. The link 176 may be wired or wireless or both and may implement, e.g., an Xn interface for 5G, an X2 interface for LTE, or other suitable interface for other standards. [0043] The one or more buses 157 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers 160 may be implemented as a remote radio head (RRH) 195 for LTE or a distributed unit (DU) 195 for gNB implementation for 5G, with the other elements of the RAN node 170 possibly being physically in a different location from the RRH/DU, and the one or more buses 157 could be implemented in part as, e.g., fiber optic cable or other suitable network connection to connect the other elements (e.g., a central unit (CU), gNB-CU) of the RAN node 170 to the RRH/DU 195. Reference 198 also indicates those suitable network link(s).

[0044] The wireless network 100 may include a network element or elements 190 that may include core network functionality, and which provides connectivity via a link or links 181 with a further network, such as a telephone network and/or a data communications network (e.g., the Internet). Such core network functionality for 5G may include access and mobility management function(s) (AMF(s)) and/or user plane functions (UPF(s)) and/or session management function(s) (SMF(s)). Such core network functionality for LTE may include MME (Mobility Management Entity)/SGW (Serving Gateway) functionality. These are merely exemplary functions that may be supported by the network element(s) 190, and note that both 5G and LTE functions might be supported. The RAN node 170 is coupled via a link 131 to a network element 190. The link 131 may be implemented as, e.g., an NG interface for 5G, or an SI interface for LTE, or other suitable interface for other standards. The network element 190 includes one or more processors 175, one or more memories 171, and one or more network interfaces (N/W I/F(s)) 180, interconnected through one or more buses 185. The one or more memories 171 include computer program code 173. The one or more memories 171 and the computer program code 173 are configured to, with the one or more processors 175, cause the network element 190 to perform one or more operations.

[0045] The wireless network 100 may implement network virtualization, which is the process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization. Network virtualization is categorized as either external, combining many networks, or parts of networks, into a virtual unit, or internal, providing network-like functionality to software containers on a single system. Note that the virtualized entities that result from the network virtualization are still implemented, at some level, using hardware such as processors 152 or 175 and memories 155 and 171, and also such virtualized entities create technical effects.

[0046] The computer readable memories 125, 155, and 171 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer readable memories 125, 155, and 171 may be means for performing storage functions. The processors 120, 152, and 175 may be of any type suitable to the local technical environment, and may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples. The processors 120,

152, and 175 may be means for performing functions, such as controlling the multi-UE device 110, RAN node 170, and other functions as described herein.

[0047] In general, the various embodiments of the devices 110, 112 can include, but are not limited to, cellular telephones such as smart phones, tablets, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, vehicles with a modem device for wireless Y2X (vehicle-to- everything) communication, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances (including Internet of Things, IoT, devices) permitting wireless Internet access and possibly browsing, IoT devices with sensors and/or actuators for automation applications with wireless communication tablets with wireless communication capabilities, as well as portable units or terminals that incorporate combinations of such functions.

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

[0049] As previously described, there are issues in achieving requirements for ultrareliable low latency communications (URLLC). As such, techniques for meeting URLLC have been being researched. For instance, methods to further enhance performance of URLLC services were studied as part of a 3 GPP Rel-16 Study Item and the results were captured in the 3GPP TR 23.725. One of the studied issues was how to improve end-to-end reliability achievable over 5G systems, which is especially important for new services such as those related to Industrial Internet of Things (IIoT), e.g., factory automation, smart grid operations, and the like. Since unscheduled service down-times are unacceptable for such applications, not only full redundancy of data paths in the network is required, but also hardware redundancy of the network nodes along this path might be needed. One of the solutions considered by the 3 GPP SA2 WG was then to achieve complete user plane redundancy provided by having multi-UE devices as depicted in FIG. 2.

[0050] FIG. 2 is a block diagram illustrating redundant user plane paths with multi- UE devices. The wireless network 100-1 in this example includes and interfaces with a multi- UE device 110 having a device controller 140 and two UEs, UE1 80-1 and UE2 80-2, and comprises two gNBs 170-1 and 170-2, and two User Plane Functions (UPFs) 210-1, 210-2 (e.g., each implemented as illustrated by a network element 190 of FIG. 1), and connects to a data network 230 that comprises a communication endpoint 270. The data network 230 may include a cellular network and/or the Internet and/or a cloud of computers, and/or other networks, and may be wired or wireless or a combination of these. There are two redundant paths 220-1 and 220-2 that are shown, and the communication endpoint 270 terminates one end of each path 220, while the multi-UE device 110 terminates the other end of each path.

[0051] In 5G terminology, a data network 230 is “external” to the 3GPP network 102 (or wireless network 100) and terminates an application/service outside the 3 GPP core network 235. The 3 GPP network is in an exemplary embodiment a mobile network, which comprises both wireless and wired parts of a 5G system. Thus, a communication endpoint 270 in a data network would mean a device outside the 5G network 102. The communication endpoint 270 in the data network 230 could be, e.g., an application server providing operator services or third- party services, or a termination point of industrial automation applications e.g. controllers and sensors / actuators (such as robotic devices). In one example, an IEEE Time-Sensitive Network (TSN) part of the IEEE 802. IQ standard could be considered, where a TSN system / controller / device in the data network 230 is connected to a group of TSN devices (e.g., as multi-UE devices 110) through the 5G network 102. Other examples are possible, e.g., it is possible that communicating endpoints are both in the 3 GPP network and the data is exchanged without interfacing with an external data network.

[0052] As can be seen in FIG. 2, there is no single point of failure in this 5G system architecture, as the redundant paths 220-1, 220-2 are using two different User Plane Functions (UPFs) 210-1, 210-2 in the 5G Core Network, CN, 235 (which is referred to for 5G as 5GC), and use two different gNBs 170-1, 170-2 in the RAN network 240, while the end device 110 (e.g., an industrial controller) is equipped with two UEs 80-1, 80-2, each of them terminating one of the paths 220-1, 200-2. Each UE is a traditional user equipment capable of operating according to a 3GPP standard (e.g., 5G NR) that will have an associated UE identifier identifying the UE in the 3GPP network (e.g., the RAN network 240 and the CN 235). It is also assumed herein the device 110 is aware of hosting two UEs and that means are used at the network to determine that two UEs are hosted in the same device, e.g. based on their UE IDs. The 3 GPP network 102 could use the knowledge of which flows are coupled, for instance. These means are known, as prior art mechanisms could be assumed.

[0053] Such architecture can be, e.g., leveraged by the IEEE Time Sensitive Networking (TSN) Frame Replication and Elimination for Reliability (FRER) function (see, e.g., IEEE P802.1CB), which can duplicate the data packets to be transferred between the two hosts in a TSN network where each data packet would be delivered to the same device by using different paths in the network. This is shown in FIG. 3.

[0054] In FIG. 3, there is a host (Host A) 110-1 (a version of multi-UE device 110) that has two UEs 80-1, 80-2 and an FRER function 320. There are also two switches 350-1, 350- 2, and a second host (Host B) 270-1 with a FRER function 340. The switches 350 and host B 270 could be part of a TSN network.

[0055] Each of the UEs 80, belonging to the same device 110-1, has its own radio connection with the RAN network 240 and its own PDU (Protocol Data Unit) session established with the 5G Core Network (5GC) 235-1. Although full path redundancy can be used, as mentioned above, comprising two gNBs 170-1, 170-2 and two UPFs 210-1, 210-2, the most probable point of failure can be assumed to be a UE 80. Architectures with multi-UE devices 110, where both UEs are connected to a single gNB/UPF can also be considered (see 3 GPP TR 23.725). [0056] Redundancy (hardware, information, and the like) is a must in industrial automation and other safety-critical applications. Usage of redundant transmission paths assumes that the payload data traverses the entirety of one or multiple redundant paths. For example, the FRER function 340 in Host B 270-1 always duplicates each data packet and delivers the copies to both switches 350-1 and 350-2 in FIG. 3. The duplication comes at a cost of large decrease in resource efficiency, since the duplicate packets are only required in case the original one does not reach the receiver, which in most of the cases will not happen (e.g., if the reliability of each of the paths is 99.99%, then only one out of 10,000 duplicated packets is really needed).

[0057] To address high reliability via redundancy, in 3GPP TR 23.725 VI 6.1.0 (2019-03), there is a “solution #2” for “Key Issue #1”. See, e.g., section 6.2. This involves multiple UEs per device for user plane redundancy. The solution will enable a terminal device to set up multiple redundant PDU sessions over the 5G network, so that the network will attempt to make the paths of the multiple redundant PDU sessions independent whenever that is possible.

[0058] This solution makes use of the integration of multiple UEs into the device and assumes a RAN deployment where redundant coverage by multiple gNBs is generally available. Multiple PDU sessions are set up from the UEs, which use independent RAN (e.g., gNB) and CN entities (e.g., UPF entities).

[0059] While this solution does not address the issue of resource efficiency (as addressed herein), and instead addresses the issue of high reliability requirement, this solution does present a structure into which the exemplary embodiments herein may be used.

[0060] The 5G QoS architecture is depicted in FIG. 4 (see, 3GPP TS 23.501, Rel. 15, Figure 5.7.1.5-1). FIG. 4 is a schematic of (QoS flow-based) QoS framework in 5G. This illustrates an application/service layer 410 that creates data packets 430 from applications and that inputs to both the UPF 440 and the UE 480. There are QoS rules 450 that perform mapping of UL packets to QoS flows and apply QoS flow markings. The QoS flows 460 are all packets marked with the same “QoS flow ID”. According to 3GPP 5G terminology, a QoS Flow is identified by its ID as described in the previous sentence. In addition, one or more Service Data Flows (SDFs) can be transported in the same QoS flow, if they share the same policy and charging rules. All traffic within the same QoS flow receives the same treatment since the QoS is enforced at the QoS flow level. A PDU session between a UE and the 5GC may contain multiple QoS flows (to which packets of different services with different QoS can be mapped) and several DRBs, but only a single N3 GTP-U tunnel. A DRB may transport one or more QoS flows.

[0061] The UE 480 and the AN (access network) 420 perform mapping 470 of QoS flows to AN resources 482 (illustrated in DRB 481-1). The UPF 440 uses SDF templates 490, which classify packets to SDFs, for QoS flow marking.

[0062] A 5G UE can have multiple E2E PDU sessions 495 running in parallel, each of them comprising at least one (e.g., E2E) QoS Flow and one DRB 481-1 or 481-2 in the radio interface. A PDU session can be active or inactive. In the former case, at least one DRB is associated and core network interfaces are established (e.g., N2 CP interface and N3 UP interface). On the contrary, upon releasing the last DRB, the corresponding PDU session becomes inactive. Initially, the UE 480 registers to the network with no PDU session activated, i.e., the UE with a signaling only connection, and subsequently selective activation of PDU sessions can take place based on need. For this, a PDU session activation procedure is required to activate an inactive PDU session, entailing some latency. For further details refer to Section 5.6.8 of 3 GPP TS 23.501.

[0063] A technique similar to redundant PDU sessions was also applied in a “hot standby” functionality used e.g., in GSM-R and Information Technology (IT). In particular, the GSM-R system, based on GSM mobile communications standards, is used for railway wireless communication (i.e. voice and data communications between the train and the control center), which has a very high reliability requirement. In that system, a full duplication of network and coverage is used in wide macro areas to meet the reliability demand. A “hot standby” functionality is used as a state of art geo-redundancy solution to automatically and rapidly switch over between a primary and a backup node upon failure of the primary node (operating at different geo-locations), see FIG. 5, which illustrates a fully duplicated network with overlaid radio cell coverage for a GSM-R system. In this figure, the following acronyms are used: RBC = radio block center; SDH = Synchronous Digital Hierarchy; MSC = mobile-services switching center; BSC = base station controller; BTS = base transceiver station; MS = mobile station; and EVC = European vital computer.

[0064] Hot standby is basically a redundant method in which one system runs simultaneously with an identical primary system. Upon failure of the primary system, the hot standby system immediately takes over, replacing the primary system. However, data is still mirrored in real time, thus, both systems have identical data, which leads to resource inefficiency. Hot standby is also known as hot spare, especially at the component level, such as a hard drive in a disk array. This expensive solution, of GSM-R mobile access solution upgrade for trains, is for instance deployed by the Danish train company Banedanmark, based on Nokia design, implementation and maintenance.

[0065] However, this hot-standby technique suffers from the same problem as UP redundancy as recently proposed for 5G systems, i.e., due to duplicating all the nodes and data transmissions, the resource efficiency is very low in such networks.

[0066] The exemplary embodiments herein aim at, e.g., solving the resource inefficiency problem, while ensuring a swift establishment of the redundant path. Additionally, certain exemplary embodiments herein are targeted at scenarios including multi-UE devices 110 and can be applied both in the case with single gNB/UPF or with different gNB/UPFs per UE as shown in FIGS. 6 A and 6B. FIG. 6 A is an illustration of a multi-UE device 110 with a connection to a single gNB 170 in a wireless network, in accordance with an exemplary embodiment. Each UE 80 connects to gNB 170. In this example, the UE1 80-1 draws from data source 1 610-1 and the UE2 80-2 draws from data source2610-2. Meanwhile, FIG. 6B is an illustration of a multi-UE device 110 with a connection to multiple gNBs 170-1 and 170-2 in a wireless network, in accordance with an exemplary embodiment. Each UE 80-1, 80-2 connects to a different one of the eNBs 170-1, 170-2.

[0067] Furthermore, exemplary embodiments herein can be also applied for a single UE device where the UE has redundant PDU sessions and/or QoS flows established. This is described in more detail below.

[0068] An exemplary embodiment proposes a method for enhancing resource efficiency of solutions based on redundant PDU sessions being established with the same device, while keeping the reliability and service continuity in case of hardware failure or equipment replacement. This is achieved in exemplary embodiments by introducing a new type of QoS flows, called buffered QoS flows, which are configured depending on the QoSs of the services and architecture constraints, e.g., in the redundant PDU session(s) of the device. Via a buffered QoS flow, duplicated data is delivered only up to a certain segment in the network where the data is buffered, i.e. it is not delivered to the end destination to save system resources on the remaining data segment (e.g., air interface, RAN to CN interface) as presented in FIG. 7 in one example.

[0069] FIG. 7 is a block diagram of an exemplary illustration with normal and buffered QoS flows in a multi-UE device case and in a wireless network 100-2, in an exemplary embodiment. The wireless network 100-2 in this example interfaces with a multi-UE device 110 having a device controller 140 and two UEs, UE1 80-1 and UE2 80-2, and comprises two gNBs 170-1 and 170-2, and two User Plane Functions (UPFs) 210-1, 210-2 (e.g., each implemented as illustrated by network element 190 of FIG. 1), and interfaces with a data network 230. The data network 230 may be a cellular network and/or Internet and/or a cloud of computers, and/or other networks, and comprises a communication endpoint 270 that terminations a communication with the device 110. There are two redundant paths 720-1 and 720-2 that are shown. There is a RAN network 240 and a core network, such as a 5GC, 235, and these are part of a 3GPP network 102.

[0070] As block 710 indicates, data of a normal QoS flow in the path 720-1 is sent normally to UE1 80-1. The path 720-1 contains a normal QoS flow 730. However, block 790 indicates that data of the buffered QoS flow is buffered at the gNB and not delivered to UE2 80- 2. That is, path 720-2 contains a buffered QoS flow 740. The dashed line for reference 745 indicates that the flow 740 is set up to pass from the gNB2 170-2 to the UE2 80-2 in response to a failure of delivery of the normal QoS flow 730. That is, the buffered QoS flow 740 effectively “ends” at the gNB2, but is buffered and ready for delivery via a DRB mapped to radio link 745, should delivery be necessitated.

[0071] At least one buffered QoS flow 740 should be associated with a normal QoS flow 730, e.g., the corresponding QoS flow of the associated PDU session used for traffic redundancy. In an exemplary targeted use case, the associated, normal QoS flow 730 would carry the same data packets as the buffered QoS flow 740. Upon failure of the associated QoS flows 730 (which can also be called primary QoS flows), packets of the buffered QoS flow 740 which were buffered in gNB2 170-2 are immediately sent to the UE (e.g., UE2 in FIG. 7, and via a DRB mapped to radio link 745) and the buffered QoS flow 740 is automatically turned into a normal QoS flow 730, i.e., subsequent packets of this QoS flow incoming to the gNB are not buffered, but delivered to the receiver (UE2 of the multi-UE device 110 in this example) in a normal way. An exemplary embodiment proposes also dedicated signaling and procedures (a) for the configuration of the buffered QoS flow(s), and (b) for the detection of a failure which triggers recovery actions leveraging a buffered QoS flow.

[0072] One of the main exemplary use cases is the multi-UE device 110, where multiple UEs 80 are collocated in the same physical device (e.g., as per 3GPP TR 23.725), and when the failure affects one of the UEs 80, as described in reference to FIG. 7. However, exemplary use cases can also apply to single-UE device scenarios where the failure happens in one of the network nodes or data links delivering normal QoS flow (e.g., UPF1 210-1 or gNBl 170-1, or a data link between gNBl 170-1 and UE1 80-1, and the like) can be recovered by certain exemplary embodiments as presented in FIG. 7. It should be noted that although two UEs 80 are illustrated for a multi-UE device 110, it is possible to have three or more UEs 80 in a multi-UE device 110.

[0073] However, exemplary embodiments can also be used in single-UE device 112 scenarios where the failure happening in one of the network nodes or data links delivering normal QoS flow (e.g., UPF1 or gNBl, or data link between gNBl and UE, and the like) can be recovered as presented in FIG. 7A. FIG. 7A is similar to FIG. 7, except that there is a single-UE device 112 having a single UE 80 that terminates both paths 720-1 and 720-2 in wireless network 100-3. In this example, block 710 and path 720-1 (with the normal QoS flow 730) flow through the gNBl 170-1 to the UE 80. Block 790 and path 720-2 (with the buffered QoS flow 740) flow through the gNB2 170-2 to the UE 80. As with FIG. 7, the flow 740 is communicated using a DRB mapped to radio link 745 and occurs in response to a failure of delivery of the normal QoS flow 730.

[0074] It is noted that exemplary embodiments herein have merits compared to ’’hot standby” (see the description above) since the exemplary embodiments do not require a complete network duplication and/or a complete reservation of network resources. Exemplary embodiments herein employ only a selective buffering that is different from the complete mirroring of the data through the entire redundant path required by the hot-standby, which complete mirroring is rather expensive, e.g., in terms of resources.

[0075] Exemplary operations for an exemplary method are illustrated through FIG. 8. FIG. 8 is a signaling flow diagram in a wireless network 100-4 showing embodiments for a multi-UE device example. This figure illustrates the operation of an exemplary method or methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiments.

[0076] FIG. 8 illustrates signaling between a device controller 140-1, possibly comprising an FRER function 320-1, two UEs (UE1 80-1 and UE2 80-2), two gNBs 170-1 and 170-2, two UPFs 210-1 and 210-2, and a DN 820 possibly comprising an FRER function 340-1 (e.g., as part of a communication endpoint 270-1 that is in the DN 820 and terminates the communication with the multi-UE device 110).

[0077] In step 1 of FIG. 8, the NW (e.g., 3GPP network 102-2) establishes both a normal (primary) QoS flow and a buffered QoS flow to serve the same traffic reliably. In one example, the element performing step 1 is the network element in charge of the control plane (CP) in the 5G core network 235-1 that establishes PDU sessions and QoS flows, e.g., the AMF. The E2E path of the redundant QoS flow may take into account, e.g., the risk of failure, the architectural constraints and associated cost. That is, there is a PDU session establishment comprising a primary QoS Howl 730 via UPFl/gNBl/UEl and comprising at least one buffered QoS flow2740, via UPF2/gNB2/UE2.

[0078] In FIG. 8, steps 2 and 3 are described as including indication of primary and buffered QoS flows and their pairing. Additional details about these steps are described now.

[0079] In step 2, the CN 235-1 indicates explicitly to the UEs 80 and any NW node (e.g., the gNBs 170) parts of the E2E path for which the established QoS flows are buffered QoS flows 740 and which are normal QoS flows 730.

[0080] For step 3, for each buffered QoS flow 740, the network 102-2 may indicate which of the normal QoS flows 730 is associated to this buffered QoS flow 740 (i.e., carries the same traffic as buffered QoS flow 740).

[0081] In step 4, the network 102-2 performs selecting a buffering entity (e.g., gNB2 170-2) based, e.g., on QoS targets (e.g., low latency) and/or high risk of radio failures of gNBl 170-1. That is, the network 102-2 may also choose which of the network nodes should be buffering packets related to the buffered QoS flow 740:

[0082] a. In downlink direction, those may include, e.g., UPF or gNB; and/or

[0083] b. In uplink direction, those could be the UE, gNB or UPF.

[0084] The choice of the buffering node may depend, e.g., on the delay requirements of the traffic. For traffic with stricter requirements in terms of latency, the buffering point should be closer to the end receiver. For less-strict latency requirements, the buffering point can be further from the end receiver. The choice will always be a trade-off between how quickly the buffered packets reach the end receiver in case of failure and the gains in terms of resource efficiency in the network 102-2 (e.g., the closer the buffering node is to the end receiver, the more network interface and nodes the data has to traverse, even in a case where the primary QoS flow is operational).

[0085] In step 4A, the buffering entity is informed it is to act as the buffering entity (e.g., for a QoS flow2) and configures itself accordingly. The indication could be provided by e.g. requesting the buffering entity to establish a special “buffered” QoS flow.

[0086] For step 5, the network 102-2 includes configuring a buffering time (e.g., with a default value equal (=) to the Packet Delay Budget, PDB) for the buffering entity to keep the packets before discarding - unless instructed differently. For instance, the discarding could be disabled under certain, e.g. temporary, conditions, rather than setting PDB to infinity and therefore disabling discarding at all times. As an example, perhaps the communication is known to require very high reliability and the conditions at the multi-UE device 110 are unknown or perhaps known to be intermittently poor. The discarding could be disabled for a time to ensure higher reliability (e.g., then enabled with a time commensurate with current conditions). For the buffering time, the network 102-2, while configuring the buffered QoS flow, may decide in an exemplary embodiment also for how long the packets related to this QoS flow should be buffered in the buffering node. The length of this time may be either indicated explicitly or can be equal to the PDB or a fraction of the PDB (e.g., corresponding to the PDB dedicated to the remaining part of the network 100-4 the packet still needs to traverse).

[0087] In step 6, which includes steps 6A, 6B, and 6C, there is downlink data transfer on the QoS flowl (step 6A) and downlink data transfer on buffered QoS flow2 to gNB2 170-2. (step 6B). By way of explanation, data flows via the primary QoS flow 730 between the server (e.g., DN 820) and the UE (e.g., US 1 80-1) (e.g., via the gNBl 170-1 and UPF1 210-1) in step 6A, whereas data is buffered at the selected buffering entity (e.g., the gNB2 170-2 or the UPF2 210-2) for the buffered QoS flow 740 in step 6C. In this example, the gNB2 170-2 buffers (see step 6C) the data without transferring the data to UE2 80-2 according to, e.g., the buffering time.

[0088] In step 7, when a failure and the corresponding failure detection happen on a primary QoS flow 1 730 (e.g., a UE1 80-1 failure is detected), the transmission of traffic, buffered in a buffering node and related to the associated buffered QoS flow 740, is triggered by the detecting node (e.g., in this case, the device controller 140-1), and the buffering node starts to be automatically sent to the end receiver direction. In this example, the buffering node is the gNB2 170-2. Also, further traffic incoming to the buffering node is not buffered any more, but is delivered in a normal way. One could say that the buffered QoS flow 740 automatically becomes normal QoS flow 730 in case its associated QoS flow (primary QoS flow 730) fails. The example in FIG. 8 has the device controller 140-1 detecting a failure of QoS flowl 730 because of a failure of the UE1 80-1 being detected.

[0089] In step 8, this is split into steps 8A, 8B, 8C, 8D, and 8E. There may be several ways for the buffering node to detect the failure of the primary QoS flow 730 and to start transmission of the packets of the buffered QoS flow 740 (where the transmission concerns the buffered data and new data). The triggers may depend on the direction of the QoS flow (uplink or downlink or both) and which of the network nodes was chosen as the buffering node. In the non-limiting examples below, the gNB2 170-2 and UEs/device employ failure detection, as described below.

[0090] Activation triggers (e.g., for DL or UL) of buffered QoS flows in the UE can include one or more of the following:

[0091] i. measured signal level and/or quality at the link associated to the primary QoS flow 730 (e.g., in the multi-UE scenario this can be the link of UE1) dropping below a threshold configured by the network 102;

[0092] ii. measurement report(s) (e.g., related to potential Handover, HO) triggered in the UE (in multi-UE device scenario, this can also be a measurement report of the other UE of the device);

[0093] iii. PHY layer issues, beam failure, Radio Link Failure (RLF) or the like on the link serving the primary QoS flow;

[0094] iv. reception of data belonging to the buffered QoS flow in DL; or

[0095] v. a specific indication/signal emitted when a hardware component (e.g., affecting the primary QoS flow) is going to be (e.g., temporarily) unavailable, e.g. due to hardware failure or due to being removed and/or replaced (e.g., swapped) for maintenance or upgrade purposes (e.g., a board implementing a software-defined module of a UE 80-1), where the indication/signal could be sent to the device 110/112, the UE 80-2 (assuming the UE 80-1 is having a hardware component replaced), or the second gNB 170-2 as examples.

[0096] Concerning the measurement reports such as for a HO, when a measurement report used at the network 102 for deciding to hand over the UE to a different cell is triggered to be sent by the UE to the gNB, the corresponding path will be temporarily interrupted during the handover procedure. Therefore, it is beneficial to activate the second path to avoid any interruption. So here it is meant that when the report is triggered, that will in turn trigger the activation of the second path, by sending the activation indication either to the device or the other UE (or even to the buffering gNB).

[0097] Activation triggers (e.g., in UL and DL) of buffered QoS flows in a gNB 170 (or a different network node such as a UPF 210) can include one or more of the following nonlimiting examples:

[0098] i. indication of failure received from another network node, e.g.: (1) from one gNB to another gNB over an Xn interface from gNB-Cu to gNB-DU on an FI interface, where the first gNB may detect the failure because of, e.g., an usual number of missing transmissions and/or acknowledgment from the UE; or (2) indication of failure from UPF 210 to gNB 170 on an N3 interface, where the indication from the UPF to the gNB can be for example triggered by a measurement report received from a UE transmitting/receiving on the primary QoS flow;

[0099] ii. indication and/or reconfiguration received from the CN 235-1 (e.g., extra reliability required for traffic associated with buffered QoS flows), where the indication/reconfiguration affects the QoS flow operation according to tighter (e.g., higher) QoS requirements;

[00100] iii. reception of data belonging to buffered data flow in UL/DL;

[00101] iv. direct indication from the UE 80 requesting to activate the buffered QoS flow (e.g., sent based on an indication from a device controller 140-1);

[00102] v. a specific indication/signal emitted when a hardware component (e.g., affecting the first data flow) is going to be (e.g., temporarily) unavailable, e.g. due to hardware failure or due to being removed and replaced (swapped) for maintenance or upgrade purposes (e.g., a blade in a server rack implementing a gNB/CU), such that, e.g., the gNBl carrying the primary QoS flow if affected by HW upgrades, will indicate the temporary unavailability to the other gNB or UPF or UE to activate the second path.

[00103] In the example of FIG. 8, in step 8A, the UE2 80-2 sends a buffered QoS Flowl activation request to its corresponding gNB2 170-2. Note that this activation request can be sent by gNBl (see step 8D) or UE. In step 8B, the gNBl 170-1 (e.g., independently) determines there is a primary QoS flowl 730 failure, e.g., via a UE1 failure being detected. In step 8D, the gNBl 170-1 sends an optional (opt.) buffered QoS flowl activation request toward the eNG2 170-2. Step 8C indicates that the gNB 170-2 responds to one or both of the request in step 8A or 8D to cause the buffered Qos flow2740 to be activated and this flow becomes the primary flow 730. The delivery of buffered data to UE2 is triggered by the gNB2 170-2. In step 8E, the gNBl 170-1 sends a QoS flowl deactivation message toward the DN 820. It is noted that the gNB will not communicate directly with the DN 820. Instead, the message should be sent to either a UPF 210 (e.g., UP F 210-1) or other 5GC network node.

[00104] In step 9, the gNB2 170-2 transfers buffered data to the UE2 80-2 via the QoS flow2 (now the primary flow 730), and the UE2 transfers the data to the device controller 140-1. The DN 820 in step 10 performs a downlink data transfer on QoS flow2, the primary flow 730, and the UE2 communicates the data to the device controller 140.

[00105] It is noted that the communication in FIG. 8 is between two communication entities: the multi-UE device 140 (and its UEs 80-1, 80-2) and the communication endpoint 270 in the data network 820. The communication could be between other entities, say to support device-to-device (D2D) communications, such that the entities are D2D devices. As is known, D2D communication in cellular networks is defined as direct communication between two mobile users without traversing the RAN node 170 or core network.

[00106] FIG. 9 illustrates an exemplary implementation in a multi-UE device scenario. This is similar to FIG. 8, but illustrated from a network view. Reference 980 illustrates a scenario before UE failure, and reference 990 illustrates a scenario after UE failure. At first, before UE failure in reference 980, the primary QoS flow 730 is operational and the packets of the associated buffered QoS flow 740 are buffered at gNB2 170-2. This is illustrated by reference 910, where timer-based DL buffering is performed for the buffered flow. The radio link 745 is configured to be used (e.g., using a mapped DRB) in response to a need for buffered QoS flow 740, but the dashed line indicates no flow occurs before UE failure. [00107] Once UE1 80-1 detects (see after UE failure for reference 990) failure 920-2 of the link serving the primary QoS flow 730, the UE informs the device controller 140 (e.g., see reference 985). The device controller 140 sends (see also reference 985) a notification to the UE2 80-2, which in turn sends the notification further to the gNB2 170-2 (e.g. using an RRC message or MAC CE). That is, the device controller 140 performs (see block 940) UE1 failure detection (indicated by reference 920-1) and performs activation of the buffered flow. Reference 930 indicates the DL data buffered at gNB2 is sent over the activated flow, as also indicated by 740- >730.

[00108] If buffering would have taken place at UPF2210-2, the gNB2 would have sent the notification further to the CN, e.g. directly to UPF2210-2 using, e.g., N3. Other alternatives for the latter case (buffering at UPF2), not visible in the figure, are also possible, such as the following:

[00109] 1) The gNB may send a notification to an Access Management Function

(AMF) using N2 interface signaling, and the AMF forwards the notification to UPF2; or

[00110] 2) The UE2 80-2 may send the notification directly to AMF using NAS signaling, and the AMF then forwards the notification to UPF2210-2.

[00111] Further implementation options, based on different buffering points, are presented below. In these examples, each of the established PDU sessions has one a primary QoS flow 730 and at least one buffered QoS flow 740 associated to each other (i.e., paired flows). However, for simplicity, only one buffered QoS flow 740 is shown, though there could be multiple buffered QoS flows 740.

[00112] For a DL case where the buffering point is in UPFs, this is illustrated by FIG. 10, which illustrates a wireless network 100-5 with a 3 GPP NW 102-3. That is, one exemplary implementation with user plane redundancy with a multi-UE device 110 and buffering point for a DL buffered QoS flow in the UPF2 is presented in FIG. 10.

[00113] Steps 1-2: The QoS controller 1010 (e.g., some network node in the 3GPP NW 102-3 having control plane functions with respect to QoS, such as PCF or SMF) indicates (via link 1) to the UPF1 210-1 that some of data flows (e.g., 1030-2) (to be) established for UPF1 are buffered QoS flows and should be buffered in UPF1 and indicates (via link 2) to UPF2210-2 that some of data flows (e.g., 1030-1) (to be) established for UPF2 are buffered QoS flows and should be buffered in UPF2. Based on this, the UPF1 would pass through QoS flow 1030-1 as a primary QoS flow 1030-1, but would treat QoS flow 1030-2 as buffered QoS flow 1040-2. The UPF2 would pass through QoS flow 1030-2 as a primary QoS flow 1030-2, but would treat QoS flow 1030-1 as buffered QoS flow 1040-1. The corresponding UPF buffers but does not send the buffered QoS flow.

[00114] Steps 3-4: The QoS controller 1010 indicates (via link 3) to the gNBl that some of data flows (to be) established in gNBl are buffered QoS flows 1040-2 and are/will be buffered in UPF1 and indicates (via link 4) to gNB2 that some of data flows 1040-1 (to be) established in gNB2 are buffered QoS flows 1040-1 and are/will be buffered in UPF2.

[00115] Steps 5-6: Similar indication is sent to UEs via links 5 and 6.

[00116] Another possibility is to have gNB(s) perform the buffering. This is illustrated by FIG. 11 , which illustrates an exemplary implementation of a differently-configured wireless network 100-6 in case of DL buffering at the gNB.

[00117] Steps 1-2: The QoS controller 1010 indicates (via link 1) to UPF1 that some of data flows 1030-2 (to be) established for UPF1 are buffered QoS flows and will be buffered in gNBl and indicates (via link 2) to UPF2 that some of data flows 1030-1 (to be) established for UPF2 are buffered QoS flows and will be buffered in gNB2. In this case, both UPF1 and UPF2 pass both flows 1030-1 and 1030-2 toward their respective gNBs 210-1, 210-2.

[00118] Steps 3-4: The QoS controller 1010 indicates (via link 3) to gNBl that some of data flows 1030-2 (to be) established in gNBl are buffered QoS flows and should be buffered in gNBl and to gNB2 (via link 4) that some of data flows 1030-2 (to be) established in gNB2 are buffered QoS flows and should be buffered in gNB2. What this means is that the gNBl 170-1 passes the primary QoS flow 1030-1 and buffers the flow 1030-2 (to create a buffered flow 1040-2). Meanwhile, the gNB2 170-2 passes the primary QoS flow 1030-2 and buffers the flow 1030-1 (to create a buffered flow 1040-1). For clarity, flows 1040-1 and 1040-2 are only used in response to a failure of delivery of the corresponding primary QoS flow 1030-1 or 1030-2, respectively.

[00119] Steps 5-6: Similar indication is sent to UEs 80-1 and 80-1 via links 5 and 6, respectively.

[00120] FIG. 12 illustrates an exemplary implementation in case of UL buffering at the UE in another differently-configured version of wireless network 100-5. This is an UL case, with the buffering point in UEs. [00121] Steps 1-2: The QoS controller 1010 indicates (via link 1) to UE1 that some of data flows (e.g., 1230-2) (to be) established for UE1 are buffered QoS flows and should be buffered in UE1 and indicates (via link 2) to UE2 that some of data flows (e.g., 1230-1) (to be) established for UE2 are buffered QoS flows and should be buffered in UE2. This means UE1 will pass QoS flow 1230-1 as a primary flow but will buffer QoS flow 1230-2 to create buffered flow 1240-2. Similarly, UE2 will pass QoS flow 1230-2 as a primary flow but will buffer QoS flow 1230-1 to create buffered flow 1240-1. The buffered flows 1240 are not transmitted unless failures in the corresponding primary flows 1230 are reported.

[00122] Steps 3-4: The QoS controller 1010 indicates (via link 3) to gNBl that some of data flows 1240-2 (to be) established in gNBl are buffered QoS flows and will be/are buffered in UE1 and indicates (via link 4) to gNB2 that some of data flows 1240-1 (to be) established in gNB2 are buffered QoS flows and will be/are buffered in gNB2.

[00123] Steps 5-6: Similar indication is sent to the UPFs 210-1, 210-2 via the respective links 5 and 6.

[00124] The following are additional examples.

[00125] Example 1. A method, comprising:

[00126] in a node in a wireless network, where a first data flow is transferred via a first path between two endpoints, buffering a second data flow, wherein at least one of endpoints is in the wireless network, wherein the first and second data flows comprise a same data, and wherein the node is in a second path between the two endpoints; and

[00127] in response to receiving indication the second data flow should be activated, sending at least some of the buffered second data flow through the second path.

[00128] Example 2. The method of example 1, wherein the received indication is based on a failing of the first data flow.

[00129] Example 3. The method of examples 1 or 2, wherein a first one of the two endpoints comprises a multi-user equipment device within the wireless network, the first data flow terminates at a first user equipment in the multi-user equipment device, and the second data flow terminates at a second user equipment in the multi-user equipment device.

[00130] Example 4. The method of examples 1 or 2, wherein a first one of the two endpoints comprises a single-user equipment device within the wireless network, and the first and second data flows terminate at a user equipment in the single-user equipment device. [00131] Example 5. The method of any of examples 1 to 4, wherein one of the two endpoints is a receiving device within the wireless network, and the node comprises one of the following: a radio access node; a gNB; a node comprising a user plane function; or a base station;

[00132] Example 6. The method of example 5, wherein the other of the two endpoints is in a data network outside the wireless network and the other endpoint, and wherein the first and second data flows are sent in a downlink direction from the data network toward the receiving device.

[00133] Example 7. The method of any of examples 1 to 4, wherein one of the two endpoints is a receiving device within the wireless network, and the node comprises one of the following: a user equipment; a radio access node; a gNB; a node comprising a user plane function; or a base station.

[00134] Example 8. The method of example 7, wherein the other of the two endpoints is in a data network outside the wireless network, and wherein the first and second data flows are sent in an uplink direction from a single-user equipment or multi-user equipment device toward the data network.

[00135] Example 9. The method of any of examples 1 to 5 or 7, wherein both of the two endpoints are within the wireless network.

[00136] Example 10. The method of any of examples 1 to 9, wherein the indication the second data flow should be activated include one or more of the following:

[00137] measured signal level and/or quality at a link associated to the first data flow drops below a corresponding threshold that has been configured by the network;

[00138] one or more measurement report(s) triggered in the user equipment;

[00139] one or more of physical layer issues, beam failure, or radio link failure on the link serving the first data flow;

[00140] reception of data belonging to the second data flow in downlink; or

[00141] a specific indication and/or signal emitted when a hardware component in one of the endpoints affecting the first data flow is going to be unavailable.

[00142] Example 11. The method of any of examples 1 to 4, wherein one of the two endpoints comprises at least a user equipment receiving the first data flow, and activation triggers to be used by the node to send the second data flow include one or more of the following:

[00143] indication received from another network node of failure of the first data flow;

[00144] indication and/or reconfiguration received from a core network in the wireless network, where the indication/reconfiguration affects the data flow operation for at least the first data flow according to tighter quality of service requirements;

[00145] reception of data belonging to the second data flow in uplink or downlink;

[00146] a direct indication from a user equipment in the receiving device requesting to activate the second flow; or

[00147] a specific indication and/or signal emitted when a hardware component, in the node or other nodes in the first path and affecting the first data flow, is going to be unavailable.

[00148] Example 12. The method of example 11 , wherein the node is a first node and wherein the indication received from another network node of failure of the first data flow comprises one or more of the following:

[00149] an indication of failure from a second node to the first node over at least one interface, where the second node detects the failure; or

[00150] an indication of failure from a user plane function to the first node on at least one interface.

[00151] Example 13. The method of any of examples 1 to 12, further comprising discarding packets from the second data flow in response to the packets being buffered for longer than a buffering time.

[00152] Example 14. The method of any of examples 1 to 13, where the data flows are quality of service data flows and are distinguishable at least by corresponding identifications in each flow.

[00153] Example 15. A method, comprising:

[00154] in a node in a wireless network, setting up first and second data flows between two endpoints, wherein at least one of endpoints is in the wireless network, wherein the first data flow is communicated via a first path through the wireless network between the two endpoints, the second data flow is sent via a second path through the wireless network between the two endpoints;

[00155] selecting a node in the second path to buffer the second data flow; and [00156] indicating to the node that the node is to buffer the second data flow and to send data through the second data flow in response to receiving indication the second data flow should be activated.

[00157] Example 16. The method of example 15, wherein the received indication is based on a failing of the first data flow.

[00158] Example 17. A computer program, comprising code for performing the methods of any of examples 1 to 16, when the computer program is run on a computer.

[00159] Example 18. The computer program according to example 17, wherein the computer program is a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with the computer.

[00160] Example 19. The computer program according to example 17, wherein the computer program is directly loadable into an internal memory of the computer.

[00161] Example 20. An apparatus comprising means for performing:

[00162] in a node in a wireless network, where a first data flow is transferred via a first path between two endpoints, buffering a second data flow, wherein at least one of endpoints is in the wireless network, wherein the first and second data flows comprise a same data, and wherein the node is in a second path between the two endpoints; and

[00163] in response to receiving indication the second data flow should be activated, sending at least some of the buffered second data flow through the second path.

[00164] Example 21. The apparatus of example 20, wherein the received indication is based on a failing of the first data flow.

[00165] Example 22. The apparatus of examples 20 or 21, wherein a first one of the two endpoints comprises a multi-user equipment device within the wireless network, the first data flow terminates at a first user equipment in the multi-user equipment device, and the second data flow terminates at a second user equipment in the multi-user equipment device.

[00166] Example 23. The apparatus of examples 20 or 21, wherein a first one of the two endpoints comprises a single-user equipment device within the wireless network, and the first and second data flows terminate at a user equipment in the single-user equipment device.

[00167] Example 24. The apparatus of any of examples 20 to 23, wherein one of the two endpoints is a receiving device within the wireless network, and the node comprises one of the following: a radio access node; a gNB; a node comprising a user plane function; or a base station;

[00168] Example 25. The apparatus of example 24, wherein the other of the two endpoints is in a data network outside the wireless network and the other endpoint, and wherein the first and second data flows are sent in a downlink direction from the data network toward the receiving device.

[00169] Example 26. The apparatus of any of examples 20 to 23, wherein one of the two endpoints is a receiving device within the wireless network, and the node comprises one of the following: a user equipment; a radio access node; a gNB; a node comprising a user plane function; or a base station.

[00170] Example 27. The apparatus of example 26, wherein the other of the two endpoints is in a data network outside the wireless network, and wherein the first and second data flows are sent in an uplink direction from a single-user equipment or multi-user equipment device toward the data network.

[00171] Example 28. The apparatus of any of examples 20 to 24, or 26, wherein both of the two endpoints are within the wireless network.

[00172] Example 29. The apparatus of any of examples 20 to 28, wherein the indication the second data flow should be activated include one or more of the following:

[00173] measured signal level and/or quality at a link associated to the first data flow drops below a corresponding threshold that has been configured by the network;

[00174] one or more measurement report(s) triggered in the user equipment;

[00175] one or more of physical layer issues, beam failure, or radio link failure on the link serving the first data flow;

[00176] reception of data belonging to the second data flow in downlink; or

[00177] a specific indication and/or signal emitted when a hardware component in one of the endpoints affecting the first data flow is going to be unavailable.

[00178] Example 30. The apparatus of any of examples 20 to 23, wherein one of the two endpoints comprises at least a user equipment receiving the first data flow, and activation triggers to be used by the node to send the second data flow include one or more of the following:

[00179] indication received from another network node of failure of the first data flow; [00180] indication and/or reconfiguration received from a core network in the wireless network, where the indication/reconfiguration affects the data flow operation for at least the first data flow according to tighter quality of service requirements;

[00181] reception of data belonging to the second data flow in uplink or downlink;

[00182] a direct indication from a user equipment in the receiving device requesting to activate the second flow; or

[00183] a specific indication and/or signal emitted when a hardware component, in the node or other nodes in the first path and affecting the first data flow, is going to be unavailable.

[00184] Example 31. The apparatus of example 30, wherein the node is a first node and wherein the indication received from another network node of failure of the first data flow comprises one or more of the following:

[00185] an indication of failure from a second node to the first node over at least one interface, where the second node detects the failure; or

[00186] an indication of failure from a user plane function to the first node on at least one interface.

[00187] Example 32. The apparatus of any of examples 20 to 31, wherein the means are further configured to perform discarding packets from the second data flow in response to the packets being buffered for longer than a buffering time.

[00188] Example 33. The apparatus of any of examples 20 to 32, where the data flows are quality of service data flows and are distinguishable at least by corresponding identifications in each flow.

[00189] Example 34. An apparatus comprising means for performing:

[00190] in a node in a wireless network, setting up first and second data flows between two endpoints, wherein at least one of endpoints is in the wireless network, wherein the first data flow is communicated via a first path through the wireless network between the two endpoints, the second data flow is sent via a second path through the wireless network between the two endpoints;

[00191] selecting a node in the second path to buffer the second data flow; and

[00192] indicating to the node that the node is to buffer the second data flow and to send data through the second data flow in response to receiving indication the second data flow should be activated. [00193] Example 35. The apparatus of example 34, wherein the received indication is based on a failing of the first data flow.

[00194] Example 36. An apparatus, comprising:

[00195] one or more processors; and

[00196] one or more memories including computer program code,

[00197] wherein the one or more memories and the computer program code are configured, with the one or more processors, to cause the apparatus to perform operations comprising:

[00198] in a node in a wireless network, where a first data flow is transferred via a first path between two endpoints, buffering a second data flow, wherein at least one of endpoints is in the wireless network, wherein the first and second data flows comprise a same data, and wherein the node is in a second path between the two endpoints; and

[00199] in response to receiving indication the second data flow should be activated, sending at least some of the buffered second data flow through the second path.

[00200] Example 37. The apparatus of example 36, wherein the one or more memories and the computer program code are configured, with the one or more processors, to cause the apparatus to perform the method of any of examples 2 to 14.

[00201] Example 38. An apparatus, comprising:

[00202] one or more processors; and

[00203] one or more memories including computer program code,

[00204] wherein the one or more memories and the computer program code are configured, with the one or more processors, to cause the apparatus to perform operations comprising:

[00205] in a node in a wireless network, setting up first and second data flows between two endpoints, wherein at least one of endpoints is in the wireless network, wherein the first data flow is communicated via a first path through the wireless network between the two endpoints, the second data flow is sent via a second path through the wireless network between the two endpoints;

[00206] selecting a node in the second path to buffer the second data flow; and [00207] indicating to the node that the node is to buffer the second data flow and to send data through the second data flow in response to receiving indication the second data flow should be activated.

[00208] Example 39. The apparatus of example 38, wherein the received indication is based on a failing of the first data flow.

[00209] As used in this application, the term “circuitry” may refer to one or more or all of the following:

[00210] (a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

[00211] (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

[00212] (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.”

[00213] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

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

[00215] If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above-described functions may be optional or may be combined.

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

[00217] It is also noted herein that while the above describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention.

[00218] The following abbreviations that may be found in the specification and/or the drawing figures are defined as follows:

[00219] 3 GPP third generation partnership project

[00220] 5G fifth generation [00221] 5GC 5G core network [00222] AMF access and mobility management function [00223] AN access network [00224] CE control element [00225] CN core network [00226] CP control plane [00227] CU central unit [00228] D2D device-to-device [00229] DL downlink (from network toward user equipment) [00230] DN data network [00231] DRB data radio bearer

[00232] DU distributed unit

[00233] E2E end-to-end

[00234] eNB (or eNodeB) evolved Node B (e.g., an LTE base station)

[00235] EN-DC E-UTRA-NR dual connectivity

[00236] en-gNB or En-gNB node providing NR user plane and control plane protocol terminations towards the UE, and acting as secondary node in EN-DC

[00237] E-UTRA evolved universal terrestrial radio access, i.e., the

LTE radio access technology

[00238] FRER frame replication and elimination for reliability [00239] gNB (or gNodeB) base station for 5G/NR, i.e., a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC

[00240] GSM global system for mobile communications [00241] GSM-R GSM railway [00242] HO handover [00243] HW hardware [00244] ID identification [00245] I/F interface [00246] IIoT Industrial Internet of Things [00247] incl. including or includes

[00248] LTE long term evolution [00249] MAC medium access control [00250] MME mobility management entity [00251] ng orNG next generation [00252] ng-eNB or NG-eNB next generation eNB [00253] NR new radio [00254] N/W orNW network [00255] opt. optional [00256] PCF policy control function [00257] PDCP packet data convergence protocol [00258] PDB packet delay budget [00259] PDU protocol data unit [00260] PHY physical layer [00261] RAN radio access network [00262] QoS quality of service [00263] Rel release [00264] RLC radio link control [00265] RLF radio link failure [00266] RRH remote radio head [00267] RRC radio resource control [00268] RU radio unit [00269] Rx receiver [00270] SDAP service data adaptation protocol [00271] SDF service data flow [00272] SGW serving gateway [00273] SMF session management function [00274] TS technical specification [00275] TSN time sensitive networking [00276] Tx transmitter [00277] UE user equipment (e.g., a wireless, typically mobile device)

[00278] UPF user plane function [00279] UL uplink (from a user equipment toward the network) [00280] UP user plane [00281] URLLC ultra-reliable low latency communications [00282] WG working group