Signaling radio bearer configuration in a multipath system

Abstract

Methods and apparatus for managing use of Signalling Radio Bearers, SRBs, in a wireless communication system supporting multipath communication and relaying between a User Equipment, UE, and a network including a base station are disclosed. A method performed at the UE comprises: activating a SRB on a first path between the UE and the base station; receiving, from the base station, configuration information for configuring the SRB on a second path between the UE and the base station, the configuration information including triggering event information for indicating one or more triggering events for triggering the use of the SRB on the second path; using the second path for carrying signalling data through the SRB after determining an occurrence of one of the one or more triggering events, wherein the first path is one of a direct path between the UE and the base station and an indirect path including a relay node between the UE and the base station and the second path is one of a direct path and an indirect path.

Description

Field of the Invention The present invention generally relates to managing the use of Signalling Radio Bearers (SRB) in a wireless communication system supporting Multipath (MP) communication and relaying, such as Sidelink (SL) relaying, between User Equipment, UE, and a base station. In particular, the present invention relates to managing the use of SRB on the indirect path at triggering events configured by the network (e.g. a gNB) to handle the control plane in a Multipath transmission system. 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 (WI), 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, 3GPP 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 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 of communication. This multipath relay solution aims to provide applications requiring high Uplink (UL) 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 UEs 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 or End-to-End (E2E) radio bearer (RB) can be a Signaling Radio Bearer (SRB) for control data or a Data Radio Bearer (DRB) for user data. The E2E RB may be assigned to a single path (e.g., direct or indirect path) and thus, it is named a non-split MP radio bearer or a MP non-split bearer. As the remote UE has two paths in a multipath transmission system, the E2E RB may be assigned to both paths and thus, it is called a MP split radio bearer or a MP split bearer. As specified in SLR WI RP-221262 in Release 18, the remote LIE is connected to the same gNB via a direct path and via an indirect path. Thus, the remote UE is configured by the same gNB (intra-gNB) for multipath. The configuration is sent to the remote UE through one of the paths (e.g., direct or indirect paths) using signaling radio bearers (SRB). The SRB may refer to SRB1 or SRB2 in the following description. The SRB1 is more dedicated to carry RRC messages while SRB2 is intended for NAS messages. The SRB2 provides a lower priority than SRB1. In Release 18 SLR Work Item RP-221262, it has been decided that SRB 1 / 2 will be sent mainly on the direct path. Different configuration types for SRB 1 / 2 are allowed in a Multipath transmission system: the non-split and the split configuration types (with or without duplication). The non-split SRB 1 / 2 is normally only allowed on the direct path, and thus, there is no control plane on the indirect path. However, the split SRB 1 / 2 configuration may allow to have duplicated RRC PDUs on both direct and indirect paths if duplication is activated. Furthermore, a split SRB 1 / 2 without duplication may have the RRC PDUs only on the primary path, mainly considered as the direct path in multipath configuration system (e.g. in this case the indirect path is considered as the secondary path). Nevertheless, there are some use cases where the SRB 1 / 2 is needed to be sent through the indirect path. For instance, a direct path failure may lead to an interruption to the signaling flow and in such a case when no signaling can be exchanged between the remote UE and the gNB, it is not possible to send a failure report. Moreover, any momentarily inactivity on the direct path, such as a direct path change or a direct path release, may lead also to disconnection of the signaling flow between the remote UE and the gNB. In this case, the SRB1 and more generally SRB is needed on the enabled second (or active) path (i.e., the indirect path) to ensure the service continuity. In another example, a remote UE may select a relay UE in all RRC states to be used for the indirect path and so for the creation of a multipath transmission system. Thus, a relay UE in IDLE / INACTIVE RRC state may be assigned to the indirect path. When the relay UE is in a non-connected RRC state (e.g. IDLE / INACTIVE RRC state), data cannot be transmitted between the remote UE and the gNB over the indirect path. A dedicated PC5-RRC message has been introduced in the Release 18 to solve this problem, and to act as a trigger to switch the relay UE to a CONNECTED RRC state and to enable the indirect path to be used, but this new trigger is not backward compatible with legacy relay UEs issued according to former Releases prior to Release 18. Thereby, a Release 17 relay UE is not compatible and may not be aware of the new PC5-RRC message. Accordingly, it is desirable to provide new mechanisms which help to control use of the SRB on the direct and / or indirect paths for multipath communication so as to avoid or minimize signaling interruptions or disconnections. Summary In accordance with a first aspect of the present invention, there is provided a method for managing use of Signalling Radio Bearers, SRBs, in a wireless communication system supporting multipath communication and relaying between a User Equipment, UE, and a network including a base station, the method at the UE comprising: activating a SRB on a first path between the UE and the base station; receiving, from the base station, configuration information for configuring the SRB on a second path between the UE and the base station, the configuration information including triggering event information for indicating one or more triggering events for triggering the use of the SRB on the second path; using the second path for carrying signalling data through the SRB after determining an occurrence of one of the one or more triggering events, wherein the first path is one of a direct path between the UE and the base station and an indirect path including a relay node between the UE and the base station and the second path is one of a direct path and an indirect path. In accordance with a second aspect of the present invention, there is provided a method for managing use of Signalling Radio Bearers, SRBs, in a wireless communication system supporting multipath communication and relaying between a User Equipment, UE, and a network including a base station, the method at the base station comprising: sending, to the UE, configuration information for configuring a SRB on a first path between the UE and the base station; sending, to the UE, configuration information for configuring the SRB on a second path between the UE and the base station, the configuration information including triggering event information for indicating one or more triggering events for triggering the use of the SRB on the second path; receiving, from the UE using the second path, signalling data through the SRB, wherein the first path is one of a direct path between the UE and the base station and an indirect path including a relay node between the UE and the base station and the second path is one of a direct path and an indirect path. In accordance with a third aspect of the present invention, there is provided a method for managing multipath communication in a wireless communication system supporting multipath communication and relaying between a User Equipment, UE, and a network including a base station, wherein the UE is connected to the base station via a direct path and wherein an indirect path including a relay node between the UE and the base station is to be established, the method at the relay node comprising: sending, to the UE or the base station, information indicating the relay node is a Release 18 relay node or a relay node of a Release that is higher than Release 18. The information may include information indicating whether the relay node can support a PC5 trigger to enter a RRC connected state. In accordance with a fourth aspect of the present invention, there is provided apparatus for a UE as recited in claim 41 of the accompanying claims. In accordance with a fifth aspect of the present invention, there is provided apparatus for a base station as recited in claim 42 of the accompanying claims. The configuration of the remote UE with a list of triggering events may help the remote UE to control the use of SRB on the second path (which may be a direct or indirect path) for specific usage. For example, in the case where the first path is a direct path configured with a non-split SRB or split SRB without duplication, the remote UE is able to use the indirect path for signalling data (e.g. RRC messages) through or over the SRB after occurrence of a triggering event, and without the need to reconfigure or re-establish the first path (depending the triggering event). Furthermore, the base station may not need to reconfigure, at each triggering event, the SRBs on the second path as the remote UE can configure and control the use of the SRBs based on the one or more triggering events and information included in the configuration information provided before the occurrence of any of the triggering events. For backward compatibility issues (e.g. where the relay node is not identified as a 3GPP Release 18 or later 3GPP Release relay node, such as when the relay node is a Release 17 relay node), the SRB (e.g. SRB1) can be assigned to the second path (which is an indirect path in this case) in response to the remote UE determining a backward compatibility event and the relay UE may be triggered by a RRCConfigurationComplete message or other Release 17 procedure sent by the remote UE through the SRB using the configured indirect path. Thus, the relay node can be triggered by the remote UE to enter the RRC connected state from a nonconnected RRC state even when the relay node is not a 3GPP Release 18 or later relay node. The configuration may further include PDCP information indicating the type of SRB to be used for the SRB on / at or after determining the occurrence of the one of the one or more triggering events. In the case where the activated SRB on the first path is a non-split bearer type of SRB or a split bearer type of SRB without duplication, after determining an occurrence of the one of the one or more triggering events, the remote UE may determine whether to change the type of SRB to be configured on the second path based on the PDCP information. The PDCP information may include at least one of: PDCP duplication configuration information for configuring the UE to activate PDCP duplication after determining an occurrence of the one of the one or more triggering events; PDCP switch configuration information for configuring the UE to switch the SRB to the second path after determining an occurrence of the one of the one or more triggering events; PDCP configuration information for indicating to the UE the type of SRB to be used for the SRB after configuration of the SRB on the second path has been completed or on or after determining the occurrence of the one of the one or more triggering events. The PDCP information enables the base station to control the configuration of the SRB on or after the occurrence of the triggering event and enables the remote UE to know if the configuration for the SRB is to be applied at the triggering event and kept afterwards or is to be applied just at the triggering event and some other configuration for the SRB (which could be the initial configuration on applied on the first path or a new configuration) is to be applied after the triggering event. This provides a flexible solution for configuring SRBs for multipath communication. 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 la 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 lb is a schematic diagram illustrating a typical 5G Proximity-based Services (ProSe) Relay reference architecture; Figure 2 is a schematic diagram illustrating user plane and control plane stacks of some protocol layers involved in Sidelink relay operations for UE-to-network (U2N) based relaying; Figure 3 is a schematic and simplified diagram illustrating example message flows for managing use of SRBs in a wireless communication system supporting multipath communication and relaying in accordance with one or more embodiments of the invention, in an example use case where the SRB1 is used on the indirect path upon direct path inactivity; Figure 4 is a schematic and simplified diagram illustrating example message flows for managing use of SRBs in a wireless communication system supporting multipath communication and relaying in accordance with one or more embodiments of the invention, in an example use case where the SRB 1 is used on the indirect path upon direct path failure; Figure 5 is a schematic and simplified diagram illustrating example message flows for managing use of SRBs in a wireless communication system supporting multipath communication and relaying in accordance with one or more embodiments of the invention, in an example use case where the SRB1 is used on the indirect path for backward compatibility; Figure 6 is a block schematic diagram of an example wireless communication device in accordance with one or more embodiments of the present invention; Figure 7 is a simplified flowchart of a method performed at a UE in accordance with one or more embodiments of the present invention; Figure 8 is a simplified flowchart of a method performed at a base station in accordance with one or more embodiments of the present invention; and Figure 9 is a simplified flowchart of a method performed at a relay node in accordance with one or more embodiments of the present invention. Detailed Description Figure la 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 and multipath communication 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). In the following description reference is made to a wireless communication system 100 capable of supporting Sidelink (SL) relaying where a path between a remote UE and a base station includes a sidelink connection (also known as a PC5 link) between the remote UE and a relay node (also referred to as a relay UE) and a network connection (also known as a Uu link) between the relay UE and the base station. However, it is not intended that the present invention is limited to a PC5 link between the remote UE and the relay UE and could apply to relaying configurations where the link between the remote UE and the relay UE is via another type of connection (e.g. a non-3GPP connection), such as a WiFi or Bluetooth. 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). 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 and multipath communications. With reference to Figure la, UE node 110 is served by network node 106 and may operate as a relay UE node relaying data between the UE node 113 (referred to as a remote UE node) and the network node 106, hence performing UE-to-network (U2N) relay. In an example where the network node 106 is part of a cellular network, the relay UE 110 is served by a cell controlled by the network node 106. The network nodes 106 and 107 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 la only shows the base station of the wireless network for clarity. For a 5G NR network, the network nodes 106 and 107 are referred to as a gNodeB, or gNB. The gNB 106 is split into a Centralized Unit (gNB-CU) 104 and multiple Distributed Units (gNB-Dus), such as gNB-DU1 101 and gNB-DU2 102. The gNB 107 is a non-split base station in the sense that the functions of the Centralized Unit (gNB-CU) and Distributed Unit (gNB-DU) are combined in one entity. In one example, the Centralised Unit gNB-CU (e.g. gNB-CU 104 and gNB-CU of gNB 107) provides support for the higher layers such as SDAP, PDCP and RRC layers while the Distributed Unit gNB-DU (e.g. gNB-DU 101, 102 and gNB-DU of gNB 107) provides support to the lower layers such as MAC and PHY. The gNB-DU may serve different cells. The gNB-CU is connected to the gNB-DU via a Fl interface (e.g. Fl interface 101a and 102a). The gNB-CU may exchange different F1AP messages with the gNB-DU via the Fl interface. For instance, the gNB-CU may configure the UE context at a selected gNB-DU using the UE context management procedures as specified in 3GPP TS 38.473 section 8.3. Furthermore, the gNB-CU may send the RRC messages for the UE in a RRC MESSAGE TRANSFER container to the gNB-DU to be forwarded later to the UE as specified in the TS 38.473, section 8.4. In the following, a relay UE node will also be referred to as a relay node or 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 base station or gNB. In an example shown in Figure la, in a UE-to-Network (or U2N) scenario with the UE 110 operating as a UE-to-Network relay UE, the UE-to-Network relay UE 110 connects the UE 113, operating as a remote UE, to the gNB-DUl 101. The remote UE 113 is connected to the relay UE 110 via or through a link 113a. The link 113a may be referred to as a hop or link or connection or interface or leg 113a. The link 113a may be either a sidelink (PC5 link) or a non-3GPP link (ideal UE-UE connection). The link 113a is used for the relayed traffic of the remote UEs 113 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 to the gNB-DUl 101 through the relay UE 110 with a PC5 / non-3GPP hop 113a and aUu hop 110a. For uplink communication, the remote UE 113 is the source node (or transmitter node for transmitting data) and the gNB-DUl 101 is the destination or target node (or receiver node for receiving data) for a sidelink relay connection established between the remote UE 113 and the gNB-DUl 101 with a PC5 / non-3GPP hop 113a and a second Uu hop 110a. For downlink communication, the remote UE 113 is the destination or target node (or receiver node) and the gNB-DUl 101 is the source node (or transmitter node). The remote UE 113 may be connected to the gNB 106 via multiple paths in a multipath configuration. For instance, the remote UE 113 may be connected to the gNB-DUl 101 via the relay UE 110 and may be connected to the gNB-DU2 102 directly. Thus, the remote UE is connected to the gNB 106 via an indirect path (113a+l 10a) and via a direct path 113b. The gNB-CU 104 may configure the end-to-end multipath radio bearers (E2E RB) between the remote UE and the network using different configuration types. The E2E RB may be assigned to a single path (e.g., direct or indirect path) and thus, in such a case the type of E2E RB is named a non-split MP radio bearer or a MP non-split bearer or non-split bearer. As the remote UE has two paths in a multipath transmission system, the E2E RB may be assigned to both paths and thus, in such a case the type of E2E RB is called a MP split radio bearer or a MP split bearer or split bearer. For a MP split bearer, the PDCP duplication is supported. When duplication is activated, the MP split bearer is referred to as a split bearer with duplication and the RB is activated on both paths. However, when the duplication is deactivated, the MP split bearer is referred to as a split bearer without duplication and it is only activated on one path which is usually the direct path. The different MP radio bearers’ configuration types can be applied to the signalling radio bearers (SRB) and the data radio bearers (DRB). The Signalling Radio Bearers or SRBs are defined as the Radio Bearers (RBs) that are used only for the transmission of signalling (e.g. signalling data), such as for the transmission of RRC and NAS messages, between the remote UE and the network. The SRB split is only supported for SRB1 and SRB2 types in multipath. Referring to TS 38.331, the SRB1 and SRB2 are defined as follows: - SRB1 is for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages prior to the establishment of SRB2, all using DCCH logical channel; - SRB2 is for NAS messages and for RRC messages which include logged measurement information, all using DCCH logical channel. SRB2 has a lower priority than SRB 1 and may be configured by the network after AS security activation. After the set-up of SRB 1 for a UE, the UE can send NAS messages to the core network that are encapsulated in RRC messages over or through SRB 1 to the gNB and sent later to the core network by the gNB. For example, the NAS registration request is encapsulated in the RRC Setup Complete message. NAS messages are sent over SRB2 after SRB2 is established. According to SLR Work Item RP-221262 for Release 18, two multipath scenarios are supported. The link between the relay and the remote UE may be either a PC5 link (scenario 1) or a non-3GPP link (scenario 2). According to RAN2 workgroup, six use cases are specified as path management for scenario 1 to be further studied in Release 18. The uses cases published in R2-2210804, clause 8.9.4, are divided between path addition for indirect and direct paths (Case A and B respectively), path release for indirect and direct paths (case C and D respectively), and path change for direct and indirect (case E and G respectively). Two use cases for indirect path addition (case B) and indirect path release (case D) are supported for scenario 2. In a first example, the remote UE 113 may be connected with a direct path (e.g. via Uu link 113b) and an indirect path via the relay UE 110 (e.g. via PC5 link 113a and Uu link 110a) to the same gNB-DUl 101. The remote UE 113 may perform a direct path change (case E) of path or link 113b to connect to a different gNB-DU2 102 within the same gNB 106 (e.g. change from link 113b to link 113c shown in dotted lines in figure la). The direct path change may include a change of the cell within the same gNB-DU or a change of the gNB-DU within the same gNB. In a second example, the remote UE 113 connected in multipath to the gNB-DU I 101 (113a+l 10a, 113b) may perform handover of its direct path 113b by connecting to a second gNB 107 via the direct path 113d. The handover to the gNB 107 may be performed as an inter-gNB path switch, not illustrated in figure la, where the remote UE 113 connected to the gNB 106 may switch from direct path 113b to an indirect path where the relay UE is connected to the gNB 107. Therefore, the remote UE 113 may have a multipath configuration with two indirect paths where the first relay 110 connects the remote UE to the gNB 106 and the second relay UE connects the remote UE to the gNB 107. Figure lb is a schematic diagram illustrating a typical 5G Proximity-based Services (ProSe) Relay reference architecture. The remote and relay UEs are attached to the core network through their serving gNB which is part of the NG-RAN. Figure lb represents a typical 5G Proximity-based Services (ProSe) Relay reference architecture and shows the different connections between the core network entities of the 5G core (5GC) such as the Access and Mobility Management Function (AMF) entity, the Session Management Function (SMF) entity and the User Plane Function (UPF) entity, the UEs (5G ProSe Remote and 5G ProSe Relay) and the NG-RAN (i e., base station or gNB). The 5G ProSe Remote UE 130 and 5G ProSe Relay 120 may be served by the same or different PLMNs (Public Land Mobile Network). If the serving PLMNs of the 5G Remote UE and the 5G ProSe Relay are different then the NG-RAN is shared by the serving PLMNs. In order to set up a relayed traffic between a first node (remote UE) and a second node (gNB or remote UE), a Sidelink relay architecture may be used 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 that is introduced between the PDCP layer and the RLC 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 201 between its Uu PDCP layer and its PC5 RLC layer. Similarly, the gNB, such as gNB 106, has a Uu SRAP layer 204 between its Uu PDCP layer and its Uu RLC layer. 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 202 is connected to the PC5 SRAP 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 204 at the gNB side 106 through the Uu link 110a. A remote UE 113 establishes End-to-End (E2E) radio bearers 205 with the gNB 106. These radio bearers could be a Signaling Radio Bearer SRB or Data Radio Bearer DRB. Figure 2 shows an E2E Uu DRB between the SDAP layer at the remote UE 113 and the gNB 106 by way of example. An E2E SRB may also be considered between the Uu RRC layer at the remote UE 113 and the gNB 106. 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 Relay RLC channels 206 through the PC5-RLC layer 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 Relay RLC channels 206 to egress Uu Relay RLC channels 207a and / or 207b at Uu link 110a. Thus, a mapping table is required for uplink and it is configured by gNB 106 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 / SRB 205 ID) and an identifier of the ingress PC5 Relay RLC channel (or bearer) 206 and identifies the egress Uu Relay 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 via the PC5-SRAP entity 202. 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. UE ID E2E Uu SRB ID Ingress PC5 Relay RLC channel ID Egress Uu Relay RLC channel ID xl yi zl wl 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 106 arrive at the relay UE 110 through the Uu link 110a. The Uu SRAP layer 203 of the UE-to-Network relay UE 110 receives data or packets (traffic data or signalling) over or via ingress Uu Relay RLC channels 207a and 207b through the Uu-RLC layer from gNB 106 and transmits the packet to the PC5 SRAP entity 202 of the same relay UE 110. Those ingress Uu Relay RLC channels 207a and 207b will be mapped at the PC5 SRAP entity 202 of the relay UE 110 to the egress PC5 Relay RLC channels 206 at PC5 hop 113a. Thus, a mapping table is required for downlink and it is configured by the gNB 106 at PC5 SRAP entity 202 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 Relay RLC channel (or bearer) 207a and 207b ID and identifies the egress PC5 Relay RLC channels (or bearer) 206 ID of the PC5 hop 113a. The End-to-End Radio bearer 205 is then mapped at the PC5 hop 113a to the egress PC5 Relay 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 PC5 SRAP entity 202 via the Uu SRAP entity 203. An example of a downlink mapping table with one entry configured at the PC5 SRAP entity 202 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. UE ID E2E Uu SRB ID Egress PC5 Relay RLC channel ID Ingress Uu RLC Relay channel ID x2 y2 z2 w2 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 106, and vice-versa. To summarize, the transmitting part of each SRAP entity at the UE-to-Network Relay UE 110 receives the data packet with its SRAP header from its corresponding receiving part (receiving part of the SRAP entity 202 forwards the data to the transmitting part of the SRAP entity 203 and vice-versa). The transmitting part of each SRAP entity owns a mapping table configured by the gNB 106 which allows the identification of the egress RLC channel (at Uu or PC5 link) based on the ingress RLC channel where the data packet is received and the UE and Bearer IDs carried in the SRAP header. We can note that specific mapping rules may be applied for SRB0 and SRB1 as specified in TS38.351 and TS38.331. In the case of the multi-path with one indirect and one direct path, the remote UE 113 and the gNB 106 may communicate with each other through both paths. Thereby, either node has two protocol stacks: one for the indirect path such as described above and one for the direct path. The split between the direct and / or the indirect path is performed at the PDCP layer of each node. For the direct path, in the downlink direction, data or packets transmitted from gNB 106 through the direct path arrive at the remote UE 113 via ingress Uu Direct Path RLC channel 208 of the Uu link 113b. On the other hand, in the uplink direction, data or packets transmitted from the remote UE 113 through the direct path arrive at the gNB 106 via ingress Uu Direct Path RLC channel 208 of the Uu link 113b. The E2E radio bearers between the remote UE 113 and the gNB 106 may have different configuration types in a multipath transmission system (e.g. when multipath communication is configured). The gNB 106 may configure the E2E RB 205 as a non-split RB and thus, 205 may be assigned either to the direct path via the link 113c or to the indirect path via the links 113a+110a. In this case, the non-split SRB is activated on a single path within the multipath transmission system. Either the SRB is configured or not on the indirect path. The gNB may configure the mapping table of the SRAP layer of the U2N relay UE (e.g., 110) with E2E SRB 1 / 2 for later use. For instance, the mapping of SRB 1 / 2 may be (pre)configured (e.g. a mapping table with the mapping of SRB 1 / 2 may be preconfigured at the relay UE) and thus, there are (pre)configured ingress PC5 / Uu RLC channels mapped to the E2E SRB 1 / 2 which can be applied by default by the relay UE 110. Otherwise, the gNB may configure the E2E SRB1 / 2 on the relay UE of the indirect path when multipath communication is configured in a multipath configuration system. The E2E RB 205 may also be configured by the gNB 106 as a split bearer as thus, it is assigned to both paths in a multipath transmission system. The split bearer may support duplication and thus, in such a case, the flow is activated on the direct path and the indirect path (e.g. the direct and indirect paths are used to carry data (traffic or signalling) through or over the split radio bearer between the remote UE 113 and the gNB 106). For example, for an E2E split SRB in 205, the signaling flow will be exchanged between the remote UE 113 and the gNB 106 on both paths. This configuration is called split bearer with duplication. In case the duplication is deactivated on the split bearer, the flow is activated mainly on the direct path. For example, for an E2E split SRB in 205 without duplication, the signalling data will be mainly exchanged between the remote UE and the gNB 106 via the direct path. No data flow may be sent on the indirect path. The gNB 106 may configure its remote UE 113 with E2E SRB1 and E2E SRB2 for multipath. The bearer type can be either a non-split SRB on the direct path or a split SRB on both paths. The split SRB may be configured with duplication or without duplication. In case the SRB1 (or SRB2) is configured as a non-split bearer or a split bearer without duplication, the SRB1 (or SRB2) is only active on one path, mostly the direct path. No SRB1 (or SRB2) may be active on the indirect path. Nevertheless, there are some use cases where the RRC messages are required on the indirect path. In a first example, a direct path change may lead the current direct path being inactive in a multipath transmission system until the establishment of a new direct path. Meanwhile, the direct path is suspended and so where SRBs are activated on the direct path, no SRB1 (or SRB2) is available to exchange signaling flow between the remote UE 113 and the gNB 106. In a second example, the direct path release or the direct path failure may switch off the signaling flow at the direct path. The remote UE 113 configured with a non-split SRB 1 / 2 or a split SRB 1 / 2 without duplication (and where SRBs are activated on the direct path) is not able to exchange signaling messages with the network and thus, the control plane is no longer functional for multipath protocol stack represented in figure 2. In a third example, the remote UE 113 may connect to a relay UE (such as relay UE 110) in any RRC state. In order to trigger the relay UE in a non-connected RRC state (e.g. RRC INACTIVE / 1DLE state) to enter the CONNECTED state, a new PC5-RRC message has been introduced in Release 18 which message is sent by the remote UE 113 to the relay UE 110 for multipath. However, a Release 17 relay UE cannot be triggered with Release 18’s new PC5-RRC message and thus, this Release 18 solution for triggering the relay UE to enter the RRCCONNECTED state is not backward compatible. In order to wake up the Release 17 relay UE, a legacy method such as the sending of a RRCReconfigurationComplete message should be used as specified in Release 17. In order for the remote UE 113 to send this RRC message to the relay UE 110, this RRC message should be sent by the remote UE 113 towards the indirect path and thus, there is a need for the signaling bearer SRB1 to be configured also on the indirect path. The figures 3 to 5 represent solutions to the aforementioned problems revealed in the previous examples by assigning the SRB (e.g. SRB 1 / 2) on demand to the indirect path. In other words, by controlling on demand the use of the indirect path for carrying signalling (e.g. signalling data) through or over the SRB (e.g. SRB 1 / 2). The message flows of figure 3 and 4 are compatible with a connection between a relay UE and a remote UE through a PC5 or a non-3 GPP link. In the following description, reference is made to the SRB being activated on a direct path between the remote UE and gNB and after an occurrence of a triggering event being detected or determined, using an indirect path between the remote UE and gNB for carrying signalling data through the SRB. However, it is not intended that the invention is limited to changing the configuration or mapping of the SRB from the direct path to the indirect path. The invention may apply to the case where the SRB is activated on an indirect path between the remote UE and gNB and after an occurrence of a triggering event being detected or determined, using a direct path or a second indirect path between the remote UE and gNB for carrying signalling data through the SRB. In other words, the invention may also apply to changing the configuration or mapping of the SRB from the indirect path to the direct path or a second indirect path. Thus, the SRB may be activated or assigned or configured on a first path between the UE and the base station, where the first path may be one of a direct path and an indirect path for MP communication, and after an occurrence of a triggering event being detected or determined, a second path may be used to carry the signalling data through the SRB, where the second path is one of a direct path and an indirect path for MP communication. Referring now to figure 3 which shows example message flows for managing use of SRBs in a wireless communication system, such as that shown in figure la, supporting multipath communication and relaying, and in particular for managing use of SRB 1 on a second path upon inactivity on a first path in a multipath transmission system in accordance with embodiments of the invention. The following description is for the case where the first path is a direct path and the second path is an indirect path (via a relay node between the UE and the network) by way of example. It will be appreciated that the following description may also apply in the case where the first path is an indirect path and the second path is a direct path or an indirect path.According to this figure 3, the remote UE 113 may be connected to the serving or source gNB 106 (e.g. serving or source gNB-DUl 101) through a first path or direct path (e.g. comprising Uu link 113b) and through a second path or an indirect path (e.g. comprising PC5 link 113a and Uu link 110a) via the relay UE 110. The relay UE 110 may serve as U2N relay UE for relaying data between the remote UE 113 and the source gNB-DUl 101. The message or call flows in 300 represent the different exchanged messages between the remote UE 113, the serving relay UE 110, the serving gNB 106 and the target gNB 107 (in case of inter-gNB handover). The message flows in figure 3 consider the issue of direct path inactivity. By way of example, and not limitation, the direct path inactivity may cover the use cases of direct path change, direct path release, direct path deactivation and inter-gNB handover. The gNB 106 may configure the remote UE 113 to perform a direct path release, a direct path change or an inter-gNB handover. Moreover, the gNB 106 may decide to deactivate the direct path (e.g. if the link quality becomes bad) in a multipath transmission system and rely on the remaining paths to maintain the connection with the network. An indirect path inactivity may refer to the previous use cases such as path change, path release, path deactivation or relay UE (re)selection or handover. In a first example of direct path release, the link 113b connecting the remote UE 113 to the gNB 106 is released and thus, the remote UE 113 remains connected to the network through the indirect path via relay UE 110. In a second example of direct path change, the gNB 106 may decide to switch the direct path to another cell or another gNB-DU within the same gNB. The figure la illustrates aninter-DU path change case. The remote UE 113 may perform a direct path change from the direct path comprising Uu link 113b (connecting the remote UE 113 to the source gNB-DUl 101) to a direct path comprising Uu link 113c (connecting the remote UE 113 to a target gNB-DU2 102). During the direct path switching from a source gNB-DUl 101 to a target gNB-DU2 102, the direct path is suspended for signaling and data flows. In a third example of direct path inter-gNB handover, the gNB 106 may configure the remote UE to handover the direct path 113b. Thus, the remote UE 113 connected to the gNB 106 may handover to be connected to the gNB 107 as illustrated in the figure la. As the remote UE is in multipath configuration, the gNB 106 may choose to handover the direct link 113b while keeping the remote UE 113 connected indirectly to the source gNB 106 via the relay UE 110. The direct link 113b is then released with the gNB 106 and a new direct link 113d is added with the gNB 107. During the handover, the direct path is suspended for signaling and data flows. In a fourth example, the gNB 106 may decide to suspend any path in a multipath transmission system by deactivating the path. The gNB 106 may choose to deactivate the direct path 113b or the indirect path (113a+110a) connecting the remote UE 113 to the network. In case the direct path 113b is suspended, the remote UE 113 remains connected to the network via the indirect path. The message flows of figure 3 may provide solutions for controlling or managing the use of SRBs for the aforementioned examples on direct path inactivity. The remote UE 113 may receive a multipath configuration in message 301a from the gNB 106. By way of example but not limited to, the multipath configuration can include configuration information for a direct path 113b and an indirect path (113a+110a) connected to the gNB-DUl 101 as illustrated in figure la. The remote UE 113 may apply the multipath configuration and may respond with a configuration complete in 301b. For example, the remote UE 113 may apply the multipath configuration to configure or set up the remote UE 113 to use the direct path 113b and the indirect path (113a+l 10a) for communicating data over or through the configured radio bearers (SRB(s), DRB(s)). In particular and in the example shown in figure 3, the multipath configuration from the gNB 106 configures the remote UE 113 to activate or set up a SRB on at least the direct path 113b. Whether the indirect path is used at this point will depend on the type of SRB and whether for split SRB duplication is activated. Next, the remote UE 113 may communicate with the gNB 106 by transmitting uplink (UL) data and receiving downlink (DL) data carried by the radio bearers using both paths as in 302. The multipath configuration in message 301a may also include a list of triggering events or one or more triggering events related to the direct path inactivity issue. In an example, the multipath configuration included in the message 301a sent to the remote UE 113 may be inserted in the RRCReconfiguration message, defined in TS 38.331. The RRCReconfiguration message may include the information element (referred to as MP-SRB-PathSwitchConfig-r 18) described hereafter. This IE may be added to the radiobearerconfig IE or the PDCP-config IE included in the RRCReconfiguration message. According to one example, configuration information of the information element MP-SRB-PathSwtchConfig-rl8 for configuring the SRB may include all or part of the following information: The list of the triggering events including for example one or more related to path inactivity, such as one or more of the direct path change, the direct path release, the direct path deactivation, the direct path handover, relay (re)selection of a relay node in the case the first path is an indirect path, and relay handover of a relay node in the case the first path is an indirect path. Other triggering events related to the path inactivity can be added to the enumerated list. PDCP-duplication. This element may indicate the remote UE is to activate the PDCP duplication when a triggering event occurs. The gNB 106 may configure the remote UE to activate the PDCP duplication when a triggering event occurs. The duplication can be activated if the SRB is initially configured on the first path (e.g. direct path) as a split bearer without duplication. For example, at the triggering event, the remote UE 113 may activate the duplication of the split SRB (e.g., SRB1 or SRB2) and send RRC messages on the second path (e.g. the indirect path). Moreover, the PDCP duplication can be applied for an initial configuration of the SRB as a non-split bearer. The nonsplit SRB may switch to a split SRB with duplication at the triggering event based on the PDCP-duplication activation. The SRB may then be activated on the second path (e.g., indirect path) as the SRB 1 / 2 are already mapped at the SRAP layer of the relay UE in a multipath configuration. PDCP-switch'. This element may indicate the remote UE is to switch the SRB to a second path (e.g. indirect path) when a triggering event occurs. The gNB 106 may decide to configure the remote UE to switch the SRB on the indirect path. The SRB may be configured initially as a non-split SRB on the direct path or a split SRB without duplication on the direct path (e.g. the first path). At the triggering event, the remote UE may switch the SRB to the second path or the indirect path with no change of its configuration type. For example, a non-split SRB (or split SRB without duplication) on the first or direct path may be switched at the triggering event to a non-split SRB (or split SRB without duplication) on the second path or the indirect path. In case of nonsplit SRB switched to the second path (e.g., indirect path), the remote UE may switch the primary path of the SRB at the triggering event to become the second path (e.g., the indirect path). Moreover, the non-split SRB may change its configuration to a split SRB without duplication at the triggering event as the E2E SRB 1 / 2 are already mapped at the SRAP layer of the relay UE in a multipath configuration. The split SRB configuration is decided based on PDCP switch. In case of PDCP-switch, the non-split SRB may change its configuration to split SRB with switching of its primary path to the second path (e.g., indirect path). PDCP-configP. This element may include or indicate a new PDCP configuration or a PDCP configuration for the radio bearer after the occurrence of a trigger event and upon or after completion of the configuration of the radio bearer (SRB) on the second path or indirect path. The PDCP configuration for the SRB as indicated by PDCP-configl can be applied by the remote UE when the second path is being used and in the case where the configuration indicated by PDCP-configl uses a direct path, once the direct path has been (re-)established. In a first example, the PDCP-configl may refer to the PDCP-config already used for the radio bearer on the first path or direct path before the triggering event. In a second example, the PDCP-configl may remain empty or assigned to the existing configuration for the radio bearer on the second path or indirect path after the triggering event, which existing configuration is determined by PDCP-duplication or PDCP-switch, and thus the radio bearer may keep the configuration which was set for the second or indirect path after the triggering event. The PDCP-configl may introduce a new configuration for the radio bearer different from the earlier configurations. In an example, the configuration refers to the type of SRB and for split SRB whether it is with duplication or without duplication. When included in the configuration information sent to the remote UE 113, the PDCP-configl indicates to the remote UE 113 what configuration to apply after the occurrence of the triggering event or at and after the occurrence of the triggering event. This enables the remote UE 113 to know if the configuration for the SRB is to be applied at the triggering event and kept afterwards or is to be applied just at the triggering event and some other configuration for the SRB (which could be the initial configuration on applied on the first path or a new configuration) is to be applied after the triggering event. This provides a flexible solution for configuring SRBs for multipath communication. The remote UE 113 and the relay UE 110 may also send to the gNB 106 some measurement reports through the Measurement Report message 303 as defined in 3GPP TS 38.331. The reporting may include theUu measurement quantity information, the sidelink measurement quantity information and additional information regarding measurement of neighbor cells or other UEs in the vicinity of UE 113. Based on the measurement report, the gNB 106 may decide to reconfigure the direct path in 304. For example, the gNB 106 may detect a better Uu quality signal in a neighbor cell or neighbor gNB-DU and thus, it may decide to configure the remote UE 113 for a direct path change. The gNB 106 may decide to configure the remote UE 113 for a handover if better Uu quality is detected with a neighbor gNB (e.g. gNB 107). In another example, the gNB 106 may decide to deactivate the direct path for different reasons including, but not limited to, low data traffic in multipath with better QoS at the indirect path, rerouting the data traffic on the indirect path for better coverage or to control the load at the connected Pcell (e.g. the cell to which the remote UE 113 is connected in the direct path). The gNB 106 may then send a reconfiguration message 305 to the remote UE 113. The reconfiguration message 305 may include, but not restricted to, a direct path change or release, a direct path deactivation or a handover or relay (re)selection for an indirect path or relay handover for an indirect path. For example, the reconfiguration message 305 may including reconfiguration information for reconfiguring the remote UE 113, where the reconfiguration information indicates one of: a direct path change or release, a direct path deactivation or a handover or relay (re)selection for an indirect path or relay handover for an indirect path. After receiving the RRCReconfiguration message 305, the remote UE 113 may detect the direct path reconfiguration and may identify that this new configuration leads to a direct path inactivity. The signaling and data traffic may then be suspended on the direct path. If the direct path inactivity is one of the triggers according to the list of triggering events configured previously through the configuration for multipath 301a, the remote UE 113 may then call (in step 306) the MP-SRB-PathSwitchConfig-r 18 IE and may activate the SRB on the indirect path by means of PDCP duplication or PDCP switch as specified in the IE. The result is the remote UE 113 can then use the indirect path for signalling data through or over the SRB. For example, the gNB 106 may configure the remote UE 113 with “split SRB1 without duplication” in message 301a. The split SRB1 is then activated on the direct path for RRC messages exchange (e.g. signalling data exchange) and deactivated on the indirect path. Furthermore, the “split SRB1 without duplication” configuration may include the MP-SRB-PathSwitchConfig-r 1'8 IE with a list of triggering events e.g., a direct path change as discussed above. The MP-SRB-PathSwitchConfig-r 18 IE may indicate a PDCP-duplication when the triggering event occurs. Therefore, the remote UE 113 receiving a configuration message 305 indicating a direct path change may trigger the reconfiguration of the split SRB1 with duplication according to the configuration information included in message 301a allowing the exchange of RRC messages 308 through the indirect path. In other words, after determining a reconfiguration involving a direct path change is required, which direct path change event is in the list of triggering events included in the configuration information received in message 301a, the remote UE 113 is triggered to change the type of SRB (e.g. to a split SRB with duplication) enabling the indirect path to be used for signalling data over the SRB. During this SRB switch, the remote UE 113 continues to communicate UL / DL data via the indirect path in 307 using the DRB configured on the indirect path for instance by the message 301a. The exchange of RRC messages 308 carried by the SRB through the indirect path may be required for some use cases as in a direct path change. By way of example, the remote UE 113 may receive from the source gNB-DUl 101 a configuration message 305 to perform an inter-DU direct path change. Thus, the remote UE 113 may change the direct path 113b to be connected to the target gNB-DU2 102 via the direct path (e.g. link 113c) as illustrated in figure la. However, the source gNB-DUl 101 may need to receive a RRCReconfigurationComplete message 308 from the remote UE 113 in order to modify or to release the remote UE context. Thus, by allowing the remote UE 113 to be able to use the indirect path (113a+110a) for signalling data through or over the SRB, the remote UE 113 can exchange RRC messages through the indirect path remaining connected to the source gNB-DUl 101. The configuration of the remote UE with a list of triggering events may help the remote UE to control the use of SRB on the indirect path for specific usage. Furthermore, the gNB 106 may not need to reconfigure, at each triggering event, the SRBs to the indirect path as the remote UE 113 can configure and control the use of the SRBs based on the one or more triggering events and information included in the configuration information provided before the occurrence of any of the triggering events (e.g. in message 301a). Upon completion of the configuration of the SRB on the indirect path (e.g. after using the indirect path for signalling through the SRB), the remote UE 113 may apply the PDCP-configl specified earlier in the MP-SRB-PathSwitchConfig-r 18 IE. For instance, the PDCP-configl may refer to the PDCP-config already setup for the SRB and thus, the remote UE 113 may (re)-use the initial configuration sent in message 301a (e.g., split SRB1 without duplication) or modified configuration as indicated in message 305 (e.g., split SRB1 with duplication) at the re-establishment of the service or communication on a direct path. The direct path may be the previous direct path, such as direct path 113b, or may be a new direct path, such as direct pathll3c in the case of inter-DU handover or direct path 113d in the case of inter-gNB handover. For the inter-DU direct path change example, after the establishment of the link 113c with the target gNB-DU2 102, the remote UE 113 may (re)-use the SRB1 configuration sent in message 301a or modified in message 305 on the new direct path 113c. Thus, a split SRB1 with duplication activated at the triggering event may be replaced by the split SRB1 without duplication as initially setup in message 301a after the completion of the indirect path change procedure. Similarly, the step 309 may be applied after completeness of handover procedure. Some use cases as direct path release may not be able to apply the step 309 as the direct path is released. For direct path deactivation, the step 309 is applied once the direct path is activated again by the network. The remote UE 113 may be able to communicate through both paths in uplink and downlink with the network in 310 upon the completion of the configuration sent in message 305 and the activation of the direct path. Otherwise, the UL / DL data traffic may be exchanged only on the indirect path. Referring now to figure 4 which shows example message flows for managing use of SRBs in a wireless communication system, such as that shown in figure la, supporting multipath communication and relaying, and in particular for managing use of SRB1 on the indirect path upon direct path failure in a multipath transmission system in accordance with embodiments of the invention. The following description is for the case where the first path is a direct path and the second path is an indirect path (via a relay node between the UE and the network) by way of example. It will be appreciated that the following description may also apply in the case where the first path is an indirect path and the second path is a direct path or an indirect path. The first path or direct path may suffer from a severe link degradation causing a path failure and thus, an interruption or a limitation of the traffic and signalling at the direct path. Moreover, the gNB may face recurrent RRC failed configurations at the direct path. The aforementioned issues may be categorized as direct path link issues and may need to be reported by the remote UE to the network via a second path within the multipath transmission system (e.g., the indirect path). It is noted that in the case of an indirect path, either or both of the Uu link or the PC5 link may suffer from severe link degradation, RLF or RRC failed configurations: these may be categorised as indirect path link issues and may need to be reported by the remote UE to the network via a second path (e.g. direct path or indirect path). For all or any of these link issues, figure 4 provides a solution to maintain the connectivity with the network by using a second path or indirect path and more particularly for reporting direct path link issues through the indirect path in a multipath transmission system. The direct path link issues are not limited to the aforementioned listed issues. The message flows 400 represents RRC message exchanges between the serving gNB 106, the serving relay UE 110 and the remote UE 113. The remote UE 113 may receive a multipath configuration in message 401a from the network and after applying the multipath configuration may respond with a configuration complete message 401b. For example, the remote UE 113 may apply the multipath configuration to configure or set up the remote UE 113 to use the direct path 113b and the indirect path (113a+l 10a) for communicating data over or through the configured radio bearers (SRB(s), DRB(s)). In particular and in the example shown in figure 4, the multipath configuration from the gNB 106 configures the remote UE 113 to activate or set up a SRB on at least the direct path 113b. Whether the indirect path is used at this point will depend on the type of SRB and whether for split SRB duplication is activated. The multipath configuration message 401a, similar to the message 301a, may include a list of triggering events related to the direct path link issues such as direct path failure (e.g. RLF), direct path link degradation or direct path RRC failures (e.g. configuration failure). In an example, the multipath configuration included in the message 401a sent to the remote UE 113 may be inserted in the RRCReconfiguration message, defined in TS 38.331. The RRCReconfiguration message may include the information element (referred to as MP-SRB-PathSwitchConfig-rl8) described hereafter. This IE may be added to the radiobear er config IE or the PDCP-config IE included in the RRCReconfiguration message. According to one example, configuration information of the information element MP-SRB-PathSwitchConfig-r 18 for configuring the SRB may include all or part of the following information: - The list of the triggering events including for example one or more of the direct path failure (e g. RLF), the direct path link degradation or the direct path RRC failures (e.g. configuration failure). Other triggering events related to the direct path link issues can be added to the enumerated list. PDCP-duplication'. This element may indicate the remote UE is to activate the PDCP duplication when a triggering event occurs. The gNB 106 may configure the remote UE to activate the PDCP duplication when a triggering event occurs. The duplication can be activated if the SRB is initially configured on the first path (e.g. direct path) as a split bearer without duplication. For example, at the triggering event, the remote UE 113 may activate the duplication of the split SRB (e.g., SRB1 or SRB2) and send RRC messages on the second path (e.g. the indirect path). Moreover, the PDCP duplication can be applied for an initial configuration of the SRB as a non-split bearer. The nonsplit SRB may switch to a split SRB with duplication at the triggering event based on the PDCP-duplication activation. The SRB may then be activated on the second path (e.g., indirect path) as the SRB1 / 2 are already mapped at the SRAP layer of the relay UE in a multipath configuration. PDCP-switch'. This element may indicate the remote UE is to switch the SRB to a second path (e.g. indirect path) when a triggering event occurs. The gNB 106 may decide to configure the remote UE to switch the SRB on the second path or the indirect path. The SRB may be configured initially as a non-split SRB on the direct path or a split SRB without duplication on the direct path (e.g. the first path). At the triggering event, the remote UE may switch the SRB to the second path or indirect path with no change of its configuration type. For example, a non-split SRB (or split SRB without duplication) on the first or direct path may be switched at the triggering event to a nonsplit SRB (or split SRB without duplication) on the second path or the indirect path. In case of non-split SRB switched to the second path (e.g., indirect path), the remote UE may switch the primary path of the SRB at the triggering event to become the second path (e.g., the indirect path). Moreover, the non-split SRB may change its configuration to a split SRB without duplication at the triggering event as the E2E SRB 1 / 2 are already mapped at the SRAP layer of the relay UE in a multipath configuration. The split SRB configuration is decided based on PDCP switch. In case of PDCP-switch, the non-split SRB may change its configuration to split SRB with switching of its primary path to the second path (e.g., indirect path). PDCP-configP. This element may include or indicate a new PDCP configuration or a PDCP configuration for the radio bearer after the occurrence of a trigger event and upon or after completion of the configuration of the radio bearer (SRB) on the second path or indirect path. The PDCP configuration for the SRB as indicated by PDCP-configl can be applied by the remote UE when the second path is being used and in the case where the configuration indicated by PDCP-configl uses a direct path, once the direct path has been (re-)established. In a first example, the PDCP-configl may refer to the PDCP-config already used for the radio bearer on the first path or direct path before the triggering event. In a second example, the PDCP-configl may remain empty or assigned to the existing configuration for the radio bearer on the second path or indirect path after the triggering event, which existing configuration is determined by PDCP-duplication or PDCP-switch, and thus the radio bearer may keep the configuration which was set for the second or indirect path after the triggering event. The PDCP-config 1 may introduce a new configuration for the radio bearer different from the earlier configurations. In an example, the configuration refers to the type of SRB and for split SRB whether it is with duplication or without duplication. Following the multipath configuration at the remote UE 113, UL / DL data is communicated between the remote UE and the network by the radio bearers using both paths (i.e., direct and indirect paths) in 402. In a first aspect, the remote UE 113 may detect a direct path failure in 403 and thus, a MCGFailurelnformation report is generated at the remote UE. This report is sent by the remote UE 113 to the gNB 106 using SRB1. As the direct path is suspended because of path failure, in order to send the MCGFailurelnformation report to the network (e.g. gNB 106), the remote UE 113 may need to send the MCGFailurelnformation report through the indirect path in case the SRB 1 is configured also on this path. At the detection of a direct path failure, the remote UE 113 is triggered to activate the SRB1 on the indirect path in step 404. For instance, the remote UE 113 may be configured with a non-split SRB1 in message 401a for multipath. Therefore, the non-split SRB1 is supported only on the direct path. The gNB 106 may configure its remote UE 113 in message 401a with one or more triggering events which includes a direct path failure event and in response to determining the occurrence of the direct path failure, the remote UE 113 is triggered to use the indirect path for carrying signalling data through SRB1. In the case where the configuration information in the message 401a also includes PDCP-switch information, the remote UE 113 is triggered to switch the non-split SRB 1 to the indirect path at the triggering event by activating the PDCP-switch. Thus, at the direct path failure triggering event, the remote UE 113 may switch the non-split SRB1 from the direct path to the indirect path and subsequently, the MCGFailurelnformation report 405 can be carried by the SRB1 through the indirect path to the gNB 106. The gNB 106 may receive the MCGFailurelnformation report from the remote UE 113 and may take the decision to recover the current direct path, or to change the Primary Cell (Pcell) of the direct path or to release the direct path. The remote UE 113 may keep the current configuration (SRB 1 on the indirect path) till receiving new RRCReconfiguration messages from the network. In another aspect, the remote UE 113 may suffer from recurrent RRC failures in 403 such as RRCreconfiguration failure or RRCResume failure. The remote UE 113 may then detect a problem to exchange RRC messages with the gNB 106 through the direct path in step 404 and may then trigger the SRB1 on the indirect path. For instance, a split SRB1 without duplication may initially be configured in message 401a by the gNB 106. Moreover, the gNB 106 may configure the remote UE 113 with configuration failure as a trigger event (via message 401a) and in response to determining or detecting configuration failure, the remote UE 113 is triggered to use the indirect path for carrying signalling data through SRB1. In the case where the configuration information in the message 401a also includes PDCP-switch information, the remote UE 113 is triggered to switch the SRB1 without duplication to the indirect path (PDCP-switch) at specified triggering events including a direct path failure. Thus, the remote UE 113 may switch the split SRB1 without duplication by switching its primary path to the indirect path and subsequently, exchange the RRC messages through the indirect path in 405. The remote UE 113 may report the Uu-RRC-Failures occurring at the direct path through the indirect path in RRC messages exchange 405. The configuration of the remote UE 113 with a list of triggering events may help the remote UE to control the occasional use of SRB on the indirect path. Furthermore, the gNB 106 may not need to reconfigure, at each triggering event, the SRBs to the indirect path as the remote UE 113 can configure and control the use of the SRBs based on the one or more triggering events and information included in the configuration information provided before the occurrence of any of the triggering events (e.g. in message 401a). The case of non-split SRB 1 (or split SRB 1 without duplication) on the direct path may trigger a re-establishment of the connection for a direct path failure case and thus, a need for exchanging additional signaling messages between the remote UE 113 and the gNB 106. Moreover, the re-establishment procedure may risk the loss of the multipath configuration. The method of flow diagram 400 configuring the SRB1 by switching or duplicating the SRB1 on the indirect path at pre-defined triggering events (such as RLF) so the additional signaling messages can be exchanged with the network on direct path failure may help to avoid the need for the re-establishment procedure by providing a smooth transition of the SRBs to an operational path (e.g the indirect path). Upon sending the RRC message 405, the remote UE 113 may apply the PDCP-configl specified in the IE as described above. In an example, the PDCP-configl may indicate the current PDCP-config is used after the triggering event and configuration of the SRB1 on the indirect path and thus, the remote UE may keep the SRB1 on the indirect path. In another example, the PDCP-configl may indicate the SRB1 in a split configuration without duplication with the primary path on the direct path is to be used after the triggering event and configuration of the SRB1 on the indirect path. In this case, the remote UE 113 may wait the re-establishment of the direct path before applying the PDCP-configl. Meanwhile, the remote UE 113 may need to continue using the SRB1 on the indirect path. Referring now to figure 5 which shows example message flows for managing multipath communication in a wireless communication system, such as that shown in figure la, supporting multipath communication and relaying, and in particular for managing use of SRB1 on the indirect path for backward compatibility in a multipath transmission system in accordance with embodiments of the invention. The following description is for the case where the first path is a direct path or indirect path and the second path is an indirect path (via a relay node between the UE and the network) by way of example. It will be appreciated that the following description may also apply in the case where the first path is an indirect path and the second path is a direct path. According to this figure, the remote UE 113 is connected to the gNB 106 via the direct link 113b as illustrated in figure la. In an example, the gNB 106 may configure the remote UE for multipath by adding (or changing) an indirect path. Thus, the gNB 106 may configure the remote UE 113 and the serving U2N relay UE 110 to establish (or change) an indirect path. The flow diagram 500 represents signalling message exchanges between the core network (120, 130), the serving gNB 106, the serving relay UE 110 and the remote UE 113 The U2N relay UE 110 may be added in any RRC state. Thus, a U2N relay UE 110 can be in a non-connected RRC state, such as RRC IDLE or INACTIVE state. A PC5-RRC message can be sent by the remote UE 113 to trigger the added Release 18 U2N relay UE to enter the CONNECTED state at the indirect path addition or change procedure. Nevertheless, the U2N relay UE 110 may be a Release 17 relay UE. The new PC5-RRC method is not backward compatible and so in the case where relay UE 110 is a Release 17 U2N relay UE, the relay UE 110 cannot be triggered by this PC5-RRC message to enter the CONNECTED state. Therefore, legacy procedure for instance using RRCReconfigurationComplete message as described by the Release 17 should be reused to trigger the Release 17 U2N relay UE to enter CONNECTED state. In order to send RRCReconfigurationComplete message on the indirect path to a relay UE, the SRB1 should be configured on this path. However, non-split SRB1 or split SRB1 without duplication configurations may restrict the exchange of RRC messages on the direct path only and thus, the remote UE 113 will not be able to send a message, such as the RRCReconfigurationComplete message, through the indirect path to trigger the relay UE to enter the RRC connected state. In order to solve the backward compatibility issue, the network should be able to distinguish between Release 17 relay UE and Release 18 or later (i.e. >Release 18 which is referred to as 18+ below) relay UE candidates. A Release 17 relay UE cannot be identified by the remote UE and / or the gNB at the moment of relay discovery, (re)selection and indirect path addition (or change). However, a Release 18 (or later) U2N relay UE may be able to be identified by its capabilities as a Release 18 (or later) relay UE. In a first example, the Release 18+ U2N relay UE may communicate its capabilities in 5G ProSe capabilities during the registration request 501 sent to the core network 120 (illustrated in figure lb) via the NG-RAN. Referring to the TS 23.304, clause 6.6.2, the UE may indicate in the registration procedure, its capabilities to support one or more ProSe capabilities, such as 5G ProSe direct discovery, 5G ProSe Layer-2 or Layer-3 U2N relay UE, etc.. The Release 18 may introduce new capabilities such as multipath and thus, the UE may include new features related to its capabilities to be a Layer-2 / Layer-3 remote UE capable of multipath communication or a Layer-2 / Layer-3 relay UE capable of multipath. For instance, a Layer-2 / Layer-3 U2N relay UE capable of multipath may be triggered using the new PC5-RRC message. Therefore, the UE exchanging its 5G ProSe capabilities and multipath capabilities at the registration stage may help the gNB (or NG-RAN node) and the core network at an early stage to classify the UEs according to their capabilities. In a second example, the Release 18+ U2N relay UE may communicate its capabilities during discovery procedure 502 or later during PC5-RRC establishment with the remote UE 113 by broadcasting its capabilities or sending them to the remote UE 113. In this case, the remote UE 113 is aware from the U2N relay UE capabilities whether the relay UE 110 is a Release 18+ relay UE and so whether the relay UE can be triggered to enter the RRCCOWECTED state by a PC5-RRC message. The remote UE 113 may or may not communicate the U2N relay UE capabilities to the gNB 106 at the discovery stage. For example, the selected relay UE 110 may communicate its capabilities to be a 5G ProSe Layer-2 U2N relay UE capable of multipath (i.e. the relay UE 110 is a Release 18+ relay UE) and thus, the remote UE 113 does not then have to consider the backward compatibility issue in the multipath configuration. In a third example, the Release 18+ U2N relay UE may include its relay UE capabilities while establishing a RRC connection 501 with the NG-RAN or the gNB 106. For instance, the Release 18+ U2N relay UE capabilities may be included in RRCSetupRequest message sent by the relay UE 110 to the gNB 106 or later in future RRC exchanged messages. The gNB 106 is then aware if the relay UE 110 is a Layer-2 or Layer-3 U2N relay UE capable of multipath or not. In case the multipath capabilities at the relay UE 110 are not communicated, the gNB 106 may then consider the backward compatibility issue at the configuration of the remote UE 113 for multipath 504. In a fourth example, the remote UE 113 may ask the relay UE 110 about its capability by sending a UECapabilityEnquirySidelink message. This message may optionally include the capability of the remote UE 113 in the UECapabilitylnformationSidelink Information Element. This capability can carry information to inform the relay UE 110 that the remote UE 113 supports the message that triggers the relay UE 110 to enter in RRCCOWECTED (i.e. supports the sending of the PC5-RRC message to trigger the relay UE 110 to enter RRC CONNECTED). From the remote UE standpoint, it means the remote UE 113 is able to send this triggering message to the relay UE 110. As a response, the relay UE 110 sends a UECapabilitylnformationSidelink message including the capability of the relay UE 110 and for example, whether the relay UE 110 supports to be triggered by the remote UE 113 to enter in RRC CO WECTED for example, the relay UE supports PC5_trigger. In a variant, this feature of supporting PC5_trigger may be mandatory for Rei ease 18 sidelink relay UE and so the relay UE 110 or remote UE 113 with the AccessStratumReleaseSidelink field set to rell8 in the UECapabilitylnformationSidelink should support this functionality (i.e. PC5 trigger). This UECapabilitylnformationSidelink message may be sent autonomously by the relay UE 110 to inform the remote UE 113 about its capabilities. According to the aforementioned procedures (e.g., 501 or 502), but not limited only to these described procedures and other procedures could be used, the Release 18+ U2N relay UE may then be identified by its capabilities to be a Release 18+ by the network or remote UE 113. In this case, no backward compatibility is to be considered in multipath configuration. However, the backward compatibility should be addressed when a U2N relay UE is not identified by the remote UE 113 or the network as Release 18+. The message flow in figure 5 aims to solve the problem of backward compatibility for an unidentified relay UE capability related to Release 18+. In other words, the message flow in figure 5 aims to solve backward compatibility issues where the relay node is not identified as a 3GPP Release 18 relay node or is not identified as a relay node of a 3GPP Release that is higher than 3GPP Release 18. The serving relay UE 110 is a Release 17 relay UE with unidentified capability related to Release 18+ by the network. This relay UE is in non-connected state 503 (e.g., RRC INACTIVE or IDLE). The remote UE 113 may receive a multipath configuration in message 504 from the network and may then apply the multipath configuration to configure or set up the remote UE 113 to use the direct path 113b and the indirect path (113a+110a) for communicating data over or through the configured radio bearers (SRB(s), DRB(s)). In particular and in the example shown in figure 5, the multipath configuration from the gNB 106 configures the remote UE 113 to activate or set up a SRB on at least the direct path 113b. The gNB 106 may include in the multipath configuration message 504 an indication of backward compatibility. For example, the gNB 106 may include information in the message 504 indicating the relay UE 110 is not identified as a Release 18+ relay node. In another example, the gNB 106 may send, after message 504, a separate message to indicate the relay UE 110 is not identified as a Release 18+ relay node. Alternatively, the remote UE 113 may determine itself that the relay UE 110 is not identified as a Release 18+ relay node based on information (e.g. capability information) received from the relay UE 110, such as from messages received from the relay UE 110 as discussed above. Thus, the remote UE 113 may be aware in step 505 (e.g. based on the information in message 504) of the need to trigger the Release 17 relay UE to enter connected state by sending an RRCReconfigurationComplete message 507 through the indirect path. For example, after the remote UE 113 determines the relay UE is not identified as a Release 18+ relay node, the remote UE 113 is triggered to activate the SRB on the indirect path and to send, to the relay UE 110 using the indirect path and through the SRB, a message (e.g. message 507) to trigger the relay UE 110 to enter the RRC connected state. The remote UE 113 may send the message 507 either after the remote UE 113 determines that the relay UE 110 is not identified as a Release 18+ relay UE or after the remote UE 113 determines that the relay UE 110 is not identified as a Release 18+ relay UE and is also in a non-connected RRC state. The remote UE 113 may determine that the relay UE 110 is in a non-connected RRC state based on information received from the gNB 106. To this end, the remote UE 113 may activate occasionally the SRB1 on the indirect path in order to send the configuration complete message 507. The multipath configuration message 504, similar to the message 301a and 401a, may include one or more triggering events related to the backward compatibility issue. For example, the one or more triggering events may include one or more of an event where the relay node is not identified as a Release 18 relay node or is not identified as a relay node of a Release that is higher than Release 18 (i.e. not identified as a Release 18+ relay node) and an event where the relay node is in a non-connected RRC state and is not identified as a Release 18 or a Release higher than Release 18 relay node. In an example, the multipath configuration included in the message 504 sent to the remote UE 113 may be inserted in the RRCReconfiguration message, defined in TS 38.331. The RRCReconfiguration message may include the information element (referred to as MP-SRB- PathSwitchConfig-rl8I) described hereafter. This IE may be added to the radiobearerconfig IE or the PDCP-config IE included in the RRCReconfiguration message. According to one example, configuration information of the information element MP-SRB-PathSwitchConfig-rl8 may include all or part of the following information: - A list of one or more triggering events for backward compatibility including for example one or more of an event where a relay node is not identified as a Release 18 relay node or is not identified as a relay node of a Release that is higher than Release 18 (e.g. is not identified as a Release 18+ relay node) and an event where a relay node is in a non-connected RRC state and is not identified as a Release 18 or a Release higher than Release 18 relay node. - An indication of backward compatibility. For example, the indication of backward compatibility indicates the relay UE 110 is not identified as a Release 18+ relay node or indicates the relay UE 110 is in a non-connected RRC state and is not identified as a Release 18+ relay node. At the receiving of this indication, the remote UE may trigger or activate the SRB1 on the indirect path to send the configuration complete message 507. _ pDCP-duplication. This element may indicate the remote UE is to activate the PDCP duplication when a triggering event occurs (e.g. when the UE determines there is a backward compatibility issue). The gNB 106 may configure the remote UE to activate the PDCP duplication for backward compatibility indication. The duplication can be activated if the SRB is initially configured on the direct path or indirect path as a split bearer. For example, when backward compatibility is indicated, the remote UE 113 may activate the duplication of the split SRB (e g., SRB1 or SRB2) and send RRC messages on the indirect path. In addition, the PDCP-duplication may be applied to a non-split SRB active on the direct path or indirect path. The PDCP-duplication may switch the non-split SRB configuration to a split SRB configuration with duplication ensuring the exchange of RRC messages on the added / changed indirect path. PDCP-switch'. This element may indicate the remote UE is to switch the SRB to a second path (e.g. indirect path) when a triggering event occurs (e.g. when the UE determines there is a backward compatibility issue). The gNB 106 may decide to configure the remote UE to switch the SRB on the indirect path. The SRB may be configured initially as a non-split SRB on the direct path or indirect path or a split SRB without duplication on the direct path or indirect path. For backward compatibility indication, the remote UE may switch the SRB to the indirect path with no change of its configuration type. For example, a non-split SRB (or split SRB without duplication) on the direct path may be switched for backward compatibility purpose to a non-split SRB (or split SRB without duplication) on the indirect path by switching its primary path. Thus, the primary path becomes the indirect path. - PDCP-configP. This element may include or indicate a new PDCP configuration or a PDCP configuration for the radio bearer after the occurrence of a trigger event and upon or after completion of the configuration of the radio bearer (SRB) on the second path or indirect path. The PDCP configuration for the SRB as indicated by PDCP-configl can be applied by the remote UE when the second path is being used and in the case where the configuration indicated by PDCP-configl uses a direct path, once the direct path has been (re-)established. In a first example, the PDCP-configl may refer to the PDCP-config already used for the radio bearer on the first path (direct path or indirect) before the triggering event. In a second example, the PDCP-configl may remain empty or assigned to the existing configuration for the radio bearer on the second path or indirect path after the triggering event, which existing configuration is determined by PDCP-duplication or PDCP-switch, and thus the radio bearer may keep the configuration which was set for the second or indirect path after the triggering event. The PDCP-configl may introduce a new configuration for the radio bearer different from the earlier configurations. In an example, the configuration refers to the type of SRB and for split SRB whether it is with duplication or without duplication. The gNB 106 may configure or setup the SRB1 in configuration information included in the multipath configuration message 504 to a non-split SRB mode or split SRB without duplication. However, the gNB 106 may include an indication of backward compatibility to the multipath configuration with a need for PDCP duplication or PDCP switch to trigger the Release 17 relay UE 110 to enter the connected state as in step 506. In a first aspect, a split SRB1 without duplication may be activated on the indirect path with PDCP duplication. The SRB1 is then set to the indirect path as a split SRB1 with duplication in order to trigger the Release 17 relay UE 110 to enter the connected state as in 506. The remote UE 113 sends a RRCReconfigurationComplete message 507 to the gNB 106 via the direct path (not shown in figure 5) and the indirect path. The RRCReconfigurationComplete message 507 triggers the Release 17 relay UE to enter a RRC CONNECTED state 508. After the indirect path addition or change completeness, the remote UE 113 may apply the initial configuration of split SRB1 without duplication on the direct path in 509. In a second aspect, a split SRB1 without duplication may be activated on the indirect path with PDCP switch. The split SRB1 without duplication may then switch its primary path to the indirect path in order to trigger the Release 17 relay UE 110 to enter the connected state as in 506. The remote UE 113 sends a RRCReconfigurationComplete message 507 to the gNB 106 via the indirect path. The RRCReconfigurationComplete message 507 triggers the Release 17 relay UE to enter a RRC CONNECTED state 508. After the completion of the configuration of the SRB1 on the indirect path, the remote UE 113 may apply the initial configuration of split SRB1 without duplication on the direct path in 509. In a third aspect, a non-split SRB 1 may be activated on the indirect path with PDCP switch. The non-split SRB1 may then switch its primary path to the indirect path in order to trigger the Release 17 relay UE 110 to enter the RRC connected state as in 506. The remote UE 113 sends a RRCReconfigurationComplete message 507 to the gNB 106. The RRCReconfigurationComplete message 507 triggers the Release 17 relay UE to RRC CONNECTED state in 508. Upon completion of the configuration of the SRB 1 on the indirect path, the remote UE 113 may apply the PDCP-configl specified in the IE as discussed above. For instance, the PDCP-configl may refer to the initial PDCP-config initially setup for SRB1 and thus, the remote UE 113 may apply the initial configuration of non-split SRB1 on the direct path in 509. The remote UE 113 is then able to communicate with the gNB 106 via both paths (e.g., direct path and indirect path) in a multipath transmission system. UL / DL data is then transmitted between the remote UE 113 and the gNB 106 in 510. The configuration of the remote UE 113 with backward compatibility indication may help the remote UE 113 to control the occasional use of SRB on the indirect path. Furthermore, the gNB 106 may not need to reconfigure again the SRBs upon the addition or the change on the indirect path as the remote UE 113 can configure and control the use of the SRBs. Furthermore, the indication of backward compatibility may allow to not restrict the SRB configuration type to be a split SRB with duplication: as discussed above, non-split SRB1 or split SRB1 without duplication can be configured. Referring now also to figure 7 which is a flow chart showing steps of a method 700 for managing use of SRBs in a wireless communication system supporting multipath communication and relaying between a UE and a network in accordance with one or more embodiments of the present invention. The wireless communication system supports sidelink relaying and / or other peer-to-peer relaying, such as over WiFi relaying or Bluetooth relaying. In the case where the wireless communication system supports sidelink relaying the UE is referred to as a remote UE and the relay node is referred to as a relay UE (e.g. a UE operating or functioning as a relay). The network of the wireless communication system includes at least one base station. Method 700 is performed at the UE. With respect to the example shown in figure la, the UE performing method 700 may be UE or remote UE 113 and the base station may be base station 106 (also referred to as gNB 106). The method 700 as shown in and described with respect to figure 7 may be performed by software elements and / or hardware elements. Thus, for example, the method as shown in and described with respect to figure 7 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 600 as shown in and described with reference to figure 6 with the method as shown in and described with respect to figure 7 being performed by one or more processing units, such as the processing unit 611. Briefly, at step 702, the remote UE 113 activates a SRB (e.g. SRB1 or SRB2) for or on a first path between the remote UE 113 and the gNB 106. The remote UE 113 may receive, from the gNB 106 configuration information for configuring the SRB on the first path and after receiving the configuration information, the remote UE 113 activates the SRB on the first path. The configuration information for the SRB on the first path may be included in a multipath configuration message for configuring multipath communication, such as message 301a, 401a or 504 received at the remote UE 113 from the gNB 106. The remote UE 113 receives (704 in figure 7), from the gNB 106, configuration information for configuring the SRB (e.g. SRB1 or SRB2 as configured on the first path) on a second path between the remote UE 113 and the gNB 106. The configuration information for the SRB on the second path may be included in a multipath configuration message such as message 301a, 401a or 504 received at the remote UE 113 from the gNB 106 or the configuration information for the SRB on the second path may be received later in a separate message. The configuration information for the second path may include all or part of the information in the MP-SRB-PathSwitchConfig-r 18 IE described above. The configuration information for the SRB on the first path and the configuration information for the SRB on the second path may be included in the same multipath configuration message, and the SRB on the first path is activated after receipt of such a multipath configuration message. The configuration information for the SRB on the second path includes triggering event information for indicating one or more triggering events for triggering the use of the SRB on the second path. The one or more triggering events may include at one of: one or more events where the first path becomes inactive; one or more events where a link issue occurs on a link of the first path; a backward compatibility event. After receiving the configuration information for configuring the SRB on the second path, the remote UE 113 uses the second path for carrying signalling or signalling data over or through the SRB after determining an occurrence of one of the one or more triggering events, at step 706. The first path is one of a direct path between the remote UE 113 and the gNB 106 (such as direct path comprising link 113b) and an indirect path including a relay node or relay UE between the remote UE 113 and the gNB 106 (such as the indirect path comprising the relay UE 110 and the links 113a and 110a) and the second path is one of a direct path and an indirect path. The one or more events where the first path becomes inactive includes at least one of: change of the first path; release of the first path; handover of the first path; deactivation of the first path; relay (re)selection of a relay node in the case the first path is an indirect path; relay handover of a relay node in the case the first path is an indirect path. A relay UE (re)selection or a relay UE handover on a first indirect path may also cause a first path inactivation. The one or more events where a link issue occurs on a link of the first path includes at least one of Radio Link Failure, RLF, on a link of the first path; link degradation on a link of the first path; failed configuration of the first path. In the case where the first path is an indirect path, the one or more events where a link issue occurs on a link of the first path includes at least one of: RLF (e.g. Uu-RLF) on a link between the relay node and the base station; RLF (PC5-RLF or UE-UE link failure) on a link between the UE and the relay node. A backward compatibility event includes one of: where a relay node is not identified as a 3GPP Release 18 relay node or is not identified as a relay node of a 3GPP Release that is higher than 3GPP Release 18 (i.e. the relay node is not identified as a Release 18+ relay node as discussed above); an event where a relay node is in a non-connected RRC state (e.g. RRC INACTIVE / IDLE) and is not identified as a 3GPP Release 18 or a Release higher than 3GPP Release 18 relay node. The backward compatibility event may be any other event which indicates that the relay UE node will not be able to respond to any procedure set out in 3GPP Release 18 or later to wake it up so the relay UE node can be used to communicate signalling through the SRB between the remote UE and the gNB (e.g. such as a PC5 trigger to enter a RRC connected state). The triggering event information may comprise a list of one or more triggering events as described above with reference to figures 3-5. As discussed above with respect to figure 3, the gNB 106 may decide to reconfigure the first path (e.g. reconfigure the multipath configuration). The decision may be based on measurement reports received from the remote UE 113 and the relay UE 110 or based on the QoS and / or load on the first and second paths. For example, the gNB 106 may decide to configure the remote UE 113 to one of change / release the first path, deactivate the first path, handover the first path, perform relay (re)selection in the case the first path is an indirect path, or perform relay handover in the case the first path is an indirect path. As a result, the remote UE 113 may receive a message, from the gNB 106, including configuration information indicating reconfiguration of the first path. The message may be the reconfiguration message 305 as discussed above. The reconfiguration information may indicate one of: change / release the first path, deactivation of the first path, handover of the first path, relay (re)selection in the case the first path is an indirect path, or relay handover in the case the first path is an indirect path. In an example case where the one or more triggering events include one or more events where a link issue occurs on a link of the first path, the remote UE 113 may determine there is a link issue on the first path (e.g. RLF on a link of the first path, link degradation on a link of the first path, failed configuration (or recurrent configuration failures) and after such a determination, the remote UE 113 is triggered to use the second path for carrying signalling through the SRB (SRB1 / 2). The signalling may include signalling sent in 405 of figure 4 and may include a MCGFailurelnformation report or a RRC message (such as a message reporting Uu-RRC-Failures). The discussion above with respect to figure 4 provides additional details of such an example case. In an example case where the one or more triggering events include a backward compatibility event, and where the first path is a direct path or an indirect path and the second path is an indirect path including a relay node (e.g. relay UE 110) between the remote UE 113 and the gNB 106, after determining a backward compatibility issue with the relay UE 110, the remote UE 113 activates the SRB on the second path and uses the second path to send, to the relay UE 110, a message through the SRB for triggering the relay node to enter a RRC CONNECTED state. The message may be a RRC message such as message 507 discussed above with reference to figure 5. The remote UE 113 may determine there is a backward compatibility issue based on information received from the gNB 106 or information received from the relay UE 110. For example, the remote UE 113 may receive from the relay UE 110 or from the gNB 106 information indicating the relay UE 110 is not identified as a 3GPP Release 18 relay node or is not identified as a relay node of a Release that is higher / later than 3GPP Release 18 (i.e. is not identified as a Release 18+ relay node) and may determine there is a backward compatibility issue based on this received information. The remote UE 113 may receive from the gNB 106 information indicating the relay node in the indirect path is in a nonconnected RRC state and is not identified as a Release 18+ relay node. The information (sent by the gNB 106 or the relay UE 110) may indicate the capabilities of the relay UE 110: for example, whether the relay UE 110 supports to be triggered by the remote UE 113 to enter in RRCCONNECTED (e.g. the relay UE 110 supports a PC5 trigger, 5G ProSe capabilities, multipath capabilities or any other information (such as AccessStratumReleaseSidelink field set to rel 18) that indicates to the gNB 106 whether the relay UE 110 can respond to any Release 18 or later Release procedure to be triggered to enter a RRC connected state). The information received from the gNB 106 may be sent in the multipath configuration message 504. The information received from the relay UE 110 may be received in a SIB message (broadcast by the relay UE 110), in a discovery message as part of the discovery procedure 502, in a RRC message at PC5 establishment (between the remote UE 113 and the relay UE 110) or in a UECapabilitylnformationSidelink message (e.g. AccessStratumReleaseSidelink field set to rel 18 in the UECapability Information Sidelink). The information sent by the relay UE 110 may be sent in response to a request sent by the remote UE 113. For example, the remote UE 113 may send a UECapabilityEnquirySidelink message and may receive in response a UECapability InformationSidelink message including the capability of the relay UE 110, such as whether the relay UE 110 supports to be triggered by the remote UE 113 to enter in RRCCONNECTED (e.g. the relay UE 110 supports a PC5 trigger). The discussion above with respect to figure 5 provides additional details of such an example case. The activated SRB for the first path may be a non-split bearer type of SRB (e.g. non-split SRB1 or non-split SRB2) or a split bearer type of SRB without duplication (e.g. split SRB1 without duplication or non-split SRB2 without duplication). In an example, the configuration further includes PDCP information indicating the type of SRB to be used for the SRB on / at or after determining the occurrence of the one of the one or more triggering events. In the case where the activated SRB on the first path is a non-split bearer type of SRB or a split bearer type of SRB without duplication, after determining an occurrence of the one of the one or more triggering events, the remote UE 113 then determines whether to change the type of SRB to be configured on the second path based on the PDCP information. The PDCP information may include at least one of: PDCP duplication configuration information (e.g. PDCP-duplication as discussed above with respect to figures 3, 4 and 5) for configuring the UE to activate PDCP duplication after determining an occurrence of the one of the one or more triggering events; PDCP switch configuration information (e.g. PDCP-switch as discussed above with respect to figures 3, 4 and 5) for configuring the UE to switch the SRB to the second path after determining an occurrence of the one of the one or more triggering events; PDCP configuration information (e.g. PDCP-configl as discussed above with respect to figures 3, 4 and 5) for indicating to the UE the type of SRB to be used for the SRB after configuration of the SRB on the second path has been completed or on or after determining the occurrence of the one of the one or more triggering events. In the case where the activated SRB on the first path is a non-split bearer type of SRB, after determining an occurrence of the one of the one or more triggering events, the remote UE 113 may switch the SRB to the second path and use the second path to carry signalling data through the SRB based on the PDCP information: for example in this case where there is no change of type, switching may be based on information provided by the PDCP-switch element, such as when PDCP-switch is activated. In the case where the activated SRB on the first path is a split bearer type of SRB without duplication, after determining an occurrence of the one of the one or more triggering events, the remote UE 113 may activate the SRB on the second path and use the second path to carry signalling data through the SRB based on the PDCP information: for example in this case where there is no change of type, the activation of the SRB on the second path may be based on information provided by the PDCP-switch element, such as when PDCP-switch is activated. In the case where the activated SRB on the first path is a non-split bearer type of SRB, after determining an occurrence of the one of the one or more triggering events, the remote UE 113 may change the type of the SRB for the second path to a split bearer type with or without duplication, switch the SRB to the second path and use the second path to carry signalling data through the SRB based on the PDCP information: for example in this case where there is a change of type, switching may be based on information provided by the PDCP-duplication element (e.g. PDCP-duplication is activated for duplication), the PDCP-switch element (e.g. PDCP-switch is activated) and / or the PDCP-configl element (e.g. change to split SRB without duplication based on the information indicated in PDCP-configl). In the case where the activated SRB on the first path is a split bearer type of SRB without duplication, after determining an occurrence of the one of the one or more triggering events, the remote UE 113 may change the type of the SRB for the second path to a split bearer type with duplication, and use the second path to carry signalling data through the SRB based on the PDCP information: for example in this case where there is a change of type, switching may be based on information provided by the PDCP-duplication element (e.g. PDCP-duplication is activated for duplication). In the case where the first path is a direct path and is deactivated (e.g. by the gNB 106 which may send a message to the remote UE 113 to deactivate the direct path) after determining an occurrence of the one of the one or more triggering events and subsequently communication over the first path is re-established (i.e. the direct path is re-activated) or another direct path between the UE and the network is established (e.g. on handover to another gNB such as gNB 107), the remote UE 113 may re-activate the SRB on the first path or the another direct path. The type of SRB for the re-activated first path or the another direct path may be indicated in the PDCP configuration information (e.g. PDCP-configl). The type of SRB could be the same type as that used on the initial SRB activated on the first path before using the second path, or could be the type of SRB used for the second path or could be a new type based on the information provided in PDCP-configl. Referring now also to figure 8 which is a flow chart showing steps of a method 800 for managing use of SRBs in a wireless communication system supporting multipath communication and relaying between a UE and a network in accordance with one or more embodiments of the present invention. The wireless communication system supports sidelink relaying and / or other peer-to-peer relaying, such as over WiFi relaying or Bluetooth relaying. In the case where the wireless communication system supports sidelink relaying the UE is referred to as a remote UE and the relay node is referred to as a relay UE (e.g. a UE operating or functioning as a relay). The network of the wireless communication system includes at least one base station. Method 800 is performed at the base station. With respect to the example shown in figure la, the base station performing method 800 may be base station 106 (also referred to as gNB 106) and the UE may be UE 113 or remote UE 113. The method 800 as shown in and described with respect to figure 8 may be performed by software elements and / or hardware elements. Thus, for example, the method as shown in and described with respect to figure 8 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 600 as shown in and described with reference to figure 6 with the method as shown in and described with respect to figure 8 being performed by one or more processing units, such as the processing unit 611. Briefly, at step 802, the gNB 106 sends, to the remote UE 113, configuration information (e.g. first configuration information) for configuring the SRB on the first path. The configuration information for the SRB on the first path may be included in a multipath configuration message such as message 301a, 401a or 504 received at the remote UE 113 from the gNB 106. At step 804, the gNB 106 sends, to the remote UE 113, configuration information (e.g. second configuration information) for configuring the SRB (e.g. SRB1 or SRB2 as configured on the first path) on a second path between the remote UE 113 and the gNB 106. The configuration information for the SRB on the second path may be included in a multipath configuration message such as message 301a, 401a or 504 received at the remote UE 113 from the gNB 106 or later in a separate RRC message. The configuration information for the second path may include all or part of the information in the MP-SRB-PathSwitchConfig-r 18 IE described above. The configuration information for the SRB on the first path and the configuration information for the SRB on the second path may be included in the same multipath configuration message, such as message 301a, 401a or 504. The remote UE 113 activates the SRB on the first path after receipt of the configuration information for configuring the SRB on the first path. The SRB (e.g. SRB 1 / 2) is also mapped at the SRAP layer of the relay UE 110 for an indirect second path. The mapping may be (pre)configured or configured by the gNB 106 at the relay UE 110 in a multipath transmission system (e.g. when configuring the relay UE 110 for multipath communication). The configuration information for the SRB on the second path includes triggering event information for indicating one or more triggering events for triggering the use of the SRB on the second path. The one or more triggering events may include at one of one or more events where the first path becomes inactive; one or more events where a link issue occurs on a link of the first path; a backward compatibility event. After sending the configuration information, the gNB 106 receives at least, from the remote UE 113 using the second path, signalling or signalling data over or through the SRB, at step 806. In the case of a split bearer with duplication, the gNB 106 may receive the signalling twice. The first path is one of a direct path between the remote UE 113 and the gNB 106 (such as direct path comprising link 113b) and an indirect path including a relay node or relay UE between the remote UE 113 and the gNB 106 (such as the indirect path comprising the relay UE 110 and the links 113a and 110a) and the second path is one of a direct path and an indirect path. The one or more events where the first path becomes inactive includes at least one of change of the first path; release of the first path; handover of the first path; deactivation of the first path; relay (re)selection of a relay node in the case the first path is an indirect path; relay handover of a relay node in the case the first path is an indirect path. A relay UE (re)selection or a relay UE handover on a first indirect path may also cause a first path inactivation. The one or more events where a link issue occurs on a link of the first path includes at least one of: Radio Link Failure, RLF, on a link of the first path; link degradation on a link of the first path; failed configuration of the first path. In the case where the first path is an indirect path, the one or more events where a link issue occurs on a link of the first path includes at least one of: RLF (e.g. Uu-RLF) on a link between the relay node and the base station; RLF (PC5-RLF or UE-UE link failure) on a link between the UE and the relay node. A backward compatibility event includes one of: where a relay node is not identified as a Release 18 relay node or is not identified as a relay node of a Release that is higher than Release 18 (i.e. the relay node is not identified as a Release 18+ relay node as discussed above); an event where a relay node is in a non-connected RRC state (e.g. RRCINACTIVE / IDLE) and is not identified as a Release 18 or a Release higher than Release 18 relay node. The triggering event information may comprise a list of one or more triggering events as described above with reference to figures 3-5. As discussed above with respect to figure 7, the gNB may decide to reconfigure the first path (e.g. reconfigure the multipath configuration). The decision may be based on measurement reports received from the remote UE 113 and the relay UE 110 or based on the QoS and / or load on the first and second paths. For example, the gNB 106 may decide to configure the remote UE 113 to one of change / release the first path, deactivate the first path, handover the first path, perform relay (re)selection in the case the first path is an indirect path, or perform relay handover in the case the first path is an indirect path. As a result, the gNB 106 may send to the remote UE 113 a message, from the gNB 106, including configuration information indicating reconfiguration of the first path. The message may be the reconfiguration message 305 as discussed above. The reconfiguration information may indicate one of: change / release the first path, deactivation of the first path, handover of the first path, relay (re)selection in the case the first path is an indirect path, or relay handover in the case the first path is an indirect path. In the case where the first path is a direct path or an indirect path and the second path is an indirect path, the gNB 106 may receive information associated with the capabilities of the relay node (e.g. relay UE 110): for example, the information may include capabilities that can be used to determine whether the relay UE 110 supports to be triggered by the remote UE 113 to enter in RRC CONNECTED (e.g. the relay UE 110 supports a PC5 trigger, 5G ProSe capabilities, multipath capabilities or any other information that indicates to the gNB 106 whether the relay UE 110 can respond to any Release 18 or later Release procedure to be triggered to enter a RRC connected state). For example, the gNB 106 may receive 5G ProSe capabilities from relay UE at the registration stage (e.g. 501 in figure 5) and / or other capabilities that can be used to determine whether the relay UE 110 supports to be triggered by the remote UE 113 to enter in RRCCONNECTED (e.g. the relay UE 110 supports a PC5 trigger). In other words, the information may include capabilities of the relay UE 110 that can be used to determine whether the relay UE 110 is a 3GPP Release 18+ relay node. The information associated with the capabilities of the relay UE 110 received at the gNB 106 may be sent in a registration request or setup message (part of procedure 501 of figure 5) or a subsequent RRC message, such as a RRCSetupRequest message. The gNB 106 may then, based on the received capability information, identify whether the relay UE 110 is a 3GPP Release 18 or higher / later relay node (i.e. a 3GPP Release 18+). After not identifying the relay UE 110 is a Release 18+ relay node, the gNB 106 sends to the remote UE 113 information indicating the relay UE 110 is not identified as a 3GPP Release 18 relay node or is not identified as a relay node of a Release that is higher than 3GPP Release 18 (i.e. is not identified as a Release 18+ relay node). The information sent by the gNB 106 may be sent in the multipath configuration message 504. More details are discussed above with reference to figure 5. The activated SRB for the first path may be a non-split bearer type of SRB (e.g. non-split SRB1 or non-split SRB2) or a split bearer type of SRB without duplication (e.g. split SRB1 without duplication or non-split SRB2 without duplication). In an example, the configuration further includes PDCP information indicating the type of SRB to be used for the SRB on / at or after determining the occurrence of the one of the one or more triggering events. The PDCP information may include at least one of: PDCP duplication configuration information (e.g. PDCP-duplication as discussed above with respect to figures 3, 4 and 5) for configuring the UE to activate PDCP duplication after determining an occurrence of the one of the one or more triggering events; PDCP switch configuration information (e.g. PDCP-switch as discussed above with respect to figures 3, 4 and 5) for configuring the UE to switch the SRB to the second path after determining an occurrence of the one of the one or more triggering events; PDCP configuration information (e.g. PDCP-configl as discussed above with respect to figures 3, 4 and 5) for indicating to the UE the type of SRB to be used for the SRB after configuration of the SRB on the second path has been completed or on or after determining the occurrence of the one of the one or more triggering events. In the case where the second path is an indirect path, the gNB 106 may send to the relay UE 110 configuration information for configuring the SRB (e.g. SRB1 or SRB2) on the second path. For example, the gNB 106 may send this configuration information separately to the relay UE 110 in its configuration to be a relay UE. Referring now also to figure 9 which is a flow chart showing steps of a method 900 for managing multipath communication in a wireless communication system supporting multipath communication and relaying between a UE and a network in accordance with one or more embodiments of the present invention. The wireless communication system supports sidelink relaying and / or other peer-to-peer relaying, such as over WiFi relaying or Bluetooth relaying. In the case where the wireless communication system supports sidelink relaying the UE is referred to as a remote UE and the relay node is referred to as a relay UE (e.g. a UE operating or functioning as a relay). The network of the wireless communication system includes at least one base station. Method 900 is performed at the relay node. The UE is connected to the base station via a direct path and an indirect path including a relay node between the UE and the base station is to be established. With respect to the example shown in figure la, the relay node performing method 900 may be relay node or relay UE 110, the UE may be remote UE 113 and the base station may be base station 106 (also referred to as gNB 106). 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 600 as shown in and described with reference to figure 6 with the method as shown in and described with respect to figure 9 being performed by one or more processing units, such as the processing unit 611. Briefly, at step 902, the relay UE 110 sends to the remote UE 113 or to the gNB 106, information for indicating the relay node is a Release 18 relay node or a relay node of a Release that is higher / later than Release 18, Release 18+, (e.g. to indicate to the remote UE or the gNB whether the relay UE 110 can respond to any Release 18 or later Release procedure to be triggered to enter a RRC connected state). The information sent by the relay UE 110 may include capability information for indicating the capabilities of the relay UE 110 associated with a Release 18 or higher Release relay node: for example, the information may include capabilities that can be used to determine whether the relay UE 110 supports to be triggered by the remote UE 113 to enter in RRC CONNECTED (e.g. the relay UE 110 supports a PC5 trigger). In other words, the information may include capabilities of the relay UE 110 that can be used to determine whether the relay UE 110 is a 3GPP Release 18+ relay node (e.g. 5G ProSe capabilities, multipath capabilities, AccessStratumReleaseSidelink field set to rell8). The information is used by the remote UE 113 and gNB 106 to identify whether the relay UE 110 is a 3GPP Release 18 or later 3GPP Release relay node. In the case where the relay UE 110 is not identified as a 3GPP Release 18 or later 3GPP Release relay node based on the information sent by the relay UE 110, a backward compatibility issue is determined and the example message flow as discussed above with reference to figure 5 may be used to solve the backward compatibility issue (e.g. where a Release 17 procedure will be needed to trigger the relay UE 110 to enter a RRCCONNECTED state which may involve the use of RRC messages or NAS message). In the case where the relay UE 110 sends the information to the gNB 106, the relay UE 110 may send the information, such as 5G ProSe capabilities, to the gNB 106 at the registration stage (e.g. 501 in figure 5) and / or other capabilities that can be used to determine whether the relay UE 110 supports to be triggered by the remote UE 113 to enter in RRC CONNECTED (e.g. the relay UE 110 supports a PC5 trigger). In the case where the relay UE 110 sends the information to the remote UE 113, the relay UE 110 may send the information to the remote UE 113 in a SIB message (broadcast by the relay UE 110), in a discovery message as part of the discovery procedure 502 of figure 5, in a RRC message at PC5 establishment (between the remote UE 113 and the relay UE 110) or in a UECapabilitylnformationSidelink message (e.g. AccessStratumReleaseSidelink field set to rel 18 in the L ECapability InformationSi delink). The information sent by the relay UE 110 may be sent in response to a request sent by the remote UE 113. For example, the remote UE 113 may send a UECapabilityEnquiiySidelink message and may receive in response a UECapabilitylnformationSidelink message including the capability of the relay UE 110, such as whether the relay UE 110 supports to be triggered by the remote UE 113 to enter in RRC CONNECTED (e.g. the relay UE 110 supports a PC5 trigger). The discussion above with respect to figure 5 provides additional details of such an example case. Figure 6 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 600 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 600 comprises a communication bus 613 to which there are preferably connected: - a processing unit 611, such as a microprocessor, and denoted CPU in Figure 6. The processing unit 611 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 600. The number of processors and the allocation of processing functions to the central processing unit 611 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 600. 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. For example, the program elements include at least one element for managing use of SRBs as discussed above. The at least one element when executed by the central processing unit 611 configure one or more processing units (e.g. functioning as or part of the processing unit 611) to perform the method(s) as described above. The communication device 600 may further comprise at least one communication interface 602 for communicating with other devices or nodes in a wireless communication system, such as a wireless communication system of Figure la. The at least one communication interface 602 may be connected to a communication network 603, 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 600. The memory may include: - a read only memory 607, denoted ROM, for storing computer programs for implementing the methods in accordance with one or more embodiments of the invention; - a random-access memory 612, 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 600 may also include one or more of the following components: - a data storage means 604 such as a hard disk, for storing computer programs for implementing methods according to one or more embodiments of the invention; - a disk drive 605 for a disk 606, the disk drive being adapted to read data from the disk 606 or to write data onto said disk; - a screen 609 for displaying decoded data and / or serving as a graphical interface with the user, by means of a keyboard 610 or any other user input means. Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 600 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 600 directly or by means of another element of the communication device 600. The disk 606 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 607, on the hard disk 604 or on a removable digital medium such as for example a disk 606 as described previously. According to an optional variant, the executable code of the programs can be received by means of the communication network 603, via the interface 602, in order to be stored in one of the storage means of the communication device 600, such as the hard disk 604, before being executed. The processing unit 611 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" or “processing unit” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. Also, the techniques could be fully implemented in one or more circuits or logic elements. In an embodiment, the apparatus is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). In such a case, logic units of an apparatus are configured to perform the steps of the method(s) in accordance with the present invention described above. 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, fiberoptic 5 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 10 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. 15

