EP4710608A1

EP4710608A1 - Buffer status reporting in a communication system supporting sidelink relaying

Info

Publication number: EP4710608A1
Application number: EP24723758.9A
Authority: EP
Inventors: Walaa Sahyoun; Tristan Halna Du Fretay; Romain Guignard; Pascal Lagrange
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2023-05-09
Filing date: 2024-04-30
Publication date: 2026-03-18
Also published as: WO2024231180A1; CN121080028A; KR20260004484A

Abstract

Methods for managing buffer status reporting for data to be transmitted by a user equipment, UE, to a base station of a communication system supporting sidelink relaying are disclosed. In one aspect, a method at the UE comprises determining data to be transmitted is to be split for transmission to the base station over at least two separate paths; sending, to the base station, at least one buffer status report including information for indicating a volume of PDCP data of the data to be transmitted to the base station, wherein the PDCP data is to be transmitted over at least one path of the at least two separate paths. A method for managing resource allocation for data to be transmitted by a user equipment, UE, to a base station of a communication system supporting sidelink relaying where the UE can communicate with the base station over at least two separate paths is also disclosed.

Description

BUFFER STATUS REPORTING IN A COMMUNICATION SYSTEM SUPPORTING SIDELINK RELAYING

Field of the Invention

The present invention generally relates to a buffer status reporting (BSR) in a communication system supporting sidelink (SL) relaying (e.g., multipath relaying transmission). In particular, the present invention relates to methods for managing buffer status reporting for data to be transmitted by a user equipment, UE, to a base station of a communication system supporting sidelink relaying and a method for managing resource allocation for data to be transmitted by a user equipment, UE, to a base station of a communication system supporting sidelink relaying.

Background

The 3rd Generation Partnership Project (3GPP) has initiated the development of new radio access technology known as fifth-generation New Radio (5G NR) to respond to requirements related to very high reliability and very low latency. The 5G NR is not referred only to the enhancement of radio access technology but also to address a wide range of new services to be enabled by future mobile communication. Three distinctive categories of use cases are defined in NR from enhanced mobile broadband (eMBB), massive machine typing communication (mMTC) to Ultra-Reliable and Low Latency communication (URLLC).

A first version of Sidelink for 5G, or New Radio (NR) Sidelink, has been developed in 3GPP Release 16 as part of the 5G V2X Work Item, to support advanced vehicle-to-anything (V2X) scenarios and commercial applications and services in addition to complement former basic safety services. NR V2X addresses advanced driving use cases where vehicles are exchanging large amount of data while respecting a low latency requirement. NR Sidelink is designed to provide three basic transmission scenarios: broadcast, groupcast and unicast communications, while considering both out-of-coverage and in-network coverage deployment scenarios.

Based on the NR sidelink technology, 3 GPP introduced the sidelink-based relaying functionality as part of the 3GPP Release 17 framework, where a relay UE may provide User Plane (UP) and Control Plane (CP) data relaying between a set of served remote UEs and the network (UE-to-network, or U2N, relay) or between a source remote UE, or source UE, and a target remote UE, or target UE (UE-to-UE, or U2U relay). The purpose of the Release 17 sidelink relaying functionality was to both extend sidelink / network coverage and improve power efficiency, while considering a wider range of applications and services, including V2X, Public Safety and commercial applications and services. Some of these new V2X scenarios require ultra-reliability and low latency (URLLC) performance, in order to meet high-speed and high-density constraints, while requiring some network coverage extension, which may be achieved through sidelink relaying.

This first version of the sidelink relaying functionality, as defined in the Release 17 specification, mainly aimed at supporting the UE-to-network (U2N) relay with basic functionalities and limited features. For better support of the use cases requiring sidelink relay, further enhancements are necessary in order to introduce the potential solutions identified during the Rel-17 study item. The follow-up 3GPP Release 18 work item “NR Sidelink Relay (SLR) Enhancements” has addressed several solutions considered as enhancement areas needed in NR Sidelink Relay system for the V2X, public safety and commercial use cases.

The multipath relay has been specified as a solution in the Release 18 NR SLR Enhancements WI, where a remote UE is connected to the network via a direct path (e.g. the path is the link between the UE and a base station (also referred to as a gNB) of the network which link is referred to as a Uu link) and an indirect path (e.g. a path which includes a relay UE between the remote UE and the base station (also referred to as a gNB) of the network, where the link between the remote UE and the relay UE is referred to as a PC5 link and thus the path includes a PC5 link and a Uu link), with a potential to improve the reliability, the robustness and the throughput.

This multipath relay solution aims to provide applications requiring high Uplink data rates on 5G terminals, to achieve the required UL data rate, especially at the edge of a cell. Furthermore, the multipath relaying can improve the reliability and the stability of the provided services while reducing the latency if one of the paths is suffering from deteriorating channel conditions.

Remote UE configured for multipath relaying can transmit the data via multiple paths. The transmitted data is associated to a radio bearer configured by the network. In order to improve the reliability and/or the throughput, the data can be transmitted via multiple paths and thus, one radio bearer can be mapped to multiple configured paths. This radio bearer has been considered in RAN2 meetings for Release 18 multipath relaying scenarios and has been named “MP split bearer” or “MP bearer”. A MP bearer can be a Signaling Radio Bearer (SRB) for control data or a Data Radio Bearer (DRB) for user data. Since the data can be transmitted via multiple paths with a MP bearer, the transmitted data volume can be balanced on the multiple paths in order to achieve higher reliability and/or throughput as functions of the channel occupancy or radio conditions on the different paths. For this purpose, the data split can be used and the data packets can be delivered through the direct path or the indirect path of the multipath relaying system.

The data transmission in multipath relaying is performed in downlink and in uplink. For the downlink (DL), the gNB knows the data volume and can allocate resources accordingly. However, in uplink (UL), only the remote UE knows the data volume for UL transmission and should request grant from the gNB using a Buffer Status Report (BSR). The gNB receiving the BSR may allocate resources accordingly.

In case of available UL data, the remote UE may trigger a BSR to request uplink transmission resources over the direct path. This information is provided to the scheduler of the gNB as part of the uplink transmission through a MAC Control Element (MAC-CE). The BSR may include at least a Logical Channel Group (LCG) and an associated buffer size information field indicating the total amount of RLC data volume and PDCP data volume across all logical channels of this LCG.

According to the 3GPP TS 38.321, there are two types of BSR that can be used to request uplink grant from the network. The BSR in clause 5.4.5 of 3GPP TS 38.321 reports the buffer size information for radio bearers on the direct path including the total amount of Uu RLC data volume and the PDCP data volume of a logical channel group. The SL-BSR in clause 5.22.1.6 reports the buffer size information for the indirect path including the total amount of PC5 RLC data volume and the PDCP data volume of a logical channel group of a destination.

For MP bearer in a multipath relaying transmission, the remote UE can transmit uplink data over the direct path and the indirect path simultaneously for a data split use case. A MP bearer as proposed in 3GPP document R2 -2208349 and agreed in RAN2 119 meeting may have one PDCP entity and two RLC entities corresponding to the Uu RLC entity and the PC5 RLC entity. In a data split case, and according to the multipath relaying protocol stack, the remote UE may trigger a BSR and a SL-BSR, and the same PDCP data volume associated with the split RB may be reported in the buffer size information field of BSR and also in the buffer size field of the SL-BSR. However, all the PDCP data PDUs may not be transmitted twice on the two paths, and thus, the requested or allocated resources may exceed the exact need of the remote UE for a data split.

Furthermore, and for data split in UL, the remote UE should be able to distribute the load among paths to achieve higher reliability and/or throughput. However, the remote UE normally has no knowledge of the load of each path and the radio conditions of each path, and therefore, there is a risk of unbalanced load distribution among paths in UL.

Therefore, some new mechanisms are required to improve the buffer status reporting (BSR) in a communication system supporting sidelink relay or multipath relaying which take account of the aforementioned issues.

Summary

In accordance with a first aspect of the present invention, there is provided a method for managing buffer status reporting as recited in claims 1 to 24 of the accompanying claims.

In accordance with a second aspect of the present invention, there is provided a method for managing buffer status reporting as recited in claims 25 to 35 of the accompanying claims.

In accordance with a third aspect of the present invention, there is provided a method for managing resource allocation for data to be transmitted by a user equipment, UE, to a base station of a communication system supporting sidelink relaying where the UE can communicate with the base station over at least two separate paths, as recited in claims 36 to 47 of the accompanying claims.

In accordance with a fourth aspect of the present invention, there is provided an apparatus for a UE as recited in claim 48 of the accompanying claims.

In accordance with a fifth aspect of the present invention, there is provided an apparatus for a base station as recited in claim 49 of the accompanying claims.

Further example features of the invention are described in other independent and dependent claims.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus/device/unit aspects, and vice versa.

Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other aspects of the invention, there are provided a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any aspect or example described above and a computer readable storage medium carrying the computer program. Brief Description of the Drawings

Different aspects of the invention will now be described, by way of example only, and with reference to the following drawings in which:

Figure l is a schematic diagram illustrating an example wireless communication system in which the present invention may be implemented according to one or more embodiments;

Figure 2 is a schematic diagram depicting the user plane Sidelink (SL) relay architecture for UE-to-network with the adaptation layer in accordance with 3 GPP TR 38.836;

Figure 3 is a schematic diagram depicting the user plane multipath relay architecture for a multipath MP bearer in accordance with agreements made during 3 GPP Release 18 discussions;

Figure 4 is a schematic diagram illustrating an example format of a multipath BSR in accordance with one or more embodiments of the invention;

Figure 5-7 are schematic diagrams illustrating example formats of buffer size information within a multipath BSR in accordance with one or more embodiments of the invention;

Figure 8 is a block schematic diagram of an example wireless communication device in accordance with one or more embodiments of the present invention;

Figure 9 is a flowchart of a method performed at a UE in accordance with one or more embodiments of the present invention;

Figure 10 is a flowchart of a method performed at a base station in accordance with one or more embodiments of the present invention.

Detailed Description

Figure l is a schematic diagram illustrating an example wireless communication system 100 in which the present invention may be implemented according to one or more embodiments. The wireless communication system 100 is a communication system capable of supporting sidelink relaying or multipath relaying and shows a sidelink relay arrangement or system (or network) including a plurality of nodes including one or more relay User Equipment (UE) serving one or more remote User Equipment (UE).

For instance, in Figure 1, UE node 110 is served by network node 101 and may operate as a relay UE node relaying data between one of the UE nodes 111, 112, 113 (referred to as remote UE nodes) and the network node 101, hence performing UE-to-network (U2N) relay. In an example where the network node 101 is part of a cellular network, the relay UE 110 is served by a cell controlled by the network node 101. UE node 120 is served by network node 102 and may also operate as a UE-to-network (U2N) relay UE node (for example, relaying data between the remote UE 121 and the network node 102).

UE node 130 is also served by network node 102 and may have some relaying capability, i.e. UE node 130 may act as a UE-to-network (U2N) relay UE at some time, even though it is not serving any remote UE at the time represented in Figure 1.

The network nodes 101 and 102 may be base stations of a wireless network, such as a fifth-generation (5G) New Radio (NR) network or a Long Term Evolution (LTE) network. Figure 1 only shows the base stations of the wireless network for clarity. For a 5G NR network, the network node 101, or 102, is referred to as a gNodeB, or gNB.

Even though sidelink relay is most likely to be considered in the context of V2X networks, it is not intended that the invention is limited to UE nodes that are in, or part of, a vehicle. Each of the UE nodes (relay or remote) may be a wireless communication device located in or part of a vehicle or a Road Side Unit (RSU) or a wireless communication device of a Vulnerable Road User (VRU) (e.g. a mobile or portable communication device (such as a smart phone, PDA, laptop, or similar devices) of a pedestrian or cyclist). In the following, a relay UE node will also be referred to as a relay UE, a remote UE node will also be referred to as a remote UE and a network node will be referred to as a gNB. Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR network, it will be appreciated that it is not intended that the present invention is limited to 5G NR systems and may be used in any wireless communication systems supporting sidelink (or peer to peer) relay communications.

In an example shown in Figure 1, in a UE-to-Network (or U2N) scenario with the UE 110 (or UE 120) operating as a UE-to-Network relay UE, the UE-to-Network relay UE 110 (or relay UE 120) connects the UEs 111 and 112 (or UE 121), operating as remote UEs, to the gNB 101 (or gNB 102). The remote UE 111 is connected to the relay UE 110 via or through a sidelink I l la which may be referred to as a PC5 hop or link or connection or interface or leg I l la. Similarly, remote UE 112 and remote UE 121 have PC5 hops, or links or connections or interface or legs 112a and 121a respectively with the relay UE 110 and relay UE 120. A Uu hop or link or connection or interface or leg 110a connects the relay UE 110 to the gNB 101, while a Uu hop or link or connection or interface or leg 120a and 130a respectively connect the relay UE 120 and the UE 130 to the gNB 102. PC5 connections are used for the relayed traffic of the remote UEs (111, 112 and 121) and the non-relayed traffic specific to the relay UE 110, 120, i.e. for the direct communications between relay UE 110, 120 and the other remote UEs (111, 112 and 121). Therefore, the remote UE 111 is connected to the gNB 101 through the relay UE 110 with a PC5 hop I l la and a Uu hop 110a. For uplink communication, the remote UE I l l is the source node (or transmitter node for transmitting data) and the gNB 101 is the destination or target node (or receiver node for receiving data) for a sidelink relay connection established between the remote UE 111 and the gNB 101 with a PC5 hop I l la and a second Uu hop 110a. For downlink communication, the remote UE 111 is the destination or target node (or receiver node) and the gNB 101 is the source node (or transmitter node). Similarly, the remote UE 121 is connected to the gNB 102 through the relay UE 120 with a PC5 hop 121a and a Uu hop 120a.

At some point, the gNB 101, acting as a source gNB, may decide to hand over the relay UE 110 to the gNB 102, which would then act as a target gNB. For example, in the case where the radio conditions in the serving cell (not shown in Figure 1) controlled by the source gNB 101 deteriorate such that the radio conditions in the target cell (not shown in Figure 1) controlled by the target gNB 102 are better than the serving cell, the source gNB 101 may decide to handover the relay UE 110 to the target gNB 102. In such a case, the relay UE 110 would detach from the source gNB 101, thereby releasing the Uu link 110a to further connect to the target gNB 102 through Uu link 110b (shown in dotted lines in Figure 1) established as part of a re-establishment procedure.

In another example shown in Figure 1, in a multipath relaying scenario with the UE 113 operating as a remote UE, the UE 113 is connected to the gNB 101 via or through a direct path or link or connection or interface or leg 113b and an indirect path via the relay UE 110. The remote UE 113 is connected to the relay UE 110 via or through a sidelink 113a which may be referred to as a PC5 hop or link or connection or interface or leg 113a. A Uu hop or link or connection or interface or leg 110a connects the relay UE 110 to the gNB 101. PC5 connection 113a is used for the relayed traffic of the remote UEs and the non-relayed traffic specific to the relay UE 110, i.e. for the direct communications between relay UE 110 and the remote UE 113. Therefore, the remote UE 113 is connected indirectly to the gNB 101 through the relay UE 110 with a PC5 hop 113a and a Uu hop 110a.

Thus, the remote UE 113 has one direct path (113b) and one indirect path (113a, 110a) through the relay UE 110. When multipath relaying is configured at UE 113, data traffic from/to the remote UE 113 can be sent via the indirect path and/or the direct path. Figure 1 shows the remote UE 113 having two separate paths to the network (e.g. one direct path and one indirect path). It will however be appreciated that remote UE 113 may have two separate paths which are two indirect paths to the network. Furthermore, the remote UE 113 may have more than two separate paths to the network: for example, one direct path and at least two indirect paths.

For uplink communication, the remote UE 113 is the source node (or transmitter node for transmitting data) and the gNB 101 is the destination or target node (or receiver node for receiving data) for a multipath relaying established between the remote UE 113 and the gNB 101. The multipath relaying has a sidelink relay connection or path with a PC5 hop 113a and a second Uu hop 110a and an additional direct connection or path with a Uu hop 113b. For downlink communication, the remote UE 113 is the destination or target node (or receiver node) and the gNB 101 is the source node (or transmitter node).

In order to set up a relayed traffic between a first node (remote UE) and a second node (gNB or another remote UE), a sidelink relay architecture may be used on the indirect path according to the 3GPP TR 38.836. The user plane architecture or protocol stack is shown in Figure 2 and represents the sidelink relay adaptation layer called SRAP (i.e. Sidelink Relay Adaptation Protocol) that is introduced between the PDCP (Packet Data Convergence Protocol) layer and the RLC (Radio Link Control) layer at the extreme nodes and above the RLC layer in the relay UE. This architecture was first documented in the TR 38.836 and finally refined in 3GPP TS 38.300 while the SRAP layer is defined in 3GPP TS 38.351.

This architecture shown in Figure 2 shows the sidelink relay architecture 200 for the UE- to-Network relay scenario. As shown in Figure 2 illustrating a UE-to-Network relay scenario, the remote UE, such as remote UE 113, has a PC5 SRAP layer or entity 201 between its Uu PDCP layer or entity and its PC5 RLC layer or entity. Similarly, the gNB, such as gNB 101, has a Uu SRAP layer or entity 204 between its Uu PDCP layer or entity and its Uu RLC layer or entity.

As shown in Figure 2 related to a UE-to-Network relay scenario, at the relay UE, such as relay UE 110, there are two SRAP layers to interface with the PC5 hop 113a and the Uu hop 110a: the PC5 SRAP layer or entity 202 is connected to the PC5 SRAP or entity 201 of the remote UE 113 through the PC5 hop 113a; and the Uu SRAP layer or entity 203 is connected to the Uu SRAP layer or entity 204 at the gNB side 101 through the Uu link 110a. A remote UE 113 establishes End-to-End radio bearers 205 with the gNB 101. These radio bearers could be, for example, a Signalling Radio Bearer (SRB) and/or a Data Radio Bearer (DRB). Figure 2 shows an E2E Uu DRB between the remote UE 113 and the gNB 101 by way of example.

The PC5 SRAP layer 202 of the UE-to-Network relay UE 110 receives data or packets (traffic data or signalling) over, or via, ingress PC5 RLC channels 206 from remote UE 113 (at PC5 hop 113a) in an uplink direction and transmits the packets to the Uu SRAP entity 203 of the same relay UE 110.

The Uu SRAP 203 entity will map the corresponding ingress PC5 RLC channels 206 to egress Uu RLC channels 207aband/or 207b at Uu link 110a. Thus, a mapping table is required for uplink and it is configured by gNB 101 at the Uu SRAP entity 203 of the relay UE 110.

The mapping table takes at its input an identifier of the remote UE 113 (e.g. L2-ID), an identifier of the E2E radio bearer 205 (e.g. the E2E Uu DRB 205 ID) and an identifier of the ingress PC5 RLC channel (or bearer) 206 and identifies the egress Uu RLC bearer ID where the E2E radio bearers are mapped. For example, the UE E2E bearer ID and remote UE ID can be obtained from the header of a data packet received at the Uu SRAP entity 203. An example of an entry for an uplink mapping table with one entry configured at the Uu SRAP entity 203 is shown in Table 1 below. It will be appreciated that the mapping table will be configured so that it has an entry for each remote UE connected to the relay UE.

Table 1

At the Uu side or link 110a, different radio bearers of the same remote UE or different remote UEs can be subject to N:1 mapping and data multiplexing over Uu RLC channels 207a and 207b.

In the downlink direction, data or packets transmitted from gNB 101 arrive at the relay UE 110 through the Uu link 110a. The ingress Uu RLC channels 207a and 207b at the Uu SRAP entity 203 of the relay UE 110 will be mapped to the egress PC5 RLC channels 206 at PC5 hop 113a. The corresponding packets in downlink will be transmitted from the Uu SRAP entity 203 to the PC5 SRAP entity 202 to be then transmitted through the PC5 RLC channels 206 to the remote UE 113. Thus, a mapping table is required for downlink and it is configured by the gNB 101 at Uu SRAP entity 203 of the relay UE 110. The mapping table requires at its input the remote UE 113 L2-ID, the End-to-End radio bearer 205 ID and the ingress Uu RLC channel (or bearer) 207a or 207b ID and delivers the egress PC5 RLC channels (or bearer) 206 ID to the PC5 SRAP entity 202 of the same relay UE 110. The End-to-End Radio bearer 205 is then mapped at the PC5 hop 113a to the egress PC5 RLC channels 206. For example, the UE E2E bearer ID and remote UE ID can be obtained from the header of a packet received at the Uu SRAP entity 203. An example of a downlink mapping table with one entry configured at the Uu SRAP entity 203 is shown in Table 2 below. It will be appreciated that the mapping table will be configured so that it has an entry for each remote UE connected to the relay UE.

Table 2

As mentioned in 3GPP TS 38.351, each SRAP entity has a transmitting part and a receiving part. Across the PC5 interface 113a, the transmitting part of the PC5 SRAP entity 201 at the remote UE 113 has a corresponding receiving part at PC5 SRAP entity 202 at the UE-to-Network Relay UE 110, and vice-versa. Across the Uu interface 110a, the transmitting part of the Uu SRAP entity 203 at the UE-to-Network Relay UE 110 has a corresponding receiving part at Uu SRAP entity 204 at the gNB 101, and vice-versa.

In order to set up multipath relaying of traffic between a first node (e.g., remote UE 113) and a second node (e.g., gNB 101), the remote UE 113 should be connected to the gNB 101 through a direct path (e.g. via link 113b) and an indirect path via the U2N relay UE 110. The multipath relaying supports three types of bearers which include a direct bearer mapped to the direct path on Uu link 113b, an indirect bearer mapped to the indirect path via the relay UE 110, and the MP bearer (Multi-Path bearer) mapped to both the direct path and the indirect path.

The direct bearer may use the same protocol stack used for Uu direct link, e.g., one PDCP entity at the remote UE 113 is configured with a single direct Uu RLC entity at the remote UE 113.

The indirect bearer may use the same protocol as in figure 2 with a sidelink relay architecture, e.g., one PDCP entity at the remote UE 113 is configured with a single indirect PC5 RLC entity at the remote UE 113.

However, as the MP bearer 301 is mapped to two paths and thus, a multipath user plane architecture or protocol stack 300 of the remote UE 113 should be considered as shown in figure 3 which shows a direct path 301a and an indirect path 301b. The MP bearer 301 is mapped to two RLC entities 304 and 305: one RLC entity 304 for the direct path 301a and one RLC entity 305 for the indirect path 301b. For multi-path relaying with more than two paths, there will be more than two RLC entities in the protocol stack 300.

The MP bearer 301 has one PDCP entity in 302 at the remote UE. The PDCP entity 302 is configured with one direct Uu RLC channel and one indirect PC 5 RLC channel. For a MP bearer, one PDCP entity 302 is considered. The data traffic can be split at 303 between PDCP entity and RLC entities for upstream and downstream traffic. For upstream or uplink, the PDCP entity 302 may deliver data to a Uu RLC entity 304 and a PC5 RLC entity 306 associated to a PC5 SRAP entity 305 at the remote UE side. For downstream or downlink, the PDCP entity 302 may receive the data from a Uu RLC entity 304 and a PC5 RLC entity 306 associated to a PC5 SRAP entity 305 at the remote UE side.

At 303, and for an upstream traffic, the data packets can be either duplicated or split based on the MP bearer configuration. For example, a data duplication may distribute the same data packets to the two RLC entities 304 and 306. In another example, a data split may consider splitting the data packets on one or two paths depending on the resource allocation and the MP bearer configuration. Thus, a PDCP data PDU may be submitted or provided to either Uu RLC entity 304 or PC5 RLC entity 306 in an uplink transmission.

The data transmitted to the RLC entities may then be delivered to the MAC entities for uplink transmission. In a multipath relaying protocol stack, the remote UE (e.g. remote UE 113) may have either a single MAC entity as shown by the dotted box 309 combining Uu MAC functionalities and PC5 MAC functionalities or separate MAC entities wherein the Uu MAC entity 308 and the PC5 MAC entity 307 may be associated to the Uu RLC entity 304 and the PC5 RLC entity 306 respectively.

According to TS 38.321, clause 5.4.5, the MAC entity determines the amount of UL data available for a logical channel (corresponding to a Radio Bearer RB) according to the data volume calculation procedures in TS 38.323 and in TS 38.322 respectively for the PDCP and RLC layer.

In case of data split, as described above the transmitting PDCP entity (e.g. PDCP entity 302) is associated with at least two RLC entities (e.g. RLC entities 304, 306). For the data volume calculation, the PDCP entity indicates the PDCP data volume to both the MAC entities associated with the two RLC entities involved with the data split for BSR triggering and Buffer size calculation (as specified in TS 38.323 clause 5.6).

Based on data volume calculation in TS 38.323, and for a data split, the MAC entity (e.g. single MAC entity 309 or separate MAC entities 308 and 307) may receive separate data volume for the Uu leg or direct path 301a (e.g. Uu leg or link 113b) and PC5 leg or indirect path 301b (e.g. the indirect path may include a PC5 leg or link 113a and a Uu link 110a). For instance, the Uu leg may indicate a PDCP data volume and a Uu RLC data volume to the MAC entity 309 or 308 for the direct path 301a. The PC5 leg may indicate a PDCP data volume and a PC5 RLC data volume to the MAC entity 309 or 307 for the indirect path 301b. Then, the buffer size calculation is performed for all radio bearers per Logical Channel Group (LCG) corresponding either to Uu leg (e.g. direct path 301a) or PC5 leg (e.g. indirect path 301b). The LCGs for Uu are different to the LCGs (SL-LCG) for sidelink (SL). The buffer size is calculated per LCG or SL-LCG. In other words, the buffer size calculation is performed for all logical channels (where each logical channel corresponds to a radio bearer (SRB or DRB)) of this LCG for the direct path 301a or for the indirect path 301b based on the volumes provided to the MAC entities.