Claims

1. A method for managing use of Signalling Radio Bearers, SRBs, in a wireless communication system supporting multipath communication and relaying between a User Equipment, UE, and a network including a base station, the method at the UE comprising:activating a SRB on a first path between the UE and the base station;receiving, from the base station, configuration information for configuring the SRB on a second path between the UE and the base station, the configuration information including triggering event information for indicating one or more triggering events for triggering the use of the SRB on the second path;using the second path for carrying signalling data through the SRB after determining an occurrence of one of the one or more triggering events,wherein the first path is one of a direct path between the UE and the base station and an indirect path including a relay node between the UE and the base station and the second path is one of a direct path and an indirect path.

2. The method of claim 1, wherein the one or more triggering events includes at least one ofone or more events where the first path becomes inactive;one or more events where a link issue occurs on a link of the first path;a backward compatibility event.

3. The method of claim 2, wherein the one or more events where the first path becomes inactive includes at least one of:change of the first path;release of the first path;handover of the first path;deactivation of the first path;relay (re)selection of a relay node in the case the first path is an indirect path;relay handover of a relay node in the case the first path is an indirect path.

4. The method of claim 2 or 3, wherein the one or more events where a link issue occurs on a link of the first path includes at least one of:Radio Link Failure, RLF, on a link of the first path;link degradation on a link of the first path;failed configuration of the first path.

5. The method of claim 4, wherein in the case where the first path is an indirect path including a relay node between the UE and the base station, the one or more events where a link issue occurs on a link of the first path includes at least one of:RLF on a link between the relay node and the base station;RLF on a link between the UE and the relay node.

6. The method of any one of claims 2 to 5, wherein the backward compatibility event includes one of:an event where a relay node is not identified as a Release 18 relay node or is not identified as a relay node of a Release that is higher than Release 18;an event where a relay node is in a non-connected RRC state and is not identified as a Release 18 or a Release higher than Release 18 relay node.

7. The method of any one of the preceding claims, further comprising:receiving, from the base station, a message including reconfiguration information for reconfiguring the UE, the reconfiguration information indicating one of:change of the first path;release of the first path;handover of the first path;deactivation of the first path:relay (re)selection;relay handover;determining, from the received reconfiguration information in the case where the one or more triggering events includes one or more events where the first path becomes inactive, an occurrence of the one of the one or more triggering events.

8. The method of any one of the preceding claims, wherein the one or more triggering events includes a backward compatibility event, wherein the first path is a direct path or an indirect path and the second path is an indirect path including a relay node between the UE and the base station, the method further comprising:after determining a backward compatibility issue with the relay node, activating the SRB on the second path and using the second path to send, to the relay node, a message through the SRB for triggering the relay node to enter a RRC CONNECTED state.