In the case where data of a MP bearer is mapped to two paths and so is to be split for transmission over two paths (such as paths 301a, 301b), after buffer size calculation (e.g. after the determination of the amount or volume of data pending or available to be transmitted by the remote UE to the network over the two paths) in the corresponding LCG at MAC entitie(s) at Uu leg and PC5 leg due to the data split, the remote UE may trigger a B SR to request uplink resources for Uu transmission and a SL-BSR to request uplink resources for Sidelink transmission. Therefore, two buffer status report can be triggered due to the data split and the two buffer status reports include the data volume for a MP bearer wherein:

The BSR may report in one of its buffer sizes, the PDCP data volume and the Uu RLC data volume of a MP bearer;

The SL-BSR may report in one of its buffer sizes of a destination, the same PDCP data volume and the PC5 RLC data volume for the same MP bearer.

Hence, the PDCP data volume is reported twice in the BSR and SL-BSR according to TS 38.323. All the reported PDCP data may not be transmitted over both the direct path and the indirect path, thus, the requested resources for uplink may exceed the exact need at the remote UE side.

Furthermore, the remote UE in UL data split, may submit the PDCP PDU to either the primary RLC entity or split secondary RLC entity according to TS 38.323, clause 5.2.1. However, the remote UE is not aware of the radio conditions on both paths (e.g. the radio conditions on the primary path associated with the primary RLC entity, such as a direct path, and the secondary path associated with the secondary RLC entity, such as the indirect path). In an example, deteriorating radio conditions may occur at Uu leg 110a of the indirect path and may not be known at remote UE side. Hence, the remote UE may distribute the load among paths without taking into consideration the load at each leg of the multipath relaying system and their radio conditions. Thus, the data transmitted via the indirect path may suffer from data loss and delay which can cause an unbalanced load distribution amongst paths in UL. Referring now to figure 9 which is a flow chart showing steps of a method 900 for managing buffer status reporting for data to be transmitted by a user equipment, UE, to a network (e.g. to a base station of the network) of a communication system supporting sidelink relaying in accordance with one or more embodiments of the present invention. The data to be transmitted is pending or available data held in a buffer at the UE for transmission to the network. Method 900 is performed at the UE. The communication system supporting sidelink relaying includes a base station, the UE (e.g. a UE operating or functioning as a remote UE), and at least one relay node (e.g. a UE operating or functioning as a relay). The UE can communicate with the base station over at least two separate paths. For example, the UE may be directly connected to the base station via a direct path and/or may be indirectly connected to the base station via at least one relay node (e.g. a relay UE) and thus, via an indirect path. Additionally or alternatively, the UE may be connected to the base station via at least two indirect paths. With respect to the example shown in figure 1, the UE performing method 900 may be remote UE 113 and the base station may be the base station 101 (also referred to as gNB 101). In the following description, the UE may be referred to as a remote UE. The remote UE 113 may be directly connected to the gNB 101 via connection or Uu link 113b which provides a direct path and/or may be indirectly connected to the gNB 101 via a relay UE node 110 via connection or PC5 link 113a and connection or Uu link 110a, which connect! ons/links provide an indirect path. The method 900 as shown in and described with respect to figure 9 may be performed by software elements and/or hardware elements. Thus, for example, the method as shown in and described with respect to figure 9 may be performed by an apparatus for the UE comprising one or more processing units configured to carry out the method. The UE may be implemented in a communication device 800 as shown in and described with reference to figure 8 with the method as shown in and described with respect to figure 9 being performed by one or more processing units, such as the central processing unit 811.