9. The method of claim 8, further comprising:receiving, from the relay node in the indirect path or from the base station, information indicating the relay node is not identified as a Release 18 relay node or is not identified as a relay node of a Release that is higher than Release 18;determining a backward compatibility issue with the relay node by determining the relay node in the indirect path is not identified as a Release 18 relay node or is not identified as a relay node of a Release that is higher than Release 18 based on the received information.

10. The method of claim 8, further comprising:receiving, from the base station, information indicating the relay node in the indirect path is in a non-connected RRC state and is not identified as a Release 18 or a Release higher than Release 18 relay node;determining a backward compatibility issue with the relay node by determining the relay node is in a non-connected RRC state and is not identified as a Release 18 relay node or is not identified as a relay node of a Release that is higher than Release 18 based on the received information.

11. The method of any one of the preceding claims, wherein the activated SRB for the first path is one of:a non-split bearer type of SRB;a split bearer type of SRB without duplication.

12. The method of any one of the preceding claims, wherein the configuration information further includes PDCP information indicating the type of SRB to be used for the SRB on or after determining the occurrence of the one of the one or more triggering events.

13. The method of claim 12, wherein in the case where the activated SRB on the first path is a non-split bearer type of SRB or a split bearer type of SRB without duplication, using comprises:after determining an occurrence of the one of the one or more triggering events, determining whether to change the type of SRB to be configured on the second path based on the PDCP information.

14. The method of claim 12 or claim 13, wherein the PDCP information includes at least one of:PDCP duplication configuration information for configuring the UE to activate PDCP duplication after determining an occurrence of the one of the one or more triggering events;PDCP switch configuration information for configuring the UE to switch the SRB to the second path after determining an occurrence of the one of the one or more triggering events;PDCP configuration information for indicating to the UE the type of SRB to be used for the SRB after configuration of the SRB on the second path has been completed or on or after determining the occurrence of the one of the one or more triggering events.

15. The method of any one of the preceding claims, wherein in the case where the activated SRB on the first path is a non-split bearer type of SRB, using comprises:after determining an occurrence of the one of the one or more triggering events, switching the SRB to the second path and using the second path to carry signalling data through the SRB.

16. The method of any one of the claims 1 to 14, wherein in the case where the activated SRB on the first path is a split bearer type of SRB without duplication, using comprises:after determining an occurrence of the one of the one or more triggering events, activating the SRB on the second path and using the second path to carry signalling data through the SRB.

17. The method of any one of the claims 1 to 14, wherein in the case where the activated SRB on the first path is a non-split bearer type of SRB, using comprises:after determining an occurrence of the one of the one or more triggering events, changing the type of the SRB for the second path to a split bearer type with or without duplication, switching the SRB to the second path and using the second path to carry signalling data through the SRB.