Briefly, at step 902, the UE 113 determines data to be transmitted to the base station 101 is to be split for transmission over at least two separate paths. As discussed above, the at least two separate paths may include a direct path (such as over Uu link 113b) and one or more indirect paths (such as over PC5 link 113a and Uu link 110a) or two or more indirect paths. In an example, the data to be transmitted is data associated with a Radio Bearer, such as a MP bearer (also referred to as a multipath radio bearer or multipath bearer) which is mapped to the at least two separate paths. What paths are available depend on the connections made by the UE 113 to the network and may also depend on the MP bearer configuration. The UE 113 may determine data associated with the MP bearer to be transmitted is to be split for transmission to the base station 101 over two separate paths such that PDCP data associated with the MP bearer is to be transmitted over at least one of the at least two separate paths. For example, the UE 113 may split or divide the data to be transmitted so that a first part of the PDCP data (e.g. a first set of PDCP Packet Data Units (PDUs) is to be transmitted over a first one of the at least two separate paths (e.g. via the and a second part of the PDCP data (e.g. a second set of PDCP PDUs) is to be transmitted over a second one of the at least two separate paths. In one example, the determination that data is to be split may result in a determination that all of the PDCP data is to be transmitted over the first path. The dividing or the splitting of the PDCP data to be transmitted may be based on configuration information provided to the UE by the network. For example, the configuration may indicate a ratio of how the PDCP data is to be split/divided (which may be 1 :0 for two paths in the case where the PDCP data is to be transmitted over one of the paths) or an indication of the number of PDCP PDUs that are to be transmitted in each path. The first path may be a primary path or default path and the second path may be a secondary path.

In an example, the UE 113 determines that the data to be transmitted is to be split after determining a volume of data (e.g. total amount of PDCP data volume and RLC data volume pending for transmission over all paths) to be transmitted to the base station 101 exceeds a threshold.

Alternatively, how the PDCP data is to be split and/or when it is to be split may be determined by the UE 113 itself.

The MP bearer is associated with multiple logical channels, with each logical channel having a Logical Channel ID (LCID). The number of logical channels depends on the number of RLC entities to which the MP bearer is mapped. If MP RB is associated with n RLC entities, it means that MP RB will have n logical channels where each logical channel is issued from a RLC entity. A Logical Channel Group (LCG) may be associated with a number of Radio Bearers (including MP -bearers), for example a number of RBs having the same or similar Quality Of Service (QoS) requirements.

In step 904, the UE 113 sends, to the base station 101, at least one buffer status report including information (also referred to as buffer size information in the description of Figures 4-7 below) for indicating a volume (e.g. an amount) of PDCP data of the data to be transmitted to the base station 101, the PDCP data to be transmitted over at least one path of the at least two separate paths. As discussed above, the PDCP data to be transmitted may be transmitted over one path or may be transmitted over two or more of the at least two separate paths. The determination as to which paths are used to transmit the PDCP data is based on the determination as to how the data is to be split. In the case where the network configures a 1 :0 ratio, the PDCP data is to be transmitted over one of the paths, which is normally a path associated with a primary RLC entity of the UE (which path may be referred to in the following as the primary or default path). The primary path may be a direct path or an indirect path.

The at least one buffer status report (BSR) includes information for indicating a volume of PDCP data to be transmitted (e.g. the pending or available PDCP data associated with the MP bearer that is to be transmitted to the network). The volume of PDCP data may be the total volume of PDCP data associated with the MP bearer to be transmitted. The information that is included can vary depending on the format of the BSR (e.g. whether it is a MP -BSR, SL-BSR, Uu BSR - more details are provided below with reference to Figures 4-7 of the different formats for the BSR). The information indicates the volume of the PDCP data directly (e.g. the volume of the PDCP data is given) or indirectly where the volume of the PDCP data is combined with the volume of the RLC data for one of the paths only and the total volume of the PDCP data and RLC data is provided. Thus, the information included in the BSR may include a volume of the PDCP data to be transmitted or may include a volume of data which includes the PDCP data (e.g. in the latter case the volume of data is the volume of RLC data and volume of PDCP data).

The at least one BSR is generated and sent after the UE 113 determines there is data to be transmitted to the network and the data to be transmitted is to be split over the at least two paths (e.g. the data to be transmitted is associated with a MP bearer and the data is to be split). The sending of the at least one BSR enable the UE 113 to request resources for transmitting the data associated with the MP bearer to the network.

A PDCP entity of the UE may determine data to be transmitted is to be split for transmission to the base station over at least two separate paths. In this case, the PDCP entity indicates to a MAC entity of the UE associated with a path of the at least two separate paths (e.g. the MAC entity associated with a primary RLC entity of one of the at least two paths (which may be a direct path or an indirect path)), the volume of the PDCP data to be transmitted to the base station and a buffer status report associated with the path of the at least two separate paths is sent to the base station, which buffer status report includes the volume of the PDCP data indicated to the MAC entity. In another case, the PDCP entity indicates to one or more MAC entities of the UE associated with the at least two separate paths (e.g. one or more MAC entity(s) associated with a primary RLC entity of one of the at least two paths (which may be a direct path or an indirect path) and one or more split secondary RLC entities of one or more other paths of the at least two paths (e.g. one or more indirect paths)), the volume of the PDCP data to be transmitted to the base station and a buffer status report is sent to the base station, which buffer status report includes the volume of the PDCP data indicated to the one or more MAC entities (e.g. indicated to the MAC entity associated with a primary RLC entity with the PDCP data volumes indicated to the other MAC entities associated with the one or more secondary RLC entities being ignored) or comprises sending buffer status reports associated with the at least two separate paths, each of the buffer status reports including the volume of the PDCP data indicated to the one or more MAC entities.

In one example, a BSR associated with a primary path (e.g. default path) of the at least two paths is sent, which BSR includes information for indicating the volume of PDCP data to be transmitted to the base station 101. The information for indicating the volume of PDCP data to be transmitted may indicate implicitly to the base station 101 that the BSR is associated with a data split (i.e. the base station 101 can determine from the information in the BSR a data split case. In another arrangement, the BSR may further include information, such as in a subfield of the buffer size field ((e.g. 404, 405 are discussed below), indicating the data to be transmitted is to be split for transmission over the primary path and a secondary path of the at least two separate paths. The information in the subfield may be a data split flag.

In another example, sending at least one BSR comprises sending a first buffer status report including information for indicating the volume of data, including a first part of the PDCP data to be transmitted over a first path of the at least two separate paths and a second buffer status report including information for indicating the volume of data, including a second part of the PDCP data to be transmitted over a second path of the at least two separate paths. The volume of the first part of PDCP data and the volume of the second part of the PDCP data will depend on how the PDCP to be transmitted is split between the first and second paths. In an example where the data is associated with a MP bearer mapped to a direct path and an indirect path (e.g. the first path is a direct path and the second path is an indirect path), the first BSR is a Uu-BSR for the direct path and the second BSR is a SL-BSR for the indirect path. Alternatively, the first path may be an indirect path and the second path may be a direct path. There may be more than two paths, such as one direct path (to report the BSR) and two or more indirect paths. What paths are available depend on the connections made by the UE 113 to the network and may also depend on the MP bearer configuration. The information included in the first buffer status report indicates the volume of data to be transmitted over the first path including a volume of the first part of the PDCP data and a volume of RLC data to be transmitted over the first path and the information included in the second buffer status report indicates the volume of data to be transmitted over the second path including the volume of the second part of the PDCP data and a volume of RLC data to be transmitted over the second path.

In another example, sending at least one BSR comprises sending a first buffer status report (e.g. a Uu-BSR) including information for indicating the volume of PDCP data to be transmitted to the base station 101 (e.g. total volume) and a volume of RLC data to be transmitted over a first path of the at least two separate paths and a second buffer status report (e.g. a SL-BSR) including information for indicating a volume of RLC data to be transmitted over a second path of the at least two separate paths, the second buffer status report not including information for indicating the volume of PDCP data to be transmitted. In this example, the volume of PDCP data is reported only in one of the BSRs (e.g. the BSR for the primary path which is typically the direct path over the Uu link).

Thus, the BSRs sent to the base station 101 as described above report the exact data volume to be transmitted over the at least two paths so that the base station 101 can allocate resources that are needed and allocation of unnecessary resources can be avoided. Furthermore, the UE 113 can determine how the data is to be split across the at least two paths.

In another example, sending at least one BSR comprises sending a multi-path buffer status report (MP -BSR) including PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station 101 (e.g. total volume of PDCP data), a first buffer status report including information for indicating the volume of data, including RLC data to be transmitted over a first path of the at least two separate paths and a second buffer status report including information for indicating the volume of data, including RLC data to be transmitted over a second path of the at least two separate paths. In an example where the data is associated with a MP bearer mapped to a direct path and an indirect path (e.g. the first path is a direct path and the second path is an indirect path), the first BSR is a Uu-BSR for the direct path and the second BSR is a SL-BSR for the indirect path. Alternatively, the first path may be an indirect path and the second path may be another indirect path or a direct path. This is an example of where the MP -BSR includes just one subfield which includes information representing the volume of the PDCP data. The subfields of the MP -BSR are discussed in more detail below. In another example, sending at least one BSR comprises sending a multi-path buffer status report (MP -BSR) including PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station 101 and RLC information for indicating a volume of RLC data to be transmitted over a first path of the two separate paths. As discussed in more detail with reference to Figure 5, the PDCP data volume information may be included in one of the subfields 501 or 502 and the RLC information may be included in the other subfield 502 or 501. For more details as to the possible combination of information in these subfields for different types of radio bearers, see the description below with reference to Figure 5. In this case, in addition to sending the MP -BSR, the UE 113 may also send a buffer status report for a second path of the two separate paths, wherein the buffer status report for the second path includes RLC information for indicating a volume of RLC data to be transmitted over the second path. The buffer status report for the second path may include the PDCP data volume information representing a volume of the PDCP data to be transmitted and the RLC information. In an example, where the second path is an indirect path, the buffer status report for the second path is a SL-BSR.

In another example, sending at least one BSR comprises sending a multi-path buffer status report (MP -BSR) including PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station 101 and RLC information for indicating a volume of RLC data to be transmitted over a first path of the two separate paths and RLC information for indicating a volume of RLC data to be transmitted over a second path of the two separate paths. As discussed in more detail with reference to Figure 6, the PDCP data volume information may be included in one of the subfields 601-603 (e.g. subfield 601), the RLC information for indicating a volume of RLC data to be transmitted over a first path may be included in another one of the subfields 601-603 (e.g. subfield 602) and the RLC information for indicating a volume of RLC data to be transmitted over a second path may be included in another one of the subfields 601-603 (e.g. subfield 603). For more details as to the possible combination of information in these subfields for different types of radio bearers, see the description below with reference to Figure 6.

In addition to reporting the volume of data to be transmitted which data is associated with a MP bearer where the data is split over at least two paths (e.g. MP-RB with data split mode), the MP -BSR sent by the UE 113 may also be configured to report the volume of data to be transmitted which data is associated with other types of radio bearers, such as a MP bearer where the data is not split over at least two paths (e.g. MP-RB in a non-split mode). In the case where the MP-RB is in a non-split mode, the primary path will be a direct path (Uu direct bearer or the Uu RLC entity is the primary RLC entity) or an indirect path (where the PC5 RLC entity is the primary RLC entity).

In another example, sending at least one BSR comprises sending a multi-path buffer status report (MP -BSR) including PDCP data volume information for a radio bearer (e.g. MP bearer in a split mode) representing a volume of the PDCP data associated with the radio bearer to be transmitted to the base station 101, the PDCP data to be transmitted over the at least two separate paths, and RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted to the base station 101 over a first path of the two separate paths. The MP -BSR further includes data volume information for another radio bearer (e.g. MP bearer in a non-split mode or another MP bearer in a split mode or a single radio bearer, such as a Uu direct bearer or a SL indirect bearer) representing the volume of PDCP data of the another radio bearer to be transmitted to the base station 101, and a volume of RLC data of the another radio bearer to be transmitted to the base station 101, the PDCP data and RLC data to be transmitted over a first path (e.g. primary/default path) of the two separate paths. In an example, the data volume information includes RLC volume information indicating the volume of RLC data and PDCP volume information indicating the volume of PDCP data or the data volume information includes total volume information indicating the total volume of the RLC data and the PDCP data. The data volume information may include RLC volume information indicating the volume of RLC data of a single path (e.g. a direct or indirect path) or the data volume information includes total volume information including PDCP data volume of the single path.

The UE 113 decides the format of the MP -BSR. In an example, the decision to send a MP -BSR is triggered after the UE 113 determines there is data to be transmitted to the network and the data to be transmitted is to be split over the at least two paths (e.g. the data to be transmitted is associated with a MP bearer and the data is to be split).

The above description of sending a MP -BSR to request resource allocation from the network discusses in particular a case where the UE 113 determines there is data to be transmitted to the network and the data to be transmitted is to be split over the at least two paths (e.g. the data to be transmitted is associated with a MP bearer and the data is to be split - MP-RB in split mode). It will however be appreciated that the sending of a MP -BSR with the formats as discussed above is not limited to the case where data to be sent is associated with a MP-RB in split mode but may also be used in the case where data to be sent is sent over at least two paths in other scenarios where the data is not split: e.g. data is to be duplicated and duplicate data is to be sent over the at least two paths or data is associated with a MP-RB in a non-split mode. The above description of the MP-BSRs also applies to these other scenarios (e.g. but without step 902 which is shown in a dotted box in figure 9). Furthermore, the MP-BSRs may further include, in addition to buffer size information (e.g. including PDCP volume information indicating the volume of PDCP data to be transmitted to the base station) for a MP radio bearer (split mode or non-split mode), buffer size information for one or more single path radio bearers (such as a Uu radio bearer or a SL radio bearer) volume information for PDCP data to be transmitted to the base station over a single path (e.g. direct or indirect path).

With the introduction of a MP-BSR sent to the base station 101 as described, the exact PDCP data volume to be transmitted over the at least two paths can be reported to the network so that the base station 101 can allocate resources that are needed and allocation of unnecessary resources can be avoided. Furthermore, with the information provided for the volume of PDCP data to be transmitted in the MP-BSR reports as described above, the base station 101 can determine how the data is to be split across the at least two paths. Since the base station 101 can determine the radio conditions on the links for the direct and indirect paths (e.g. through measurement reports received at the base station), the base station 101 is aware of the radio conditions and can distribute dynamically the load (e.g. PDCP data) among the at least two paths taking into consideration the load in each path and the radio conditions over all the links in each of the paths. The MP-BSR may also function to allow the base station 101 to allocate resources that are needed and allocation of unnecessary resources can be avoided but without reporting the exact PDCP data volume to the network. For example, in the case of data split mode with a primary path and secondary path, the PDCP data volume in a data split mode can be indicated to the MAC entity(s) for the primary path and the split secondary path(s) with a data split flag indicating the data is to be split over the two paths. The MAC entity (of the primary path) may then report in the MP-BSR the indicated PDCP data volume (e.g. PDCP data volume over both paths) while ignoring (i.e. not including in a BSR) other indications of the PDCP data volume received by other MAC entities (e.g. of the secondary path(s)). Otherwise, the MAC entity may report the total PDCP data volume to the gNB in the PDCP data volume sub-field and then the gNB will be able to retrieve the exact PDCP data volume when data split.

The different formats for the BSRs will be described in more detail below with reference to Figures 4 to 7.

Referring now to Figure 10 which is a flow chart showing steps of a method 1000 for managing resource allocation for data to be transmitted by a user equipment, UE, to a base station of a communication system supporting sidelink relaying where the UE can communicate with the base station over at least two separate paths in accordance with one or more embodiments of the present invention. The data to be transmitted is pending or available data held in a buffer at the UE for transmission to the network. Method 1000 is performed at the base station. The communication system supporting sidelink relaying includes a base station, the UE (e.g. a UE operating or functioning as a remote UE), and at least one relay node (e.g. a UE operating or functioning as a relay). The UE can communicate with the base station over at least two separate paths. For example, the UE may be directly connected to the base station via a direct path and/or may be indirectly connected to the base station via at least one relay node (e.g. a relay UE) and thus, via an indirect path. Additionally or alternatively, the UE may be connected to the base station via more than two paths: for example, a direct path (to report the BSR) and at least two indirect paths.

With respect to the example shown in figure 1, the base station performing method 1000 may be the base station 101 (also referred to as gNB 101) and the UE may be remote UE 113. In the following description, the UE may be referred to as a remote UE. The remote UE 113 may be directly connected to the gNB 101 via connection or Uu link 113b which provides a direct path and/or may be indirectly connected to the gNB 101 via a relay UE node 110 via connection or PC5 link 113a and connection or Uu link 110a, which connect! ons/links provide an indirect path. The method 1000 as shown in and described with respect to figure 10 may be performed by software elements and/or hardware elements. Thus, for example, the method as shown in and described with respect to figure 10 may be performed by an apparatus for the base station comprising one or more processing units configured to carry out the method. The base station may be implemented in a communication device 800 as shown in and described with reference to figure 8 with the method as shown in and described with respect to figure 10 being performed by one or more processing units, such as the central processing unit 811.

Briefly, at step 1002, the base station 101 receives, from the UE 113, a multi-path buffer status report (MP -BSR) including PDCP data volume information representing a volume of PDCP data of data associated with a radio bearer to be transmitted to the base station 101. The data associated with the radio bearer to be transmitted is to be transmitted to the base station over the at least two separate paths. The information included in the MP -BSR may be the same as that described above with reference to Figure 9 and Figures 5 to 7.

The base station 101 determines communication conditions over the at least two separate paths, step 1004. The communication conditions may include the radio conditions of each link of each of the at least two separate paths and/or the load in each of the at least two separate paths.

Based on the determined communication conditions, at step 1006, the base station 101 determines an allocation of the volume of PDCP data to at least one path of the at least two separate paths. For example, if the radio conditions are below a threshold on the Uu link 110a for the indirect path between the UE 113 and the base station 101, the base station 101 may decide to allocate all of the PDCP data (e.g. total volume of the PDCP data) for transmission over the direct path and allocate resources accordingly. Alternatively, the base station 101 may decide to allocate a part of the PDCP data for transmission over one of the at least two separate paths and another part for transmission over another one of the at least two separate paths (e.g. 50:50 allocation) and allocate resources accordingly.

In step 1008, the base station 101 sends resource allocation information indicating the resources allocated for the transmission of data associated with the radio bearer to the base station based, in part, on the determined allocation of the volume of PDCP data. The resources allocated will also depend on the volume of RLC data to be transmitted over the at least two separate paths. The allocation of the resources by the gNB 101 is discussed in more detail below with reference to Figures 5 to 7.

Examples of formats for reporting the buffer status in a multipath relaying system with the exact PDCP data volume and associated RLC data volumes in accordance with one or more embodiments of the invention will be described in more detail with reference to figures 4, 5, 6 and 7. For example, the example formats described with reference to figures 4, 5, 6 and 7 are examples of formats for a MP-BSR described above with reference to figures 9 and 10, where data is to be transmitted by the UE over at least two paths in a communication system supporting sidelink relaying. UE 113 and gNB 101 of figure 1 may be considered as examples when referring to a remote UE and gNB/base station respectively.

In order to improve buffer status reporting (BSR) in a communication system supporting sidelink relay or multipath relaying using a MP-BSR, one or more of the following points may be considered: indicate the exact PDCP data volume to the MAC entitie(s), such as MAC entities 307 and 308 or 309 of figure 3. In the case where there are two MAC entities 307, 308, that the PDCP data volume may be indicated to one or both MAC entities 307, 308. define a multipath BSR (MP-BSR) triggering condition for multipath BSR (e.g. for triggering the generating and sending of the MP-BSR). generate a multipath BSR by selecting one of the different formats detailed in figures 4-7. and transmitting the multipath BSR to the network.

The figure 4 represents a general MP -BSR format with Logical Channel Group (LCG) ID in the fields 401, 402 and 403. The buffer size information corresponding to the data volume in each LCG is reported in one of the fields 404 and 405. For example, the buffer size information in the field 404 represents the data volume for the LCG ID in field 401 (e.g. the buffer size information in the field 404 represents the volume of data to be transmitted by the UE which data is associated with a radio bearer that is associated with the LCG ID included in field 401) and the buffer size information in the field 405 represents the data volume for the LCG ID in the field 402. The buffer size field in 404 or 405 may include the total amount of data available for transmission across all logical channels of a logical channel group. Each logical channel within the logical channel group LCG is associated to a radio bearer (RB), and a LCG may regroup a set of logical channels that have the same characteristics, e.g., QoS level. A Uu direct bearer and an indirect bearer may each have a single logical channel associated to a single RLC entity (Uu RLC entity for the Uu bearer and PC5 RLC entity for the indirect bearer). An MP bearer may have at least two logical channels associated to at least two RLC entities: an Uu RLC entity and PC5 RLC entity(s). In an example of multipath relaying with a direct path and an indirect path as in figure 3, the MP bearer 301 may have a Uu logical channel associated to the Uu RLC entity 304 and another SL logical channel associated to the PC5 RLC entity 306. Both logical channels are associated to the same or different logical channels groups in the MAC entity (s) in 306, 307 or 309.

The buffer size information in field 404 may take different formats with different subfields as represented in the figures 5-7 for the multi-path BSR (MP -BSR) in accordance with one or more embodiments of the invention. The MP -BSR buffer size information may include all or part of the information in the subfields. For example, the MP -BSR may include one or more of the subfields described below.

In a first example, the PDCP entity may indicate the exact PDCP data volume to the MAC entity(s) in case of data split. For example, the UE determines that the data to be transmitted to the network is to be split for transmission over at least two separate paths and may indicate the PDCP data volume to the MAC entity(s) after determining how the PDCP data is to be split for transmission. In an example implementation, it is proposed that a PDCP data volume 1 is indicated to the first MAC entity associated with the primary RLC entity (e.g. the default RLC entity) and a PDCP data volume 2 is indicated to the split secondary MAC entity associated with the secondary RLC entity in a data split case for two paths. The total amount of PDCP data volume 1 and PDCP data volume 2 is equal to the overall PDCP data volume present at PDCP layer in UL.

For instance, the PDCP data volume may be indicated to one MAC entity associated to one RLC entity. If the MAC entity is associated with a primary RLC entity, thus the PDCP data volume 1 is equal to the PDCP data volume and the PDCP data volume 2 is equal to null. Thus, the total amount of PDCP data volume is indicated on the primary leg (e.g. associated with transmission over a primary path) while no PDCP data volume indication on the split secondary leg.

The primary RLC entity is configured for each split bearer. A split bearer or MP split bearer, as introduced in figure 3, refers to MP bearer 301. An MP bearer may have more than one transmission path to the gNB and thus, one PDCP entity 302 for the MP bearer 301 is associated with more than one RLC entity(s) (304, 305) referring to the different associated paths. The example of figure 3 for multipath relaying includes one direct path 301a and one indirect path 301b. The MP bearer 301 may then transmit the data over the direct path using the Uu protocol stack (Uu RLC entity 304 and Uu MAC entity 308 or 309) and/or over the indirect path using the indirect protocol stack (PC5 SRAP 305, PC5 RLC entity 306 and PC5 MAC entity 307 or 309). The MP bearer may have different transmission modes as follows:

- Duplication mode wherein the data is transmitted over both paths and thus, the PDCP PDUs are transmitted over both paths.

- Non duplication mode with a data split condition. o The PDPC entity may consider to send the MP bearer data over one path configured by the gNB as the primary path and thus, the MP bearer is in a nondata split mode. o Otherwise, the MP bearer may be used in a data split mode wherein the PDCP PDUs are sent either on a primary path or secondary path. In the example of figure 3, considering the data split mode, the PDCP entity 302 may detect a data split triggering condition (e.g., total amount of data volume above a configured threshold) and thus, it may communicate the PDCP PDUs to one of the RLC entity(s) associated to the MP bearer and activated for data split mode.

For instance, the primary RLC entity may be a Uu RLC entity (or a PC5 RLC entity) and thus, the split secondary RLC entity is the PC 5 RLC entity (or Uu RLC entity).

The splitting or dividing of the PDCP data volume by the UE 113 may be configured at gNB side in the PDCP layer configuration for the case of multipath relaying with two RLC entities (e.g. the gNB 101 may configure the UE 113 to perform the dividing of the PDCP data volume by providing configuration information to the UE 113 indicating how the PDCP data volume is to be divided). In an example, the gNB 101 may add a MP MoreThanOneRLC field in the PDCP configuration information element (e.g. which is sent to the UE 113). This field configures UL data transmission when more than one RLC entity in multipath relaying transmission is associated with the PDCP entity. The MP MoreThanOneRLC field may include all or parts of the following information:

- Primary path: Every MP bearer may have its proper primary path. In case of non-data split for a MP bearer, the primary path is considered as the default path to deliver data in uplink. For example, the Uu path (direct path) may be configured by the gNB 101 to be the primary path for a given MP bearer at the remote UE 113. Thus, when non-data split, all UL data may be delivered via the Uu path. The primary path information or identity may refer to the remote UE ID.

The remote UE 113 may have a first ID corresponding to the C-RNTI for the direct path 113b and a second ID corresponding to the L2-ID for the PC5 link 113a of the indirect path via the relay node 110. For a primary path on the Uu direct link, the remote UE ID may be configured as the C-RNTI ID on the direct link.

The logical channel associated to the split bearer at the primary path can be also added. The MP split bearer may have two logical channels and so, two logical channels ID (LCID) corresponding to the two RLC entities. The primary path can be associated to a primary RLC entity which is identified with a logical channel ID (LCID). Thus, the primary RLC entity and, the primary path may be identified with the LCID added to the information included in the MP MoreThanOneRLC field. In this case, the LCID corresponding to the primary RLC entity may be included in the primary path information.

UL-MPDataSplitThreshold: The gNB 101 may add a data split threshold for each MP bearer. In a way to determine the data split use case, the gNB may use this threshold parameter. If the total amount of PDCP data volume and RLC data volumes (Uu and PC5) are less than the threshold, the remote UE 113 may transmit the data on the primary path. Otherwise, if the total amount of data exceeds the UL- MPDataSplitThreshold, the remote UE can split UL data and transmit on either or both paths (direct and/or indirect). The gNB 101 may give the remote UE 113 the capacity to determine the split data ratio by using its proper algorithm (e.g. an algorithm provided at the UE 113) by setting the UL-MPDataSplitThreshold to a predefined value.

The condition of data split may not be limited to this parameter and may be determined by the gNB as a function of other parameters.

- UL-MPPDCPSplitRatio: The gNB may configure the remote UE with a PDCP data volume split ratio when data split occurs at PDCP layer. This value may be set by the gNB to distribute the PDCP data volume either on two paths or to deliver the PDCP data volume on one path (e.g., primary path). Moreover, the gNB may give the remote UE the capacity to determine the PDCP split ratio depending on its proper algorithm (e.g. using an algorithm provided at the UE 113).

In this first example where the PDCP entity of the UE 113 indicates the exact PDCP data volume to the MAC entity(s) in case of data split of splitting or dividing, the PDCP data volume reported in the buffer size information reflects the real need of the remote UE. The remote UE may then report the exact data volume on BSR and SL-BSR to request UL resources on the direct link and the indirect link respectively.

For instance, considering the primary path associated with the direct link 113b for UE 113, the BSR sent by the UE 113 may provide the serving gNB 101 with information about UL data volume in the MAC entity (308 or 309) associated with the Uu primary RLC entity 304. This UL data volume in 308 (or 309) may include a PDCP data volume 1 and the Uu RLC data volume. In the other hand, the SL-BSR sent by the UE 113 may report to the serving gNB 101 with information about UL data volume in the MAC entity (307 or 309) associated with the PC5 split secondary RLC entity 306. This UL data volume in 307 (or 309) may include a PDCP data volume 2 and the PC5 RLC data volume.

The gNB may then allocate resources according to the distributed PDCP data volume on the two paths at the remote UE 113. As the channel occupancy and/or radio conditions on the two paths may change dynamically and suffer from delay and data loss, the configured PDCP split ratio may not be sufficient to optimize the load balancing on the two paths for a data split use case.

In an example, if the primary path (over Uu link 113b) suffers from deteriorating radio conditions or congestion, and a part or a full PDCP data volume is configured to be provided on the primary path, the link issue (congestion or radio conditions) may be aggravated because of excess resource allocation on the link 113b and it may cause QoS degradation with data loss and increased delay. Therefore, the gNB 101 may need to reconfigure the UL MP PDCP split ratio in order to split the PDCP data volume on the path with better radio conditions and less risk of link issue.

In another example, it is proposed to report the PDCP data volume separately (e.g. separately to the RLC data volume) in the buffer size information. A new BSR format which better takes into account multipath relaying functionalities is proposed and is represented in figures 4-7. This new BSR is referred to as a Multi-Path Buffer Status Report (MP -BSR) and may allow the gNB 101 to determine the PDCP data volume of MP bearer(s) and allocate resources dynamically as a function of radio conditions and congestion on each path.

This proposal of a new MP -BSR may not restrict the possible reporting of PDCP data volume to both MAC entities as specified in TS 38.323. In case of reporting twice the PDCP data volume to both MAC entities associated with the primary RLC entity and the secondary split RLC entity, the solution described below with MP -BSR formats may also be applied. The PDCP data volume reported separately in the MP -BSR by remote UE for MP bearers in a data split mode may indicate the double PDCP data volume needed and thus, the gNB may then take the fact that double PDCP data volume has been indicated into consideration for resource allocation.

Figure 4 is a schematic diagram illustrating an example format of a multipath BSR (MP- BSR) in accordance with one or more embodiments of the invention.

The MP -BSR indicates a new format for BSR in a multipath relaying system. The MP- BSR is provided to the gNB through a MAC-CE. The MAC-CE may include an LCID field indicating the presence of an MP -BSR and then the MP -BSR.

According to TS 38.321, clause 6.2.1, the table 6.2.1-1 represents the LCID or eLCID (extended LCID) values in one of the MAC subheaders corresponding to a MAC-CE type for an UL-SCH transport channel for UL data. The MP -BSR introduced in the present invention is a new MAC-CE type and thus one or more other LCIDs/eLCIDs may be needed in the table in order for the MP -BSR to be identified in a MAC PDU.

The table below represents an example of assigning the LCIDs to the new MP -BSR MAC-CEs (see the new LCID values assigned to index values 37-40).

Table 3

The table 3 is an example of assigning LCID/eLCID to a MP-BSR MAC-CE. The MP- BSR may not be restricted to the four types of MP-BSR listed for index values 37-40 in the table.

The short MP-BSR or short truncated MP-BSR may refer to one MP-BSR MAC-CE with a single LCG ID field and a single associated buffer size information. For example, a short MP-BSR may include the fields 401 referring to the LCG and its buffer size information in field 404. The long MP-BSR and long truncated MP-BSR may refer to several MP-BSR with multiple LCG ID fields and their corresponding buffer size information. For example, the figure 4 may illustrate a long MP-BSR wherein multiple LCG are represented in fields 401 and 402 with their corresponding buffer size information in fields 404 and 405.

The MP BSR may include a multipath LCG ID (MP -LCG ID) in at least one of fields 401, 402 and 403, where each field may correspond to an LCG ID, or a Sidelink LCG ID or a proper multipath LCG (MP -LCG) configured by the gNB. Every MP -LCG may include several MP-LCIDs wherein each MP-LCID corresponds to a bearer (e.g., direct bearer, indirect bearer or MP bearer).

For instance, the MP -LCG ID field (401, 402 or 403) may use the same LCG used for a direct bearer on the direct path (e.g. the MP -LCG ID field may indicate a MP -LCG for MP bearer(s) which is the same as a LCG used for a direct bearer). The MP -LCG may then regroup the logical channels of direct bearers and/or MP bearers.

The MP -LCG ID field (401, 402 or 403) may use the SL-LCG dedicated for Sidelink. The MP -LCG may then contain the logical channels of indirect bearers and/or MP bearers.

The MP -LCG may contain a combination of logical channels corresponding to Uu logical channels and SL logical channels. Thus, different logical channels of different bearers are mapped to the same MP-LCG. The MP-LCG may then contain logical channels of indirect bearers, direct bearers and MP bearers. Otherwise, the LCG ID in 401 may refer to new multipath logical channel group (MP-LCG) ID mentioned previously and dedicated only for group of logical channels of MP -bearers.

The fields 401, 402 and 403 may contain either the MP-LCG ID or a single binary field to indicate if this MP-LCG ID has a buffer size. If a binary representation is used, the field 402 set to null may indicate that the corresponding buffer size information is not reported.

The MP BSR may include at least one buffer size information field 404, 405. The buffer size information in the fields 404 and 405 identifies the total amount of data available to be transmitted by the UE 113 according to the data volume calculation procedure in TS 38.323 across all logical channels of a logical channel group. The buffer size information in field 404 (or 405) may refer to the total data volume reported to the MAC entity for the LCG identified in 401 (or 402).

The buffer size information for a BSR as described in the TS 38.321 is a simple one block including all the data volumes for PDCP layer and RLC layers. In the MP -BSR in accordance with one or more embodiments of the invention, the buffer size information may take different formats (e.g. the information included in the MP -BSR may comprise different information) as it is depicted in the figures 5-7 with one or more subfields included in fields 405, 405.

The MP -BSR may have the same triggering conditions as a Uu-BSR detailed in TS 38.321 based on higher priority UL data available at MAC entity or after time expiry (e.g. after expiry of a certain time). However, for MP -BSR (e.g. generating and sending a MP -BSR), a new triggering related to the data split mode can be added. The PDCP entity 302 may detect the need of data split based on gNB’s configuration (e.g. for a MP bearer) or based on the remote UE’s proper algorithm (e.g. an algorithm provided at the UE 113), and may then indicate the data split mode for this MP bearer to the MAC entities (307, 308 or 309) through the corresponding logical channel. The MAC entity (307, 308 or 309) aware of the data split mode for the MP bearer may then trigger a MP -BSR 400 for the indicated data volume from PDCP entity 302 and the RLC entities 304, 306.

Figure 5-7 are schematic diagrams illustrating example formats of a buffer size information field within a multipath BSR (e.g. figures 5-7 illustrate examples of the different information that may be included in a MP -BSR) in accordance with one or more embodiments of the invention;

The buffer size information field 404 or 405 may be divided into one or more different subfields representing different data volumes for a same logical channel group. The buffer size information in field 404 or 405 of a MP-BSR may include all or part of the following information, for example in subfields:

- PDCP data volume: The MAC entity may indicate separately the PDCP data volume in a subfield of the buffer size information field. This subfield may refer to the PDCP data volume of all MP bearers in a data split mode within the same logical channel group. In other words, the information included in the MP-BSR may include PDCP data volume information for all MP bearers in a data split mode within the same logical channel group. In another example, this subfield may refer to the PDCP data volume of one MP bearer in a data split mode.

For example, the PDCP entity 302 may indicate the PDCP data volume to the MAC entity associated with a default (or primary) RLC entity as detailed previously in figure 4. Thus, the PDCP data volume received by the gNB 101 is the exact data volume to be split for a MP bearer. The default or primary RLC entity 304 may be configured on Uu direct link for the MP bearer. Therefore, a MP bearer configured by the gNB 101 with a primary Uu RLC entity 304 may indicate the PDCP data volume to the Uu MAC entity (308 or 309).

In another example, the PDCP entity 302 may indicate the PDCP data volume to both MAC entities (307, 308 or 309) associated with the two RLC entities (304 and 306). In this case, the PDCP data volume indicated in the buffer size is reported twice. While reporting separately the PDCP data volume in subfields for the two RLC entities (304, 306), the gNB 101 may take into consideration the double reporting of this data volume (e.g. because the PDCP data volume is reported in two subfields) and allocate the exact resources accordingly.

- Uu RLC data volume: This subfield may indicate the Uu RLC data volume in the Uu RLC entity 304 of the MP bearer 301. A MP bearer may need to report separately the PDCP data volume and the RLC data volume. Thus, this subfield is associated to a PDCP data volume reporting.

- PC5 RLC data volume: This subfield may indicate the PC5 RLC data volume in the PC5 RLC entity 306 of the MP bearer 301. A MP bearer may need to report separately the PDCP data volume and the RLC data volume. Thus, this subfield is associated to a PDCP data volume reporting.

- Destination index: This subfield is proper to the indirect path and may be indicated when reporting the PC5 RLC data volume and/or the PC5 data volume. As specified in the TS 38.321, the Destination Index field identifies the destination. The value is set to one index corresponding to SL destination identity associated to the same destination reported in sl-TxResourceReqList, sl-TxResourceReqListDisc and sl- TxResourceReqListCommRelay, if present. In an example, the destination index may include the relay UE ID 110 in the TxResourceReqListCommRelay for MP data bearer.

- Uu data volume: This subfield may include the total amount of PDCP data volume and Uu RLC data volume on the Uu direct leg (e.g. for the direct path). This subfield may be used to report the Uu data volume when data is non or not split for MP bearer wherein the default or primary RLC entity (e.g. Uu RLC entity 304 when the direct path is the primary path) is configured on the Uu direct leg. The Uu data volume may report also the data volume of a direct bearer in this subfield.

- PC5 data volume: This subfield may include the total amount of PDCP data volume and PC5 RLC data volume on the indirect leg. This subfield may be used to report the PC5 data volume when data is non or not split for MP bearer wherein the default or primary RLC entity is configured on the indirect leg (e.g. for the indirect path). The PC5 data volume may report also the data volume of an indirect bearer in this subfield.

These buffer size information examples in figures 5-7 may use all or parts of the buffer size information’s subfields listed above.

The buffer size information represented in figure 5 shows the structure of a buffer size information field 404 (or 405) for a MP-BSR with two subfields 501 and 502.

The need to report separately the PDCP data volume and the RLC data volume is mainly addressed for MP bearers in a data split mode. Thus, the buffer size information in figure 5 may just report the buffer status of the MP bearer 301 on Uu direct link in a data split mode.

In an example, the MP-BSR with sub-buffer size information included in two subfields may provide the PDCP data volume and the Uu RLC data volume of the MP bearer 301 in data split mode on Uu direct link (113b) for the case where there are two paths including a direct path. The Uu MAC entity (308 or 309) may separate the two data volumes in two separate buffer size information subfields 501 and 502 illustrated in figure 5.

The LCG ID in 401 may refer to the LCG on Uu direct link. This Uu-LCG may include MP bearers’ logical channels and Uu direct bearers’ logical channels. In the MP-BSR format reporting only MP bearers, the Uu-LCG ID in 401 may represent only the group of logical channels of MP bearers. Otherwise, the LCG ID in 401 may refer to new multipath logical channel group (MP -LCG) ID mentioned previously and dedicated only for a group of logical channels of MP bearers. In another example, the MP-BSR with sub-buffer size information included in two subfields may provide the PDCP data volume and the Uu data volume of the MP bearer 301 with primary RLC entity on Uu direct link (113b) or a Uu direct bearer. The Table 4 below indicates different combinations of two buffer size information subfields for each bearer type.

In case of MP bearer in a data split mode, the PDCP data volume is reported in subfield 501 and the Uu data volume is reported in subfield 502 in the buffer size information 404 of the MP-BSR 400. Thus, the subfield 502 may include a total amount of PDCP data volume and Uu RLC data volume. As the PDCP data volume is already indicated in subfield 501, the Uu RLC data volume may be extracted from the date volume indicated in subfield 502. The PC5 RLC data volume is reported in a SL-BSR separately.

In case of MP bearer in a non-data split mode with configured primary RLC entity on Uu direct link, or a Uu direct bearer, the PDCP PDUs are submitted directly to the Uu RLC entity (e.g. Uu RLC entity 304) and thus, the buffer size information field 404 may indicate in subfield 501 an empty subfield or a value corresponding to the non-presence of PDCP data volume (e.g., null value). The Uu data volume in subfield 502 indicates the total amount of PDCP data volume and Uu RLC data volume.

In other words, if the PDPC data volume in subfield 501 is present in the reported MP- BSR, the gNB 101 may detect a resource request for an MP bearer in a data split mode. Else, and for a null value in subfield 501, the gNB 101 may consider a MP bearer in a non-data split mode or a Uu direct bearer. This example of MP-BSR may replace the BSR specified in TS 38.321, clause 6.1.3.1 while amending the buffer size information field to address the need for reporting additionally the MP bearers’ data volume.

Table 4

The Table 4 represents the use of the two subfields 501 and 502 for different bearers’ types at Uu hop. An ‘X’ in the box indicates the subfield is used for the particular bearer type and for a MP bearer whether the MP bearer is in a data split mode or non-data split mode.

The LCG ID in field 401 may refer to the LCG on Uu direct link. This Uu-LCG may include MP bearers’ logical channels and Uu direct bearers’ logical channels. In the MP-BSR format reporting only MP bearers, the Uu-LCG ID in field 401 may represent only the logical channels of MP bearers. Otherwise, the LCG ID in field 401 may refer to new multipath logical channel group (MP -LCG) ID mentioned previously and dedicated only for a group of logical channels of MP bearers.

In both examples, the PC5 RLC data volume of the MP bearer 301 in a data split mode may be indicated to the PC5 MAC entity (307 or 309) and included in the SL-BSR reported also to the gNB 101. In this case, the gNB 101 may receive the MP-BSR and the SL-BSR. Knowing the LCIDs corresponding to the MP bearer 301, the gNB 101 may identify the different data volumes corresponding to the PDCP 302, Uu RLC 304 and PC5 RLC 306 entities.

In case the PDCP data volume is indicated to the both MAC entities of Uu and PC5 legs and thus, the PDCP data volume may be reported in the MP-BSR 400 and in the SL-BSR. As the gNB 101 has the information of the PDCP data volume separately from the information in subfield 501 of the buffer size information field (404 or 405) described with reference to figure 5, the gNB 101 may then extract the exact PC5 RLC data volume from the total amount of data volume reported in the SL-BSR.

The buffer size information provided in the subfields 501 and 502 of figure 5 may indicate the data volume on the Uu leg for a MP bearer and/or Uu direct bearer. The MP-BSR in this case may reflect the exact data volume on the Uu direct leg while reporting separately the data volumes of PDCP layer and the Uu RLC layer for a MP bearer in a data split mode. The gNB 101 may then receive MP-BSR 400 and is able to distinguish the required PDCP data volume for MP bearers in a data split mode and allocate resources accordingly while taking into consideration the radio channel conditions (e.g. communication conditions). For example, if the Uu direct link 113b shows better radio conditions with less demand on Uu grant, the gNB may allocate the PDCP data volume to be sent in preference on the Uu direct link 113b.

The buffer size information represented in figure 6 shows the structure of a buffer size information field 404 (or 405) for a MP-BSR with three subfields 601, 602 and 603.

The need to report separately the PDCP data volume and the RLC data volume is mainly addressed for MP bearers in a data split mode. Thus, the buffer size information in figure 6 may just report the buffer status of the MP bearer 301 either in data split mode or non-data split mode.

The MP-BSR with 3 subfields for the buffer size information may provide different combinations not restricted to the following examples.

In a first example, the MP-BSR 400 may report only the data volume for MP bearers. The buffer size information field 404 (or 405) may include the three following subfields for the case where there are two paths, a direct and indirect path: the PDCP data volume in 601, the Uu RLC data volume in 602 and the PC5 RLC data volume in 603. The Table 5 below indicates different combinations of buffer size information subfields for a MP bearer type.

For MP bearer in a data split mode, the buffer size information included in field 404 may contain sub-buffer size information indicating the data volumes corresponding to the MP bearers within the logical channel group ID indicated in field 401, for example in subfields as follows: the PDCP data volume in subfield 601, the Uu RLC data volume in subfield 602 and the PC5 RLC data volume in subfield 603. The gNB 101 receiving the MP-BSR with the subbuffer size information included in the three subfields 601-603 may allocate the Uu RLC data volume and the PC 5 RLC data volume on the direct and indirect paths respectively. Regarding the PDCP data volume, based on the information provided in the MP-BSR, the gNB 101 may allocate resources according to the channel occupancy and the channel radio conditions (e.g. the communication conditions).

For a non-data split mode, the PDCP PDUs are submitted to a primary path configured for each MP bearer. In case of a primary Uu RLC entity, the PDCP PDUs will be submitted to the Uu RLC entities (such as Uu RLC entity 304) and thus, the MP-BSR may indicate the PDCP data volume and the Uu RLC data volume in subfields 601 and 602 respectively. The PC5 RLC data volume for this MP bearer in subfield 603 is set to null. In case of primary PC5 RLC entity, the Uu RLC data volume subfield 602 is not reported or set to null while the PDCP data volume and the PC5 RLC data volume are indicated in subfields 601 and 603. The Table 5 summarizes the different use cases for MP bearers, where an ‘X’ in the box indicates the subfield is used for the particular bearer type and for a MP bearer in the non-data split mode, depending on which RLC entity is the primary RLC entity.

Table 5

This combination of data volumes for a MP bearer may be considered as sufficient to report their data volume in a separate BSR format dedicated to this type of bearers. In this format, the MP bearers’ data volumes are not combined with direct and indirect bearers’ data volume. Thus, this MP-BSR format may allow the remote UE to deal separately with MP bearers and their associated RLC and MAC entities. Thus, the remote UE 113 may have three types of BSR:

- Uu-BSR to report the Uu direct bearer, such as the BSR specified in TS 38.321, clause 6.1.3.1;

SL-BSR to report the indirect bearers, such as the BSR specified in TS 38.321, clause 6.1.3.33;

- MP-BSR to report separately the MP bearers.

In a second example the MP-BSR 400 may report the data volume for MP bearers and Uu direct bearers. The buffer size information included in field 404 (or 405) may include the following sub-buffer size information, for example in three subfields: the PDCP data volume in subfield 601, the Uu RLC data volume in subfield 602 and the Uu data volume in subfield 603. The Table 6 below indicates the presence of different combinations for MP bearers and Uu direct bearers.

For MP bearer in a data split mode, the buffer size information included in field 404 may include the data volumes corresponding to the MP bearers within the logical channel group ID indicated in field 401 as follows: the PDCP data volume in subfield 601 and the Uu RLC data volume in subfield 602. The Uu data volume is not reported or set to null. The PC5 RLC data volume of the MP bearer is reported in a SL-BSR. The gNB 101 receiving the MP-BSR and the SL-BSR may detect a data split case with a Uu RLC data volume and PC5 RLC data volume to be allocated on direct and indirect paths respectively. The PDCP data volume reported in subfield 601 may have resource grant on a single path or both paths depending on the channel occupancy and the channel radio conditions. Thus, the allocation of the resources will be determined by the gNB 101 based on the PDCP data volume reported and on the communication conditions.

For a MP bearer in a non-data split case, the total amount of data volume may be configured to be reported on a single path, e.g., Uu direct path. Thus, the total amount of PDCP data volume and Uu RLC data volume are reported as Uu data volume in subfield 603 of the MP-BSR. The buffer size information subfields 601 and 602 are not reported or null. Similarly, the Uu direct bearer may report its total data volume in the Uu data volume subfield 603 of the buffer size information.

The Table 6 summarizes the three subfields example for different bearers on Uu direct path, where an ‘X’ in the box indicates the subfield is used for the particular bearer type and whether the MP bearer is in a data split mode or non-data split mode.

Table 6

In a third example, the buffer size information field 404 (or 405) may include the following information: the PDCP data volume in subfield 601, the Uu data volume in subfield 602 and the PC5 data volume in subfield 603. This MP-BSR may serve to request resources for both MP bearers and Uu direct bearers.

For a MP bearer in a data split mode, the PDCP data volume may be indicated in subfield 601, the Uu RLC data volume may be indicated in subfield 602 as part of the Uu data volume and the PC5 RLC data volume in subfield 603 as part of the PC5 data volume. The gNB 101 receiving the MP-BSR with such information may detect a PDCP data volume in subfield 601 and may conclude that the sub-buffer size information in subfields 602 and 603 may indicate the Uu RLC data volume and the PC5 RLC data volume.

In another way to report the Uu RLC data volume and the PC5 RLC data volume of the MP bearer in a data split mode, the Uu data volume may represent the total amount of data volume at Uu leg which is equal to the total amount of PDPC data volume and Uu RLC data volume. Similarly, the PC5 data volume may represent the total amount of data volume at PC5 leg which is equal to the total amount of PDCP data volume and PC5 RLC data volume. The gNB 101 receiving the MP-BSR with such information may extract the exact Uu RLC data volume and PC5 RLC data volume based on the reported PDCP data volume in subfield 601.

For MP bearer in non-data split mode, the Uu data volume (PDCP data volume + Uu RLC data volume) is reported in subfield 602 in case of the MP bearer being configured with a primary Uu RLC entity. The subfields 601, 603 may not be reported or null. On the other side, in case PC5 RLC entity is configured as the primary entity of the MP bearer, thus, the PC5 data volume is reported as the total amount of PDCP data volume and PC5 RLC data volume in subfield 603 while the subfields 601 and 602 may not be reported or null.

For Uu direct bearers, the Uu data volume may report the total amount of PDCP data volume and Uu RLC data volume in subfield 602. The other subfields may then not be reported or null. The Table 7 below may indicate the presence of different data volumes for each bearer type, where an ‘X’ in the box indicates the subfield is used for the particular bearer type and for a MP bearer in the non-data split mode, depending on which RLC entity is the primary RLC entity.

Table 7

The second and third examples described above may allow the UE 113 to report in a single MP-BSR, the MP bearers and the Uu direct bearers. The combination of information provided in the MP-BSR according to the third example may even report all the data volumes in PDCP and RLC entities for MP bearers in addition to the buffer size information for a Uu direct bearer. In these examples, the Uu-BSR may not be used separately as the MP-BSR reports the total buffer size information at Uu direct leg for multipath relaying. Thus, the remote UE may report the MP-BSR for Uu leg resource request and the SL-BSR for indirect resource request.

The buffer size information included in the three subfields may not be limited to the three combinations above. Other combinations in figure 6 from the six listed subfields may be considered.

Furthermore, the PDCP entity 302 in case of data split may indicate the PDCP data volume to both MAC entities (307, 308 or 309) associated with the RLC entities (304 and 306). Thus, the PDCP data volume may be reported twice. As the gNB is able to access separately the information indicating the PDCP data volume (e.g. in the subfields of figures 5-7) for data split case, the exact PDCP data volume can be determined and resources may be allocated for PDCP PDUs accordingly.

In this MP-BSR format, the LCG ID in fields 401, 402 and 403 may refer to a Uu-LCG ID or a SL-LCG ID as the subfields 602 and 603 includes the RLC data volumes of their corresponding logical channels. The fields 401, 402, 403 may include MP -LCG ID proper to MP bearers configured by the gNB 101. The buffer size information represented in figure 7 shows the structure of a buffer size information field 404 (or 405) for a MP-BSR with six subfields 701-706. The buffer size information filed 404 (or 405) may include all or part of the six subfields 701-706 listed above.

In a first example, the buffer size information may be limited to information included in four subfields as follows: the PDCP data volume in subfield 701, the Uu RLC data volume in subfield 702, the destination index in subfield 703 and the PC5 RLC data volume in subfield 704. The Table 8 below indicates the presence of different data volumes for each bearer type.

For MP bearer in a data split mode, all four subfields 701-704 are reported. Thus, the gNB 101 on receiving a MP-BRS with all four subfields 701-704 may conclude the presence of a data split mode in one logical channel of the logical channel group.

For MP bearer in a non-data split mode, the PDCP data volume in subfield 701 is reported. The RLC data volume of the primary RLC entity of the MP bearer is also reported. If Uu primary RLC entity, then the Uu RLC data volume is reported in subfield 702 while subfields 703 and 704 are not reported or set to null. If PC5 primary RLC entity, the destination index and the PC5 RLC data volume are reported in subfields 703 and 704 respectively, while the Uu RLC data volume in subfield 702 is not reported or null.

The Uu direct bearers and the indirect bearers may also be reported in the 4 subfields buffer size information. The Uu direct bearers may report the PDCP data volume in subfield 701 and the Uu RLC data volume in subfield 702. The indirect bearers may report the PDCP data volume in subfield 701, the destination index in subfield 703 and the PC5 RLC data volume in subfield 704.

This type of MP-BSR may replace any other type of BSR for multipath relaying. The Uu-BSR and the SL-BSR may not be needed to be reported as their buffer size information may be reported in the MP-BSR. The Table 8 summarizes the subfields use for different bearers types in a multipath relaying, where an ‘X’ in the box indicates the subfield is used for the particular bearer type and for a MP bearer in the non-data split mode, depending on which RLC entity is the primary RLC entity.

Table 8

In a second example, wherein the six subfields are reported, the Table 9 below represents the content of every subfield for a bearer type, where an ‘X’ in the box indicates the subfield is used for the particular bearer type and for a MP bearer in the non-data split mode, depending on which RLC entity is the primary RLC entity.

Table 9 As referred to the Table 9, the X represents the buffer size information subfields reported for a bearer type in the 6 subfields buffer size information of a MP-BSR. For a MP bearer in a non-data split mode with Uu primary RLC entity, the MAC entity may report either the PDCP data volume and the Uu RLC data volume in the subfields 701 and 702 or the Uu data volume in subfield 705 as the total amount of data volumes at PDCP and Uu RLC entities. Similarly for a MP split bearer in a non-data split mode with PC5 RLC entity, the MAC entity may report either the PDCP data volume in subfield 701, and the PC5 RLC data volume in subfield 704 or the PC5 data volume in subfield 706 as the total amount of PDCP and PC5 RLC data volumes. In both cases, the destination index is reported in subfield 703.

This MP-BSR extended buffer size information format may also report all data volumes for all bearer types within a multipath relaying system with additional subfields.

In all the examples detailed previously, the buffer size information in the MP-BSR may change from two subfields to six subfields allowing the reporting of only MP bearers’ buffer size information or all or part of other bearer’ s types. In other words, the buffer size information included in the MP-BSR can be varied depending on the bearer type being reported (e.g. from information provided in two subfields up to information provided in six subfields) and as such the format of the described MP-BSR allows one MP-BSR to report buffer size information for any bearer type within a multipath relaying systems. Such a MP-BSR provides an efficient and flexible means for reporting buffer size information to the network. If multiple MP-BSR formats are used for multipath relaying, each MP-BSR format with a different combination of the subfields in the buffer size (figures 5-7) is reported in a MAC-CE. This MP-BSR MAC- CE may need to be identified at the gNB 101 in order to identify the number and the type of the subfields included in the buffer size (404 or 405). For example, a MP-BSR MAC-CE with three subfields buffer size (e.g., reporting the PCDP data volume, the Uu RLC data volume and the PC5 RLC data volume) should be able to be distinguished by the gNB from a MP-BSR MAC-CE with two subfields buffer size (e.g., reporting the PDCP data volume and the Uu RLC data volume). Thus, the MP-BSR MAC-CE may have to include different LCID/eLCID for each MP-BSR MAC-CE format. For example, MP-BSR may define more than one buffer size format with different subfields number and types as detailed in figure 5-7. Each of these formats may need to be identified at the gNB 101 and thus, their corresponding MP-BSR MAC- CE may need to be specified with a LCID/eLCID identifier similar to that described above with reference to Table 3.

With the introduction of a MP-BSR sent to the gNB 101 as described, the exact PDCP data volume to be transmitted over the at least two paths can be reported to the network so that the gNB 101 can allocate resources that are needed and allocation of unnecessary resources can be avoided. Furthermore, with the information provided for the volume of PDCP data to be transmitted in the MP-BSR reports as described above, the gNB 101 can determine how the data is to be split across the at least two paths. Since the gNB can determine the radio conditions on the links for the direct and indirect paths (e.g. through measurement reports received at the base station), the gNB 101 is aware of the radio conditions and can dynamically distribute the load (e.g. PDCP data) among the at least two paths taking into consideration the load in each path and the radio conditions over all the links in each of the paths. The MP-BSR may also function to allow the base station 101 to allocate resources that are needed and allocation of unnecessary resources can be avoided but without reporting the exact PDCP data volume to the network. For example, in the case of data split mode with a primary path and secondary path, the PDCP data volume in a data split mode can be indicated to the MAC entity(s) for the primary path and the split secondary path(s) with a data split flag indicating the data is to be split over the two paths. The MAC entity (of the primary path) may then report in the MP-BSR the indicated PDCP data volume (e.g. PDCP data volume over both paths) while ignoring (i.e. not including in a BSR) other indications of the PDCP data volume received by other MAC entities (e.g. of the secondary path(s)). Otherwise, the MAC entity may report the total PDCP data volume to the gNB in the PDCP data volume sub-field and then the gNB will be able to retrieve the exact PDCP data volume when data split.

Figure 8 shows a schematic representation of an example wireless communication device (apparatus) in accordance with one or more example embodiments of the present disclosure.

The wireless communication device 800 may preferably be a communication device capable of wireless communication such as a micro-computer or a workstation or a mobile device or a light portable device or a fixed device. The communication device 800 comprises a communication bus 813 to which there are preferably connected:

- a processing unit 811, such as a microprocessor, and denoted CPU in Figure 8. The processing unit 811 may be a single processing unit or processor or may comprise two or more processing units or processors carrying out the processing required for the operation of the communication device 800. The number of processors and the allocation of processing functions to the central processing unit 811 is a matter of design choice for a skilled person;

- memory for storing data and computer programs containing instructions for the operation of the communication device 800. The computer programs may contain a number of different program elements (modules) or sub-routines containing instructions for a variety of operations and for implementing the methods in accordance with one or more embodiments of the invention; and

- at least one communication interface 802 for communicating with other devices or nodes in a wireless communication system, such as a wireless communication system of Figure 1. The at least one communication interface 802 may be connected to a communication network 803, such as a radio access network of the wireless communication system, over which digital data packets or frames or control frames are transmitted. Each of the relay node and the plurality of nodes (e.g. the remote UEs and the network node) of the communication system 100 may comprise such a communication device 800.

The memory may include:

- a read only memory 807, denoted ROM, for storing computer programs for implementing the methods in accordance with one or more embodiments of the invention;

- a random-access memory 812, denoted RAM, for storing the executable code of methods according to one or more embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to one or more embodiments of the invention.

Optionally, the communication device 800 may also include one or more of the following components:

- a data storage means 804 such as a hard disk, for storing computer programs for implementing methods according to one or more embodiments of the invention;

- a disk drive 805 for a disk 806, the disk drive being adapted to read data from the disk 806 or to write data onto said disk;

- a screen 809 for displaying decoded data and/or serving as a graphical interface with the user, by means of a keyboard 810 or any other user input means.

Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 800 or connected to it. The representation of the bus is not limiting and in particular, the processing unit is operable to communicate instructions to any element of the communication device 800 directly or by means of another element of the communication device 800.

The disk 806 may optionally be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk, a USB key or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the communication device, possibly removable and adapted to store one or more programs whose execution enables methods according to embodiments of the invention to be implemented.

The executable code may optionally be stored either in read only memory 807, on the hard disk 804 or on a removable digital medium such as for example a disk 806 as described previously. According to an optional variant, the executable code of the programs can be received by means of the communication network 803, via the interface 802, in order to be stored in one of the storage means of the communication device 800, such as the hard disk 804, before being executed. The processing unit 811 is preferably adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term "processor," as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. Also, the techniques could be fully implemented in one or more circuits or logic elements.

While the present invention has been described with reference to embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the invention, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

In the preceding embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit.

Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non- transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer- readable medium.

By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. A method for managing buffer status reporting for data to be transmitted by a user equipment, UE, to a base station of a communication system supporting sidelink relaying, the method at the UE comprising: determining data to be transmitted is to be split for transmission to the base station over at least two separate paths; sending, to the base station, at least one buffer status report including information for indicating a volume of PDCP data of the data to be transmitted to the base station, wherein the PDCP data is to be transmitted over at least one path of the at least two separate paths.

2. The method of claim 1, wherein sending comprises sending, to the base station, a buffer status report, the buffer status report including information for indicating a total volume of PDCP data associated with a radio bearer to be transmitted to the base station.

3. The method of claim 1, wherein sending comprises sending, to the base station, a buffer status report associated with a primary path of the at least two separate paths, the buffer status report including information for indicating the volume of PDCP data to be transmitted to the base station and information indicating the data to be transmitted is to be split for transmission over the primary path and a secondary path of the at least two separate paths.

4. The method of claim 1, wherein sending at least one buffer status report comprises sending a first buffer status report including information for indicating the volume of data, including a first part of the PDCP data to be transmitted over a first path of the at least two separate paths and a second buffer status report including information for indicating the volume of data, including a second part of the PDCP data to be transmitted over a second path of the at least two separate paths.

5. The method of claim 4, wherein the information included in the first buffer status report indicates the volume of data to be transmitted over the first path including a volume of the first part of the PDCP data and a volume of RLC data to be transmitted over the first path.

6. The method of claim 4 or claim 5, wherein the information included in the second buffer status report indicates the volume of data to be transmitted over the second path including the volume of the second part of the PDCP data and a volume of RLC data to be transmitted over the second path.

7. The method of claim 1, wherein sending at least one buffer status report comprises sending a first buffer status report including information for indicating the volume of PDCP data to be transmitted to the base station and a volume of RLC data to be transmitted over a first path of the at least two separate paths and a second buffer status report including information for indicating a volume of RLC data to be transmitted over a second path of the at least two separate paths, the second buffer status report not including information for indicating the volume of PDCP data to be transmitted.

8. The method of claim 1, wherein sending at least one buffer status report comprises sending a multi-path buffer status report including PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station, a first buffer status report including information for indicating the volume of data, including RLC data to be transmitted over a first path of the at least two separate paths and a second buffer status report including information for indicating the volume of data, including RLC data to be transmitted over a second path of the at least two separate paths.

9. The method of claim 1, wherein sending at least one buffer status report comprises sending a multi-path buffer status report including PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station and RLC information for indicating a volume of RLC data to be transmitted over a first path of the two separate paths.

10. The method of claim 9, wherein sending at least one buffer status report further comprises sending the multi-path buffer status report and a buffer status report for a second path of the two separate paths, wherein the buffer status report for the second path includes RLC information for indicating a volume of RLC data to be transmitted over the second path.

11. The method of claim 10, wherein the buffer status report for the second path includes the PDCP data volume information representing a volume of the PDCP data to be transmitted.

12. The method of claim 1, wherein sending at least one buffer status report comprises sending a multi-path buffer status report including PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station and RLC information for indicating a volume of RLC data to be transmitted over a first path of the two separate paths and RLC information for indicating a volume of RLC data to be transmitted over a second path of the two separate paths.

13. The method of claim 1, wherein sending at least one buffer status report comprises sending a multi-path buffer status report including:

PDCP data volume information for a radio bearer representing a volume of the PDCP data associated with the radio bearer to be transmitted to the base station, the PDCP data to be transmitted over the at least two separate paths, and RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted to the base station over a first path of the two separate paths; data volume information for another radio bearer representing the volume of PDCP data of the another radio bearer to be transmitted to the base station, and a volume of RLC data of the another radio bearer to be transmitted to the base station, the PDCP data to be transmitted over at least one of the at least two separate paths and the RLC data to be transmitted over a first path of the two separate paths.

14. The method of claim 13, wherein the radio bearer and the another radio bearer are multipath radio bearers.

15. The method of claim 13, wherein the radio bearer and the another radio bearer are multipath radio bearers.

16. The method of clam 13, wherein the radio bearer is a multipath radio bearer and the another radio bearer is a single path radio bearer.

17. The method of any one of claims 13 to 16, wherein the data volume information includes RLC volume information indicating the volume of RLC data and PDCP volume information indicating the volume of PDCP data or the data volume information includes total volume information indicating the total volume of the RLC data and the PDCP data.

18. The method of any one of claims 13 to 16, wherein the data volume information includes RLC volume information indicating the volume of RLC data of a single path or the data volume information includes total volume information including PDCP data volume of the single path.

19. The method of any one of the preceding claims, wherein determining data to be transmitted is to be split for transmission over two separate paths comprises determining data to be transmitted is to be split for transmission over two separate paths after determining a volume of data to be transmitted to the base station exceeds a threshold.

20. The method of any one of the preceding claims, further comprising dividing PDCP data to be transmitted into a first part of the PDCP data to be transmitted over a first path of the at least two separate paths and second part of the PDCP data to be transmitted over a second path of the at least two separate paths.

21. The method of claim 20, wherein dividing the PDCP data comprises dividing PDCP data to be transmitted into the first part of the PDCP data to be transmitted over the first path and the second part of the PDCP data to be transmitted over the second path based on configuration information provided to the UE by the network.

22. The method of any one of the preceding claims, wherein a first path of the at least two separate paths is a direct path between the UE and a base station of the network and a second path of the at least two separate paths is an indirect path between the UE and a base station of the network via a relay node.

23. The method of any one of the preceding claims, wherein determining data to be transmitted is to be split for transmission to the base station over at least two separate paths, comprises determining, by a PDCP entity of the UE, data is to be split for transmission over at least two separate paths, the method further comprising: indicating, by the PDCP entity to a MAC entity of the UE associated with a path of the at least two separate paths, the volume of the PDCP data to be transmitted to the base station, wherein sending at least one buffer status report comprises sending a buffer status report associated with the path of the at least two separate paths including the volume of the PDCP data indicated to the MAC entity.

24. The method of any one of the preceding claims, wherein determining data to be transmitted is to be split for transmission to the base station over at least two separate paths, comprises determining, by a PDCP entity of the UE, data is to be split for transmission over at least two separate paths, the method further comprising: indicating, by the PDCP entity to one or more MAC entities of the UE associated with the at least two separate paths, the volume of the PDCP data to be transmitted to the base station; wherein sending at least one buffer status report comprises sending a buffer status report including the volume of the PDCP data indicated to the one or more MAC entities or comprises sending buffer status reports associated with the at least two separate paths, each of the buffer status reports including the volume of the PDCP data indicated to the one or more MAC entities.

25. A method for managing buffer status reporting for data to be transmitted by a user equipment, UE, to a base station of a communication system supporting sidelink relaying where the UE can communicate with the base station over at least two separate paths, the method at the UE comprising: determining data associated with a radio bearer to be transmitted is to be transmitted to the base station over the at least two separate paths; sending, to the base station, a multi-path buffer status report including PDCP data volume information representing a volume of PDCP data associated with the radio bearer to be transmitted to the base station.

26. The method of claim 25, wherein the multi-path buffer status report includes PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station over a first path of the at least two separate paths, the method further comprising sending, to the base station, a first buffer status report including information for indicating the volume of data, including RLC data associated with the radio bearer to be transmitted over the first path of the at least two separate paths and a second buffer status report including information for indicating the volume of data, including RLC data associated with the radio bearer to be transmitted over a second path of the at least two separate paths.

27. The method of claim 25, wherein the multi-path buffer status report includes PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station over a first path of the at least two separate paths and RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted over the first path of the two separate paths.

28. The method of claim 27, further comprising sending a buffer status report for a second path of the two separate paths, wherein the buffer status report for the second path includes RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted over the second path.

29. The method of claim 25, wherein the multi-path buffer status report includes PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station over a first path of the at least two separate paths, RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted over the first path of the two separate paths and RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted over a second path of the two separate paths.

30. The method of claim 25, wherein the multi-path buffer status report includes:

PDCP data volume information for a radio bearer representing a volume of the PDCP data associated with the radio bearer to be transmitted to the base station, the PDCP data to be transmitted over at least one of the at least two separate paths, and RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted to the base station over a first path of the two separate paths; data volume information for another radio bearer representing the volume of PDCP data of the another radio bearer to be transmitted to the base station, and a volume of RLC data of the another radio bearer to be transmitted to the base station, the PDCP data to be transmitted over at least one of the at least two separate paths and RLC data to be transmitted over a first path of the two separate paths.

31. The method of claim 30, wherein the radio bearer and the another radio bearer are multipath radio bearers.

32. The method of claim 30, wherein the radio bearer and the another radio bearer are multipath radio bearers.

33. The method of claim 30, wherein the radio bearer is a multipath radio bearer and the another radio bearer is a single path radio bearer.

34. The method of any one of claims 30 to 33, wherein the data volume information includes RLC volume information indicating the volume of RLC data and PDCP volume information indicating the volume of PDCP data or the data volume information includes total volume information indicating the total volume of the RLC data and the PDCP data.

35. The method of any one of claims 30 to 33, wherein the data volume information includes RLC volume information indicating the volume of RLC data of a single path of the at least two separate paths or the data volume information includes total volume information including PDCP data volume of a single path of the at least two separate paths.

36. A method for managing resource allocation for data to be transmitted by a user equipment, UE, to a base station of a communication system supporting sidelink relaying where the UE can communicate with the base station over at least two separate paths, the method at the base station comprising: receiving, from the UE, a multi-path buffer status report including PDCP data volume information representing a volume of PDCP data of data associated with a radio bearer to be transmitted to the base station, wherein the data associated with the radio bearer to be transmitted is to be transmitted to the base station over the at least two separate paths; determining communication conditions over the at least two separate paths; determining an allocation of the volume of PDCP data to at least one path of the at least two separate paths based on the determined communication conditions; sending, to the UE, resource allocation information indicating the resources allocated for the transmission of data associated with the radio bearer to the base station based on the determined allocation of the volume of PDCP data.

37. The method of claim 36, wherein the communication conditions include at least one of: radio conditions over each of the at least two separate paths; and load in each of the at least two separate paths.

38. The method of claim 36, wherein the multi-path buffer status report includes PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station over a first path of the at least two separate paths, the method further comprising sending, to the base station, a first buffer status report including information for indicating the volume of data, including RLC data associated with the radio bearer to be transmitted over the first path of the at least two separate paths and a second buffer status report including information for indicating the volume of data, including RLC data associated with the radio bearer to be transmitted over a second path of the at least two separate paths.

39. The method of claim 36, wherein the multi-path buffer status report includes PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station over a first path of the at least two separate paths and RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted over the first path of the two separate paths.

40. The method of claim 39, further comprising sending a buffer status report for a second path of the two separate paths, wherein the buffer status report for the second path includes RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted over the second path.

41. The method of claim 36, wherein the multi-path buffer status report includes PDCP data volume information representing a volume of the PDCP data to be transmitted to the base station over a first path of the at least two separate paths, RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted over the first path of the two separate paths and RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted over a second path of the two separate paths.

42. The method of claim 36, wherein sending the multi-path buffer status report includes: PDCP data volume information for a radio bearer representing a volume of the PDCP data associated with the radio bearer to be transmitted to the base station, the PDCP data to be transmitted over the at least two separate paths, and RLC information for indicating a volume of RLC data associated with the radio bearer to be transmitted to the base station over a first path of the two separate paths; data volume information for another radio bearer representing the volume of PDCP data of the another radio bearer to be transmitted to the base station, and a volume of RLC data of the another radio bearer to be transmitted to the base station, the PDCP data and RLC data to be transmitted over a first path of the two separate paths.

43. The method of claim 42, wherein the radio bearer and the another radio bearer are multipath radio bearers.

44. The method of claim 42, wherein the radio bearer and the another radio bearer are multipath radio bearers.

45. The method of claim 42, wherein the radio bearer is a multipath radio bearer and the another radio bearer is a single path radio bearer.

46. The method of any one of claims 42 to 45, wherein the data volume information includes RLC volume information indicating the volume of RLC data and PDCP volume information indicating the volume of PDCP data or the data volume information includes total volume information indicating the total volume of the RLC data and the PDCP data.

47. The method of any one of claims 42 to 45, wherein the data volume information includes RLC volume information indicating the volume of RLC data of a single path or the data volume information includes total volume information including PDCP data volume of the single path.

48. An apparatus for a User Equipment, comprising: one or more processing units configured to perform the method as recited in any one of claims 1 to 35.

49. An apparatus for a base station, comprising: one or more processing units configured to perform the method as recited in any one of claims 36 to 47.

50. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the control method according to any one of claims

1 to 47.

51. A computer-readable medium carrying a computer program according to claim 50.