18. The method of any one of the claims 1 to 14, wherein in the case where the activated SRB on the first path is a split bearer type of SRB without duplication, using comprises:after determining an occurrence of the one of the one or more triggering events, changing the type of the SRB for the second path to a split bearer type with duplication and using the second path to carry signalling data through the SRB.

19. The method of any one of the preceding claims, further comprising after determining an occurrence of the one of the one or more triggering events and using the second path, deactivating the SRB on the first path.

20. The method of any one of the preceding claims, wherein the first path is a direct path between the UE and the network, the method further comprising:after determining an occurrence of the one of the one or more triggering events and using the second path, deactivating the first path;after communication over the first path is re-established or after communication over another direct path between the UE and the network is established, re-activating the SRB on the first path or the another direct path.

21. The method of claim 20, wherein the configuration information further includes PDCP configuration information for indicating to the UE the type of SRB to be used for the SRB after configuration of the SRB on the second path has been completed, wherein re-activating the SRB includes re-activating the SRB on the first path or the another direct path based on the type of SRB indicated in the PDCP configuration information.

22. A method for managing use of Signalling Radio Bearers, SRBs, in a wireless communication system supporting multipath communication and relaying between a User Equipment, UE, and a network including a base station, the method at the base station comprising:sending, to the UE, configuration information for configuring a SRB on a first path between the UE and the base station;sending, to the UE, configuration information for configuring the SRB on a second path between the UE and the base station, the configuration information including triggering event information for indicating one or more triggering events for triggering the use of the SRB on the second path;receiving, from the UE using the second path, signalling data through the SRB,wherein the first path is one of a direct path between the UE and the base station and an indirect path including a relay node between the UE and the base station and the second path is one of a direct path and an indirect path.

23. The method of claim 22, wherein the one or more triggering events includes at least one of:one or more events where the first path becomes inactive;one or more events where a link issue occurs on a link of the first path;a backward compatibility event.

24. The method of claim 23, wherein the one or more events where the first path becomes inactive includes at least one of:change of the first path;release of the first path;handover of the first path;deactivation of the first path;relay (re)selection of a relay node in the case the first path is an indirect path;relay handover of a relay node in the case the first path is an indirect path.

25. The method of claim 23 or 24, wherein the one or more events where a link issue occurs on a link of the first path includes at least one of:Radio Link Failure, RLF, on a link of the first path;link degradation on a link of the first path;failed configuration of the first path.

26. The method of claim 25, wherein in the case where the first path is an indirect path including a relay node between the UE and the base station, the one or more events where a link issue occurs on a link of the first path includes at least one of:RLF on a link between the relay node and the base station;RLF on a link between the UE and the relay node.

27. The method of any one of claims 23 to 26, wherein the backward compatibility event includes one of:an event where a relay node is not identified as a Release 18 relay node or is not identified as a relay node of a Release that is higher than Release 18;an event where a relay node is in a non-connected RRC state and is not identified as a Release 18 or a Release higher than Release 18 relay node.

28. The method of any one of the claims 22 to 27, further comprising:after determining to reconfigure the first path, sending, to the UE, a message including reconfiguration information for reconfiguring the UE, the reconfiguration information indicating one of:change of the first path;release of the first path;handover of the first path;deactivation of the first path;relay (re)selection;relay handover.

29. The method of any one of claims 22 to 28, wherein the first path is a direct path or an indirect path and the second path is an indirect path including a relay node between the UE and the base station, the method further comprising:receiving information associated with the capabilities of the relay node;identifying, based on the received information, whether the relay node is a Release 18 relay node or a relay node of a Release that is higher than Release 18;after not identifying the relay node is a Release 18 or higher Release relay node, sending, to the UE, information indicating the relay node is not identified as a Release 18 relay node or is not identified as a relay node of a Release that is higher than Release 18.

30. The method of claim 29, wherein the information received at the base station is sent by the relay node and is included in one of:registration request message;RRC message;RRCSetupRequest message.

31. The method of any one of the claims 22 to 30, wherein the configuration information for configuring a SRB on a first path includes configuration information for configuring the SRB for the first path as one of:a non-split bearer type of SRB;a split bearer type of SRB without duplication.

32. The method of any one of the claims 22 to 31, wherein the configuration information for configuring the SRB on a second path further includes PDCP information indicating the type of SRB to be used for the SRB on or after determining the occurrence of the one of the one or more triggering events.

33. The method of claim 32, wherein the PDCP information includes at least one ofPDCP duplication configuration information for configuring the UE to activate PDCP duplication after determining an occurrence of the one of the one or more triggering events;PDCP switch configuration information for configuring the UE to switch the SRB to the second path after determining an occurrence of the one of the one or more triggering events;PDCP configuration information for indicating to the UE the type of SRB to be used for the SRB after configuration of the SRB on the second path has been completed or on or after determining the occurrence of the one of the one or more triggering events .

34. The method of any one of claims 22 to 33, wherein in the case the second path is an indirect path including a relay node between the UE and the base station, the method further comprising:sending, to the relay node, configuration information for configuring the SRB on the second path.

35. A method for managing multipath communication in a wireless communication system supporting multipath communication and relaying between a User Equipment, UE, and a network including a base station, wherein the UE is connected to the base station via a direct path and wherein an indirect path including a relay node between the UE and the base station is to be established, the method at the relay node comprising:sending, to the UE or the base station, information indicating the relay node is a Release 18 relay node or a relay node of a Release that is higher than Release 18.

36. The method of claim 35, wherein the information includes capability information indicating the capabilities of the relay node associated with a Release 18 or higher Release relay node.

37. The method of claim 35 or 36, wherein the information sent to the base station is included in one of:registration request messageRRC messageRRCSetupRequest message.

38. The method of any one of claims 35 to 36, wherein the information sent to the UE is included in one of:SIB message;discovery message;RRC message at PC5 establishment;UECapabilitylnformationSidelink message.

39. The method of claim 38, wherein the information is sent to the UE in response to a request received from the UE.

40. The method of any one of claims 35 to 39, further comprising receiving, from the base station, configuration information for configuring a SRB on the indirect path.

41. Apparatus for a User Equipment, UE, the apparatus comprising:one or more processing units configured to perform the method as recited in any one of claims 1 to 21 or claims 35 to 40.

42. Apparatus for a base station, the apparatus comprising:one or more processing units configured to perform the method as recited in any one of claims 22 to 34.

43. 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 40.

44. A computer-readable medium carrying a computer program according to claim 43.

Images