Sidelink relay multi-path relaying device and method for operating the same

Abstract

The invention relates to a communication device in a wireless network, wherein the device supports multi-path communication, the communication device being adapted to: - connect to a first access device through a direct path if the communication device is in coverage of the first access device; and - connect to a second access device through an indirect path via another device, in particular a relay device; and - receive a first configuration information from the first or second access device either through the direct path or through the indirect path or both, wherein the first configuration information includes at least a parameter about a first radio network temporary identifier, RNTI, assigned to the direct path for use by the first access device to transmit a scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, up-link and / or side-link; and - receive a second configuration information from the first or second access device through the direct path and / or through the indirect path, wherein the second configuration information includes a parameter about a second RNTI assigned to the indirect path, and - use the first RNTI to decode the scheduling information transmitted from the first access device or use the second RNTI to decode the scheduling information transmitted from the first access device whilst performing multi-path communication, depending on the received first and second configuration information.

Description

[0001] SIDELINK RELAY MULTI-PATH RELAYING DEVICE AND METHOD FOR OPERATING THE SAME

[0002] FIELD OF THE INVENTION

[0003] This invention relates to sidelink relay multi-path relaying in 5G New Radio (NR) wireless communication systems.

[0004] BACKGROUND OF THE INVENTION

[0005] In 3rdgeneration partnership project (3GPP) New Radio (NR) Release 18 (R18) specifications, a layer 2 (L2) UE-to-Network (U2N) sidelink relay is enhanced to support multi-path relaying as defined in the work item description (WID) RP-223501 . A multi-path relaying capable L2 U2N Remote User Equipment (UE) in the network coverage of the base station can establish two communication paths with the same base station, namely direct path directly over the L2 U2N Remote UE’s NR radio air interface (Uu interface) and indirect path indirectly via an L2 U2N Relay UE. However, in this description, also having multiple indirect paths without having a direct path is considered to be multi-path relaying.

[0006] There are at least two use cases of the L2 U2N sidelink relay multipath relaying:

[0007] Allowing the L2 U2N Remote UE to use split bearers I dual connectivity mechanism to aggregate user traffic transmitting I receiving over two paths to I from the base station;

[0008] Allowing the L2 U2N Remote UE to use duplicated bearers I PDCP duplication to improve the reliability and reduce the latency for communication with the base station.

[0009] R18 L2 U2N sidelink relay multi-path relaying is scoped to support the case that the multi-path L2 U2N Remote UEs are connected to the same base station (e.g., gNB and / or gNB-CU) on both the direct path and the indirect path, but the two paths may belong to different serving cells and gNB-DUs in a 5G NR CU-DU split architecture.

[0010] In the 5G NR gNB CU (Centralized Unit) and DU (Distributed Unit) split architecture, a gNB-CU can connect to multiple gNB-DUs and a gNB-DU can have multiple Transmission Reception Points (TRPs). All gNB-DUs connected to the same gNB-CU may belong to the same base station.

[0011] In a Release 17 (R17) sidelink relay, the L2 U2N Remote UE may connect to gNB / gNB-CU on either the direct path or the indirect path, but not on both paths simultaneously. A path switch procedure for service continuity between the direct path and the indirect path is defined in 3GPP specification TS 38.300 V17.5.0, clause 16.12.6 and the corresponding procedure for the 5G NR gNB CU-DU split architecture is defined in 3GPP specification TS 38.401 V17.5.0, clause 8.19.4.

[0012] Figure 8.19.4.1 -1 in clause 8.19.4.1 of TS 38.401 V17.5.0 describes the R17 L2 U2N Remote UE direct-to-indirect path switch procedure in the inter-DU case as follows:

[0013] • Initially, the L2 U2N Remote UE (i.e. , a legacy UE in the coverage of the serving cell) is connected on the direct path to the Source gNB-DU and gNB-CU. o Source gNB-DU will follow the UE Initial Access procedure defined in clause 8.1 of TS 38.401 V17.5.0 to allocate a Cell Radio Network Temporary Identifier (C-RNTI) for the Remote UE and inform gNB-CU the allocated C-RNTI, then gNB-CU will assign this C-RNTI to Remote UE in the RRCSetup message encapsulated in the DL RRC MESSAGE TRANSFER message via Source gNB-DU. The masterCellGroup IE in the RRCSetup message contains a newUE-ldentity filed to configure the C-RNTI value of the Remote UE with synchronous RRC reconfiguration. o Similarly, in the RRC reestablishment and / or RRC resume procedure Source gNB-DU can follow a similar procedure to allocate a new C-RNTI for the Remote UE and inform gNB-CU about the allocated new C-RNTI, then gNB-CU will assign the new C-RNTI to the Remote UE in RRCReestablishment and / or RRCResume message encapsulated in the DL RRC MESSAGE TRANSFER message via Source gNB-DU as defined in clauses 8.7 and 8.6.2 of TS 38.401 V17.5.0 respectively.

[0014] • Source gNB-DU will use its allocated C-RNTI to scramble / mask the downlink control information (DCI) transmitted on the Physical Downlink Control Channel (PDCCH) for transmitting the scheduling information of the Physical Downlink Shared Channel (PDSCH) / Physical Uplink Shared Channel (PUSCH) / Physical Uplink Control Channel (PUCCH) for the Remote UE; and Remote UE will use the assigned C-RNTI to check scram bled / masked DCI scheduling information on the PDCCH and detect if there are any scheduling assignments / grants from Source gNB-DU destinated to it. In the case of carrier aggregation where Remote UE may connect to multiple serving cells (SCells) of the gNB-DU, the same C-RNTI allocated by the gNB-DU is used for PDCCH / DCI scrambling / masking and detec- tion / check.

[0015] • Then, gNB-CU may decide to switch the Remote UE from the direct path to the indirect path after evaluating the measurements reports from the Remote UE.

[0016] • In step 4, gNB-CU requests the Target gNB-DU, which serves the Target Relay UE, to setup a UE context for the Remote UE via the UE CONTEXT SETUP REQUEST message.

[0017] • In step 5, Target gNB-DU will return the allocated new C-RNTI for Remote UE in the UE CONTEXT SETUP RESPONSE message.

[0018] • Then in step 6, gNB-CU will assign the new C-RNTI to the Remote UE in the RRCReconfiguration message encapsulated in the UE CONTEXT MODIFICATION REQUEST message sent to the Source gNB-DU, which will extract the encapsulated RRCReconfiguration message and forward the message to the Remote UE over the direct path. The new C-RNTI value is carried in the sl-UEIdenti- tyRemote field of the sl-L2RemoteUE-Config information element (IE) included in RRCReconfiguration.

[0019] • From now on, Remote UE (i.e. , L2 U2N Remote UE) is fully switched to the indirect path from the direct path. Remote UE will use the newly assigned C-RNTI value by the Target gNB-DU on the indirect path when C-RNTI is needed.

[0020] However, in the case of inter-DU multi-path relaying, the multi-path L2 U2N Remote UE (i.e., multi-path Remote UE) has connections with the gNB / gNB- CU on the direct path and the indirect path simultaneously via the respective serving gNB-DUs. As shown in Figure 8.xx.2 of 3GPP TDoc R3-230947 for inter-DU indirect path addition on top of direct path, if the same R17 sidelink relay procedure is used, the new C-RNTI allocated by gNB-DU2 (similar to Target gNB-DU in the Figure 8.19.4.1 -1 of TS 38.401 V17.5.0) on the indirect path will override the C-RNTI allocated by gNB-DU1 (similar to Source gNB-DU in the Figure 8.19.4.1 -1 of TS 38.401 V17.5.0) on the direct path. Then, Remote UE will use the updated new C- RNTI value as its current C-RNTI. However, gNB-DU1 will continue to use the old C- RNTI to scramble / mask PDCCH / DCI for transmitting the scheduling information of PDSCH / PUSCH / PUCCH destinated to Remote UE on the direct path. As a result, the multi-path Remote UE will not be able to check and decode the scram- bled / masked PDCCH / DCI scheduling information successfully on the direct path with the new C-RNTI value. Then the direct path fails completely.

[0021] SUMMARY OF THE INVENTION

[0022] It is clear from the description of the problem above that the C-RNTI assigned to the multi-path capable L2 U2N Remote UE on the direct path will be overridden by the new C-RNTI assigned on the indirect path when adding the indirect path on top of the direct path in the inter-DU case. This happens because the Remote UE only stores one C-RNTI value or because the gNB-DU1 and gNB-DU2 have not agreed to use the same C-RNTI. The legacy R17 sidelink relay path switch procedure (direct-to-indirect and / or indirect-to-direct) always updates the Remote UE’s current C-RNTI to the most recently assigned C-RNTI value on the currently active path, either the direct path or the indirect path.

[0023] It is an object of the invention to overcome the direct-path C-RNTI override problem for the multi-path L2 U2N Remote UE, so that the direct path of the multi-path will not fail because of a wrong C-RNTI assigned to the Remote UE.

[0024] It is also an object of the invention to provide with a solution on how to perform location reporting of a Remote UE and / or Relay UE in particular in the case of multi-path relay communication.

[0025] It is also an object of the invention to provide a method which improves the security process in case of multi-path relay communication.

[0026] This object is achieved by a communication device according to claim 1 , an access device according to claim 15, a wireless network according to claim 20, a method according to claim 21 , and a computer program product according to claim 30.

[0027] According to a first aspect, a communication device (e.g., a mobile, or stationary, or intermittently mobile and stationary UE) in a wireless network is provided, wherein the communication device supports multi-path relaying. The communication device may be adapted to:

[0028] - connect to a first access device through a direct path if the communication device is in coverage of the first access device; and

[0029] - connect to a second access device through an indirect path via another device (e.g., a relay device); and

[0030] - receive a first configuration information from the first or second access device either through the direct path or through the indirect path or both, wherein the first configuration information includes at least a parameter about a first radio network temporary identifier (RNTI) assigned to the direct path for use by the first access device to transmit a scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, uplink and sidelink; and

[0031] - receive a second configuration information from the first or second access device either via the direct path or the indirect path or both, wherein the second configuration information includes a parameter about a second radio network temporary identifier (RNTI) assigned to the indirect path, and - use the first RNTI to decode the scheduling information transmitted from the first access device or use the second RNTI to decode the scheduling information transmitted from the first access device whilst performing multi-path communication, depending on the received first and second configuration information.

[0032] According to a second aspect, an access device (e.g., a base station such as a gNB) in a wireless network is provided, wherein the access device supports multi-path communication with the communication device of the first aspect, the access device being adapted to:

[0033] - connect to the communication device through a direct path if the communication device is in coverage of the access device; and

[0034] - connect to the communication device through an indirect path via another device (e.g., a relay device); and

[0035] - determine that the communication device via each of the direct path and the indirect path is the same device; and

[0036] - generate and send configuration information to the communication device either via the direct path or the indirect path or both, wherein the configuration information includes at least a parameter about a radio network temporary identifier (RNTI) which may be used by the access device to transmit a scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, uplink and sidelink; and wherein the access device arranges for the RNTI to be shared across both paths.

[0037] According to a third aspect, a wireless network is provided, which comprises an access device of the second aspect and at least one communication device of the first aspect.

[0038] According to a fourth aspect, a method for operating a communication device which supports multi-path communication is provided, wherein the method comprises:

[0039] - the communication device connecting to a first access device through a direct path if the communication device is in coverage of the first access device; and

[0040] - the communication device connecting to a second access device through an indirect path via another device (e.g., a relay device); and

[0041] - the communication device receiving a first configuration information from the first or second access device either through the direct path or through the indirect path or both, wherein the first configuration information includes at least a parameter about a first radio network temporary identifier (RNTI) assigned to the direct path for use by the first access device to transmit a scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, uplink and sidelink; and

[0042] - receiving a second configuration information from the first or second access device either through the direct path or through the indirect path or both, wherein the second configuration information includes a parameter about a second radio network temporary identifier (RNTI) assigned to the indirect path, and

[0043] - the communication device using the first RNTI to decode the scheduling information transmitted from the first access device or use the second RNTI to decode the scheduling information transmitted from the first access device whilst performing multi-path communication, depending on the received first and second configuration information.

[0044] Finally, according to a fifth aspect, a computer program product is provided, which may comprise code means for producing the steps of the method according to the fourth aspect when run on a computer device. According to a first option that may be combined with any of the first to fifth aspects, the second configuration information may further include one or more of the following parameters:

[0045] - an optional parameter indicating that the second RNTI can be used instead of the first RNTI to receive and / or decode information from the first access device, or

[0046] - an optional parameter indicating that the first RNTI needs to be used instead of the second RNTI to receive and / or decode information from the first access device, or

[0047] - an optional parameter indicating a time to use or to switch between the first RNTI and second RNTI to receive and / or decode information from the first access device.

[0048] According to a second option that may be combined with the first option or any of the first to fifth aspects, the first and second configuration information may be combined in a single message.

[0049] According to a third option that may be combined with the first or second option or any of the first to fifth aspects, the communication device may store both the first and second RNTIs.

[0050] According to a fourth option that may be combined with any of the first to third options or any of the first to fifth aspects, the communication device may be configured to select which of the first RNTI and the second RNTI to use, or to switch between the first RNTI and second RNTI based on the received optional parameters.

[0051] According to a fifth option that may be combined with any of the first to fourth options or any of the first to fifth aspects, the first and / or second configuration information may indicate the number of RNTIs to be used and stored and / or a communication purpose of an RNTI.

[0052] According to a sixth option that may be combined with any of the first to fifth options or any of the first to fifth aspects, the first access device and the second access device, to which the communication device is connected, may be the same access device.

[0053] According to a seventh option that may be combined with any of the first to sixth options or any of the first to fifth aspects, the communication device may be connected to the first access device and the second access device, the first and second access devices being different distributed units belonging to the same centralized unit of a single access device.

[0054] According to an eighth option that may be combined with any of the first to seventh options or any of the first to fifth aspects, the communication device may be connected to the first access device and the second access device, the first and second access devices being different and interconnected by an interface to exchange messages in two directions.

[0055] According to a ninth option that may be combined with any of the first to eighth options or any of the first to fifth aspects, the first RNTI and the second RNTI may both be cell-RNTIs (C-RNTIs).

[0056] According to a tenth option that may be combined with any of the first to ninth options or any of the first to fifth aspects, the access device may be adapted to generate and share a single RNTI across the direct path and the indirect path.

[0057] According to an eleventh option that may be combined with any of the first to tenth options or any of the first to fifth aspects, the communication device may further be adapted to: send a localization request to a core network or receive a localization request from the core network indicating a localization method through the direct and indirect paths to the first and second access devices, respectively, send a connection information report to the core network including one or more of an access device cell identity, an access device coverage, an access device reception power, information about whether an access device is used for the direct or the indirect path, a location and / or transmission power and / or coverage area of one or more relay devices in the indirect path, related to the direct and indirect paths.

[0058] According to a twelfth option that may be combined with any of the first to eleventh options or any of the first to fifth aspects, the communication device may be configured with a time or counter window that determines a time that needs to pass before discarding old encryption keys and / or enabling new encryption keys.

[0059] According to a thirteenth option that may be combined with any of the first to twelfth options or any of the first to fifth aspects, the communication device may be configured to instruct a relay to release a connection of the indirect path prior to the execution of a key update command. In an example of the thirteenth option, the communication device may be configured to send a reconfiguration complete message over the direct path, but not over the indirect path, when the key update command is executed.

[0060] According to a fourteenth option that may be combined with any of the first to thirteenth options or any of the first to fifth aspects, the communication device may be configured to send data over the direct path until a timer expires and / or data is received through the indirect path.

[0061] According to a fifteenth option that may be combined with any of the first to fourteenth options or any of the first to fifth aspects, the access device may be adapted to: request a connection information report related to the communication device, where the connection information report includes one or more of an access device cell identity, an access device coverage, an access device transmission power, a rough location of the communication device or a rough distance and / or angle to one or more of the first and second access devices, information about whether a reported cell identity is from the first access device for the direct path or the second access device for the indirect path, a location and / or transmission power and / or coverage area of relay devices in the indirect path, or related measurement information, timing and / or timing advance information in particular, or a rough distance and / or angle to one or more relay devices, related to the direct and indirect paths; receive the connection information report related to the direct and indirect paths, and determine the location of the communication device.

[0062] According to a sixteenth option that may be combined with any of the first to fifteenth options or any of the first to fifth aspects, the access device may be configured to discard user plane data that cannot be securely processed.

[0063] According to a seventeenth option that may be combined with any of the first to sixteenth options or any of the first to fifth aspects, the access device may be configured to report a cell identity of a cell that serves a relay device to which the communication device is connected via multi-path communication and that has the best signal quality and / or the smallest distance to the communication device. According to an eighteenth option that may be combined with any of the first to seventeenth options or any of the first to fifth aspects, the method may further comprise: requesting by an access device a connection information report related to a communication device, where the connection information report includes one or more of an access device cell identity, an access device coverage, an access device transmission power, a rough location of the communication device or a rough distance and / or angle to one or more of the first and second access devices, information about whether a reported cell identity is from the first access device for the direct path or the second access device for the indirect path, a location and / or transmission power and / or coverage area of relay devices in the indirect path, or related measurement information, timing and / or timing advance information in particular, or a rough distance and / or angle to one or more relay devices, related to the direct and indirect paths, receiving from the communication device the connection information report related to the direct and indirect paths, and determining the location of the communication device.

[0064] It is noted that the above device of the first aspect may be implemented based on discrete hardware circuitries with discrete hardware components, integrated chips, or arrangements of chip modules, or based on signal processing devices or chips controlled by software routines or programs stored in memories, written on a computer readable media, or downloaded from a network, such as the Internet.

[0065] It shall be understood that the communication device of claim 1 , the access device of claim 15, the wireless network of claim 20, the method of claim 21 , and the computer program product of claim 30 may have similar and / or identical preferred embodiments, in particular, as defined in the dependent claims.

[0066] It shall further be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or above embodiments with the respective independent claim.

[0067] These and other aspects of the invention will be apparent from and elu- cidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] In the following drawings:

[0069] Fig. 1 schematically shows a diagram of a sidelink relay multi-path relaying system;

[0070] Fig. 2 schematically shows a diagram of a sidelink relay multi-path relaying in a gNB CU-DU split architecture;

[0071] Fig. 3 schematically shows a signalling and processing procedure of an inter-DU indirect path addition on top of a direct path for a multi-path Remote LIE with a legacy sidelink relay path switch procedure;

[0072] Fig. 4 schematically shows a signalling and processing procedure of an inter-DU indirect path addition on top of a direct path for a multi-path Remote UE, according to an embodiment;

[0073] Fig. 5 schematically shows another signalling and processing procedure of an inter-DU indirect path addition on top of a direct path for a multi-path Remote UE, according to an embodiment;

[0074] Fig. 6 schematically shows a signaling and processing diagram for indirect path change under a single procedure;

[0075] Fig. 7 schematically shows a signaling and processing diagram for direct path change under a single procedure; and

[0076] Fig. 8 schematically shows a signaling and processing diagram for key update.

[0077] DETAILED DESCRIPTION OF THE INVENTION

[0078] Various embodiments of the present invention are now described based on 5G cellular networks in which UE-to-network relay functions are enabled, where 4G network elements may be incorporated in the proposed 5G solutions. Furthermore, at least some of the below embodiments are described based on a 5G NR radio access technology.

[0079] Throughout the present disclosure, the abbreviation “gNB” (5G terminology) is intended to mean access device such as a cellular base station or a Wi-Fi access point. The gNB is part of the radio access network (RAN), which provides an interface to functions in the core network (CN). The RAN is part of a wireless communication network. It implements a radio access technology (RAT). Conceptually, it resides between a communication device such as a mobile phone, a computer, or any remotely controlled machine and provides connection with its CN. The CN is the communication network’s core part, which offers numerous services to customers who are interconnected via the RAN. More specifically, it directs communication streams over the communication network and possibly other networks. Furthermore, an access and mobility management function (AMF) terminates the control plane of different access networks onto the 5G CN (5GC) and controls which UEs can access the 5GC to exchange traffic. It also manages the mobility of UEs when they roam from one gNB to another for session / service continuity, whenever possible. Additionally, an Information Element (IE) designates (a group of) information which may be included within a signalling message or data flow which is sent across an interface (examples may include QoS (Quality of Service) definitions, setup parameters, user identifiers etc.). A location management function (LMF) is a network entity defined in 5G Core Network to provide positioning functionality by means to determine the geographic position of a mobile device based on downlink, uplink and sidelink location measuring radio signals. Further, a gateway mobile location center (GMLC) is used for active mobile positioning, meaning that it triggers specific activities on the network to retrieve a subscriber's location in real-time. For improved positioning precision, a GMLC can connect with additional precise location components in the network. The GMLC may contain functionality required to support LCS (Location Services). In one PLMN (Public Land Mobile Network), there may be more than one GMLC. The GMLC is the first node an external LCS client accesses in the network. Moreover, the abbreviation “OAM” (operations, administration, and management or maintenance) is understood to designate processes, activities, tools, and standards involved with operating, administering, managing and maintaining any system.

[0080] In the 3GPP specifications 23.304 and 24.501 for 5G networks, so- called proximity service (ProSe) functions are defined to enable - amongst others - connectivity for cellular communication devices (e.g UEs) that are temporarily not in coverage of an access device (gNB). This particular function is called ProSe UE-to- Network relay, or Relay UE. The Relay UE is a communication device that helps another UE to communicate to the gNB (i.e. , access device) by relaying application and network data traffic in two directions between the other UE and the gNB. The local communication between the Relay UE and the other UE is called D2D communication or Sidelink communication or PC5 communication. The abbreviation “PC5” designates an interface for sidelink communication as defined by ProSe. Furthermore, the abbreviation “UL” is used for the uplink direction from the communication device (e.g., UE) to the access device (e.g., gNB), the abbreviation “DL” for the downlink direction from the access device (e.g., gNB) to the communication device (e.g., UE), and the abbreviation “SL” for sidelink communication between two or more communication devices (e.g., UEs). Once the relaying relation is established, a UE can be connected via the Relay UE and acts in a role of “Remote UE”. This situation means that the Remote UE has an indirect network connection to the CN as opposed to a direct network connection that is the normal case (cf. 3GPP specification TS 22.261 V16.10.0).

[0081] Furthermore, 3GPP Technical Reports TR 23.733 v15.1.0 and TR 36.746 v15.1 .1 provide studies on architectural enhancements e.g. to enable an loT device (in a role of Remote UE) to operate on very low power by using a Relay UE to connect to the wider network. Because the Relay UE is physically very close, it can be reached using very low power transmissions. This work also includes security, speed and stability improvements to ProSe. These extensions of ProSe are called enhanced ProSe (“eProSe”). One proposed improvement in eProSe is an enhanced relaying architecture that operates in the second protocol layer (i.e. , L2) intended to offer end-to-end Internet Protocol (IP) packet and Packet Data Convergence Protocol (PDCP) packet transmissions to remote communication devices for application and / or user data. A benefit of this architecture is that the remote communication devices become directly visible as a registered entity in the CN, which is relevant for monitoring and billing purposes and for improved control by the access device over the communication device.

[0082] Furthermore, an element for implementing scheduling mechanisms may be the Radio Resource Control (RRC) protocol which can operate end-to-end to UEs, potentially over one or more hops taking into consideration the above relay architecture on the second protocol layer (i.e. L2). A further element may be the use of a downlink control information (DCI), which is a short message sent in a low-bitrate control channel (e.g. Physical Downlink Control Channel (PDCCH)) with a special blindly detectable modulation or coding. Here, various DCI formats can be defined with different information content.

[0083] The following embodiments are described in connection with sidelink relay multi-path relaying e.g. in a 3GPP 5G NR wireless communication system as depicted in Fig. 1. It is noted that - throughout the present disclosure - only those structural elements and functions are shown, which are useful to understand the embodiments. Other structural elements and functions are omitted for brevity reasons.

[0084] Referring to Fig. 1 , a multi-path L2 U2N Remote UE (REM-UE) 10 is connected to a base station (BS) 20 on a direct path (DP) and an indirect path (IP) simultaneously, where the direct path consists of a Uu interface between the L2 LI2N Remote UE 10 and the base station 20, the indirect path consists of a PC5 interface between the L2 U2N Remote UE 10 and a L2 U2N Relay UE (REL-UE) 12 and a Uu interface between the L2 U2N Relay UE 12 and the base station 20. Both Remote UE 10 and Relay UE 12 are located within a coverage area (COV) of the base station 20.

[0085] Fig. 2 schematically shows a diagram of a sidelink relay multi-path relaying in a next generation radio access network (NG-RAN) CU-DU split architecture, where on a direct path (DP) a multi-path L2 U2N Remote UE 12 is connected to a first distributed unit gNB-DU1 32 of the split architecture over a Uu interface, on an indirect path (IP) the L2 U2N Remote UE 10 is connected to a L2 U2N Relay UE 12 over a PC5 interface and the L2 U2N Relay UE 12 is further connected to a second distributed unit gNB-DU2 34 of the split architecture over a Uu interface, and both gNB-DU1 32 and gNB-DU2 34 are connected to a same central unit gNB-CU 30 of the split architecture. A legacy L2 U2N Relay UE 12 (3GPP R17) may indicate the support of R17 L2 U2N relaying function to NG-RAN and AMF by using an indication field relayUE-Operation-L2-r17 ASN.1 IE which is included in the UE-NR-Ca- pability ASN.1 IE defined in clause 6.3.3 of TS 38.331 V17.5.0.

[0086] In Fig. 2, assume the multi-path L2 U2N Remote UE 10 is firstly connected via the gNB-DU1 32 to the gNB-CU 30 on the direct path; during the direct path establishment, the L2 U2N Remote UE 10 indicates to the gNB-CU 30 and a 5G core access and mobility management function (AMF, not shown) its support of R18 sidelink relay multi-path relaying in a Non Access Stratum (NAS) UERadio- Capability IE in an initial access / attach; then at a later time, according to measurements reports received from the L2 U2N Remote UE 10 on the direct path, the gNB- CU 30 decides to add the indirect path for the L2 U2N Remote UE 10 to use the multi-path relaying function. The selected indirect path is routed via the L2 U2N Relay UE 12 served by the gNB-DU2 34, which is an inter-DU indirect path addition on top of direct path procedure for the multi-path L2 U2N Remote UE 10. The NAS is a functional layer running between the UE and the CN, which supports traffic and signalling messages between the CN and UE.

[0087] In Fig. 2, in a variant, the multi-path L2 U2N Remote UE 10 may firstly be connected via the gNB-DU2 34 to the gNB-CU 30 on the indirect path; the L2 U2N Remote UE 10 may use the legacy R17 sidelink relay indirect path RRC establishment procedure to establish the indirect path; during the indirect path establishment, the L2 U2N Remote UE 10 may then indicate to the gNB-CU 30 and the AMF its support of R18 sidelink relay multi-path relaying in an NAS UERadioCapability IE in an initial access / attach; then at a later time, according to measurements reports received from the L2 U2N Remote UE 10 on the indirect path, the gNB-CU 30 may decide to add the direct path for the L2 U2N Remote UE 10 to use the multi-path relaying function. The direct path is served by the gNB-DU1 32, which is an inter-DU direct path addition on top of indirect path procedure for the multi-path L2 U2N Remote UE 10.

[0088] Indication of multi-path relaying function support

[0089] In some embodiments, the multi-path L2 U2N Remote UE 10 and / or the multi-path L2 U2N Relay UE 12 (3GPP R18) may indicate the support of multipath relaying function to NG-RAN and AMF by using e.g. an indication field re- moteUE-MultiPathOperation-L2 respectively relayUE-MultiPathOperation-L2 contained e.g. in the below defined RelayParameters-r18 ASN.1 IE which may be included in the UE-NR-Capability ASN.1 IE defined in clause 6.3.3 of TS 38.331 V17.5.0.

[0090] - Regular non-critical Rel-16 extensions: UE-NR-Capability-v1610 SEQUENCE { inDeviceCoexlnd-r16 ENUMERATED {supported} OPTIONAL, dl-DedicatedMessageSegmentation-r16 ENUMERATED {supported} OP¬

[0091] TIONAL, nrdc-Parameters-v1610 NRDC-Parameters-v1610 OPTIONAL, powSav-Parameters-r16 PowSav-Parameters-r16 OPTIONAL, fr1 -Add-UE-NR-Capabilities-v1610 UE-NR-CapabilityAddFRX-Mode-v1610 OP¬

[0092] TIONAL, fr2-Add-UE-NR-Capabilities-v1610 UE-NR-CapabilityAddFRX-Mode-v1610 OP¬

[0093] TIONAL, bh-RLF-lndication-r16 ENUMERATED {supported} OPTIONAL, directSN-AdditionFirstRRC-IAB-r16 ENUMERATED {supported} OP-

[0094] TIONAL, bap-Parameters-r16 BAP-Parameters-r16 OPTIONAL, reference Time Provision-r16 ENUMERATED {supported} OPTIONAL,

[0095] 6.3.3. SidelinkParameters-r16 OPTIONAL, highSpeedParameters-r16 HighSpeedParameters-r16 OPTIONAL, mac-Parameters-v1610 MAC-Parameters-v1610 OPTIONAL, mcgRLF-RecoveryViaSCG-r16 ENUMERATED {supported} OP-

[0096] TIONAL, resumeWithStoredMCG-SCells-r16 ENUMERATED {supported} OP-

[0097] TIONAL, resumeWithStoredSCG-r16 ENUMERATED {supported} OPTIONAL, resumeWithSCG-Config-r16 ENUMERATED {supported} OPTIONAL, ue-BasedPerfMeas-Parameters-r16 UE-BasedPerfMeas-Parameters-r16 OP-

[0098] TIONAL, son-Parameters-r16 SON-Parameters-r16 OPTIONAL, onDemandSIB-Connected-r16 ENUMERATED {supported} OP-

[0099] TIONAL, nonCritical Extension UE-NR-Capability-v1640 OPTIONAL }

[0100] SidelinkParameters-r16 ::= SEQUENCE { sidelinkParametersNR-r16 SidelinkParametersNR-r16 OP-

[0101] TIONAL, sidelinkParametersEUTRA-r16 SidelinkParametersEUTRA-r16 OPTIONAL

[0102] }

[0103] SidelinkParametersNR-r16 ::= SEQUENCE { rlc-ParametersSidelink-r16 RLC-ParametersSidelink-r16 OP-

[0104] TIONAL, mac-ParametersSidelink-r16 MAC-ParametersSidelink-r16 OP-

[0105] TIONAL, fdd-Add-UE-Sidelink-Capabilities-r16 UE-SidelinkCapabilityAddXDD-Mode-r16

[0106] OPTIONAL, tdd-Add-UE-Sidelink-Capabilities-r16 UE-SidelinkCapabilityAddXDD-Mode-r16

[0107] OPTIONAL, supportedBandListSidelink-r16 SEQUENCE (SIZE (1 maxBands)) OF BandSidelink-r16

[0108] OPTIONAL, relayParameters-r17 RelayParameters-r17 OPTIONAL

[0109] ]], [[

[0110] - R1 32-x: Use of new RO parameters for open loop power control pO-OLPC-Sidelink-r17 ENUMERATED{supported} OP-

[0111] TIONAL

[0112] 1

[0113] [[ relayParameters-r18 RelayParameters-r18 OPTIONAL

[0114] ]]

[0115] } RelayParameters-r17 ::= SEQUENCE { relayUE-Operation-L2-r17 ENUMERATED {supported} OPTIONAL, remoteUE-Operation-L2-r17 ENUMERATED {supported} OPTIONAL, remoteUE-PathSwitchToldlelnactiveRelay-r17 ENUMERATED {supported} OP-

[0116] TIONAL,

[0117] RelayParameters-r18 ::= SEQUENCE { relayUE-MultiPathOperation-L2-r18 ENUMERATED {supported} OP-

[0118] TIONAL, remoteUE-MultiPathOperation-L2-r18 ENUMERATED {supported}

[0119] OPTIONAL,

[0120] Thus, according to this variant, it is proposed that the UE sends a relayed traffic support indication, which indicates that relay UE multipath communication is supported.

[0121] In some embodiments, the base station 20 (gNB) may broadcast the NG-RAN support of multi-path relaying information in a system information block (SIB) broadcasting and / or on-demand system information request and / or dedicated SIB request.

[0122] Fig. 3 is a diagram showing a multi-path relaying signalling and processing procedure of inter-DU indirect path addition on top of direct path with legacy R17 sidelink relay direct-to-indirect path switch procedure. A detailed description can be found from Figure 8.19.4.1 -1 in clause 8.19.4.1 of TS 38.401 V17.5.0 and Figure 8. xx.2 of 3GPP TDoc R3-230947.

[0123] In step S301 , the Remote UE 10 sends an RRC Setup Request to the gNB-DU1 32 which allocates in step S302 a first C-RNTI (C-RNTI1 ) to the Remote UE 10. Then, in step S303, the gNB-DU1 performs an initial UL RRC message transfer with the allocated C-RNTI1 to the gNB-CU 30 which stores the C-RNTI1 in step S304 and responds with a DL RRC message transfer in step S305. In response thereto, the gNB-DU1 32 sends an RRC Setup Response with the allocated C- RNTI1 to the Remote UE 10 in step S306. Then, the Remote UE 10 configures the C-RNT11 in step S307 and responds to the gNB-DU1 32 with an RRC Setup Complete message in step S308. Thereafter, the gNB-DU1 32 initiates a UL RRC message transfer to the gNB-CU 30 which sends an Initial UE message to the AMF in step S310. The AMF responds with an Initial Context Setup Request in step S311 , which is forwarded by the gNB-CU 30 in step S312 to the gNB-DU1 32. The gNB- DU1 32 sends in step S313 a Security Mode Command to the Remote UE 10 and responds to the gNB-CU 30 with a UE Context Setup Response in step S314. After completion of the security mode, the Remote UE 10 sends a Security Mode Complete message to the gNB-DU1 32 in step S315. In response, the gNB-DU1 32 initiates an UL RRC message transfer to the gNB-CU 30 in step S316, which responds with a DL RRC message transfer in step S317. Then, the gNB-DU1 32 sends an RRC Reconfiguration message to the Remote UE in step S318 and the Remote UE 10 responds in step S319 with an RRC Reconfiguration Complete message. The gNB-DU1 32 initiates in step S320 an UL RRC Message Transfer to the gNB-CU 30 which sends an Initial Context Setup Response to the AMF in step S321 . Thereafter, DL / UL data can be transferred from the Remote UE 10 over the direct path via the gNB-DU1 32 to the gNB-CU 30 in step S322. The direct data transfer is then followed by a measurement configuration and reporting in step S323.

[0124] In step S324, the gNB-CU 30 decides to add an indirect path via the Relay UE 12 and the gNB-DU2 34. In response, an RRC Reconfiguration of the Relay UE 12 is performed in step S325. Thereafter, in step S326, the gNB-CU 30 sends a UE Context Setup Request to the gNB-DU2 34 which, in response thereto, allocates in step S327 a new C-RNTI (C-RNTI2) to the Remote UE 10 and responds to the gNB-CU 30 with a UE Context Setup Response in step S328. In subsequent step S329, the gNB-CU 30 stores the new C-RNTI2. Then, in step S330, the gNB- CU 30 initiates a DL RRC Message Transfer for RRC Reconfiguration (including the new C-RNTI2) to the gNB-DU1 32. In step S331 , the gNB-DU1 32 sends an RRC Reconfiguration message with the new C-RNTI2 to the Remote UE 10. Based on the received RRC Reconfiguration message with Sidelink Path Switch Configuration information and C-RNTI information, the Remote UE 10 performs in step S332 a PC5 Connection Establishment with the Relay UE 12 and configures and stores the received C-RNTI2 in step S333. Then, the Remote UE 10 responds in step S334 with an RRC Reconfiguration Complete message to the gNB-DU1 32. The gNB-DU1 32 initiates in step S335 a corresponding UL RRC Message Transfer to the gNB-CU 30. However, in subsequent step S336, the direct path transmission fails because a different C-RNTI (i.e., C-RNTI2) has been configured at the Remote UE 10 compared to the gNB-DU1 32 (i.e., C-RNTI1 ). As a result, DL / UL data are only transmitted through the indirect path via the Relay UE 12 in step S337.

[0125] Thus, in the above R17 direct-to-indirect path switch procedure, the direct path needs to be released at the end, and only the indirect path is kept.

[0126] However, as indicated in the initial section above, when using the legacy R17 sidelink relay direct-to-indirect path switch procedure of Fig. 3, the L2 U2N Remote UE 10 will end in a state that the firstly assigned C-RNTI (i.e., C-RNT11 ) on the direct path allocated by the direct path serving gNB-DU1 32 will be overridden by the secondly assigned C-RNTI (i.e., C-RNTI2) on the indirect path allocated by the indirect path serving gNB-DU2 34 using R17 sidelink relay procedure.

[0127] As a result, the multi-path L2 U2N Remote UE 10 stores a different C- RNTI (i.e., C-RNTI2) to detect and check the PDCCH / DCI scheduling information on the direct path scrambled / masked by the gNB-DU1 32 with C-RNTI1 . Then, the L2 U2N Remote UE 10 will fail to decode the PDCCH / DCI scheduling information from the gNB-DU1 32, and the direct path fails completely.

[0128] Inter-DU indirect path addition and / or change on top of direct path

[0129] Fig. 4 is a diagram according to an embodiment of the invention. The diagram shows a multi-path relaying signalling and processing procedure of inter-DU indirect path addition on top of direct path.

[0130] The initial steps S401 to S423 are similar to the above steps S301 to S323 and are not described again here.

[0131] In step S424, the gNB-CU 30 decides to add an indirect path via the Relay UE 12 and the gNB-DU2 34. In response, an RRC Reconfiguration of the Relay UE 12 is performed in step S425. Thereafter, in step S426, the gNB-CU 30 sends a UE Context Setup Request to the gNB-DU2 34 which, in response thereto, allocates in step S427 a new C-RNTI (C-RNTI2) to the Remote UE 10 and responds to the gNB-CU 30 with a UE Context Setup Response in step S428. In subsequent step S429, the gNB-CU 30 stores the new C-RNTI2. Then, in step S430, the gNB- CU 30 initiates a DL RRC Message Transfer for RRC Reconfiguration, which may include a newly defined IE SL-MultiPathConfig(directPathC-RNTI C-RNTI1, indi- rectPathC-RNTI C-RNTI2, or similar IE to the gNB-DU1 32. In step S431 , the gNB- DU1 32 sends an RRC Reconfiguration message with the SL-MultiPathConfig IE (or similar IE) to the Remote UE 10. Based on the received RRC Reconfiguration with SL-Multi Path Config IE (or similar IE) with C-RNTI information, the Remote UE 10 performs in step S432 a PC5 Connection Establishment with the Relay UE 12 and configures and stores the received C-RNTI information in step S433. Then, the Remote UE 10 responds in step S434 with an RRC Reconfiguration Complete message to the gNB-DU1 32. The gNB-DU1 32 initiates in step S435 a corresponding UL RRC Message Transfer to the gNB-CU 30.

[0132] In view of the fact that both C-RNT11 and C-RNTI2 for both direct and indirect paths are available at the Remote UE 10, DL / UL data can be exchange through the direct path via the gNB-DU1 32 in step S436 using C-RNTI1 and through the indirect path via the Relay UE 12 and the gNB-DU2 34 in step S437 using C-RNTI2.

[0133] Thus, a new SL-MultiPathConfig IE (or similar IE) may be defined as below in the ReconfigurationWithSync IE which is further contained in RRCReconfig- uration. Detailed definition of RRCReconfiguration can be found in TS 38.331 V17.5.0, clause 6.2.2.

[0134] The SL-MultiPathConfig IE (or similar IE) contains the C-RNTI for the direct path allocated by the direct path serving gNB-DU1 32, and the C-RNTI for the indirect path allocated by the indirect path serving gNB-DU2 34. Upon receiving the RRCReconfiguration message by the L2 U2N Remote UE 10, the Remote UE 10 may configure and store the two C-RNTIs for direct path and indirect path respectively. In the following communication on the direct path, the Remote UE 10 will now have the right C-RNTI (i.e. , C-RNTI1) for checking and decoding the PDCCH / DCI scheduling information transmitted by the direct path serving gNB-DU1 32.

[0135] In a variant of the previous embodiments, the gNB / gNB-CU 30 may configure the serving cell information (such as physical cell ID, carrier information etc.) of either the direct path, indirect path or both in the new SL-MultiPathConfig IE (or similar IE) via the RRCReconfiguration message. The Remote UE 10 may configure and store the configured serving cell information for direct path, indirect path, or both in a local storage.

[0136] In a further variant of the previous embodiments, the gNB / gNB-CU 30 may only assign one C-RNTI value to the Remote UE 10 by using either the di- rectPathC-RNTI field or the indirectPathC-RNTI field in the new SL-MultiPathConfig IE (or similar IE) and skipping the other field.

[0137] In another variant of the previous embodiments, in a procedure of adding an indirect path on top of the direct path or changing from one indirect path to the other indirect path on top of the direct path, the gNB / gNB-CU 30 may only assign one C-RNTI value to the Remote UE 10 with only the indirectPathC-RNTI field configured in the new SL-MultiPathConfig IE (or similar IE). Upon receiving the RRCReconfiguration message by the L2 U2N Remote UE 10, the Remote UE 10 may keep the currently configured di rectPath C-RNTI value for the direct path, and update only the C-RNTI value for the indirect path. In another variant of the previous embodiments, in a procedure of adding an indirect path on top of a direct path or changing from one indirect path to the other indirect path on top of a direct path, the gNB / gNB-CU 30 may only assign the C-RNTI allocated by the direct path serving gNB-DU (i.e. , gNB-DU1 32) to the multipath L2 U2N Remote UE 10 because only the direct path C-RNTI is useful for the multi-path Remote UE operation to receive scheduling information from the gNB (i.e., gNB-CU 30) and / or direct path serving gNB-DU (i.e., gNB-DU1 32). In this case, the SL-Multi PathConfig IE (or similar IE) may only contain the directPathC- RNTI field as defined below.

[0138] In another variant of the previous embodiments, the gNB / gNB-CU 30 may not assign any new C-RNTI to the Remote UE 10 at all, in a procedure of adding an indirect path on top of the direct path or changing from one indirect path to the other indirect path on top of the direct path, so that the Remote UE 10 may continue to use the current C-RNTI (i.e., C-RNTI1 ) on the direct path. In this case, the SL- Multi Path Config IE (or similar IE) may be defined as above to have the C-RNTI related fields as optional, so that the SL-Multi PathConfig IE (or similar IE) configured on the Remote UE 10 may not contain the C-RNTI related field.

[0139] In another variant of the previous embodiments, the gNB / gNB-CU 30 may not assign any new C-RNTI to the Remote UE 10 at all, in a procedure of adding an indirect path on top of the direct path or changing from one indirect path to the other indirect path on top of the direct path, so that the Remote UE 10 may continue to use the current C-RNTI (i.e., C.RNTI1 ) on the direct path. In this case, the SL- Multi Path Config IE (or similar IE) may not contain any C-RNTI related field as illustrated below. In another variant of the previous embodiments, the gNB / gNB-CU 30 may configure the direct path of a multi-path Remote UE as the primary path in the multi-path configuration, and in the procedure of adding an indirect path on top of the direct path or changing from one indirect path to the other indirect path on top of direct path, the Remote UE may ignore any assigned new C-RNTI value to it and may continue to use the current C-RNTI on the direct path.

[0140] In another variant of the previous embodiments, in the procedure of adding an indirect path on top of the direct path or changing from one indirect path to the other indirect path on top of direct path, the Remote UE 10 may ignore any assigned new C-RNTI value to it and may continue to use the current C-RNTI on the direct path for the communications on the direct path.

[0141] In still another variant of the previous embodiments, the Remote UE 10 will receive the C-RNTI allocated for the indirect path by the gNB-DU (i.e. , gNB-DU2 34) serving the indirect path and store it in addition to the C-RNTI previously allocated for the direct path by the gNB-DU (i.e., gNB-DU1 32) serving the direct path, at least during the time the multi-path session is active, or until it has received an instruction (e.g., RRC (Re-)configuration message) with a parameter indicating that the C-RNTI for the direct path has been updated by the gNB-DU serving the direct path (i.e., gNB-DU1 32) to be the same as the C-RNTI allocated for the indirect path, or a parameter indicating that the C-RNTI previously allocated will not be used anymore for the direct path, or a parameter indicating a new C-RNTI value that overrides the C-RNTI allocated for the direct path and / or the indirect path (whereby the direct path / indirect path may be indicated with a flag or with a different name of the parameter)), or until a (pre-configured) timeout expires. The Remote UE 10 can then use the right C-RNTI for the decoding of the PDCCH / DCI or try another stored C- RNTI for decoding of the PDCCH / DCI if decoding fails. Additionally or alternatively, the Remote UE 10 may receive an instruction (e.g. RRC (Re-)configuration message) with a parameter indicating a time (e.g. start time or offset or time interval) to use or to switch between a first and second C-RNTI (e.g. the C-RNTI received / as- signed for direct path and the C-RNTI received / assigned for the indirect path)).

[0142] In another embodiment variant of the previous embodiments, in order to distinguish the multi-path procedure from the legacy R17 procedure for sidelink relay, the gNB-CU 30 or gNB-DU (e.g., gNB-DU1 32) may include in a message to the Remote UE 10 (e.g. RRC (Re-)configuration message)), a parameter indicating that the C-RNTI for the direct path has been updated by the gNB-DU serving the direct path to be the same as the C-RNTI allocated for the indirect path, or a parameter indicating that the C-RNTI previously allocated will not be used anymore for the direct path, or a parameter indicating a new C-RNTI value that overrides the C-RNTI allocated for the direct path and / or the indirect path (and that may be currently stored in the Remote LIE 10), whereby the direct path / indirect path may be indicated with a flag or with a different name of the parameter (e.g. different name for the different paths), or a parameter indicating a time (e.g. start time or offset or time interval) to use or to switch between a first and second C-RNTI (e.g. the C-RNTI re- ceived / assigned for direct path and the C-RNTI received / assigned for the indirect path) to receive and / or decode information from the first base station device.

[0143] In another embodiment variant of the previous embodiments, the SL- MultiPathConfig IE (or similar IE) may be defined as below in the ASN.1 format including a field of Boolean flag IsDirectPath indicating whether the included C-RNTI is for direct path or indirect path or both.

[0144] In a first case, when the flag isDirectPath is set to value “true”, the C- RNTI value may be configured for the direct path. In a second case, when the flag isDirectPath is set to value “false”, the C-RNTI value may be configured for the indirect path. In a third case, when the flag isDirectPath is absent from the SL-MultiPath- Config IE (or similar IE), the C-RNTI value may be configured for both direct path and indirect path.

[0145] In another embodiment variant of the previous embodiments, the SL- PathSwitchConfig-r17 IE may be expanded to include the configuration parameters defined in the SL-MultiPathConfig IE (or similar IE), then SL-PathSwitchConfig-r18 IE may have the same parameters as SL-MultiPathConfig IE (or similar IE).

[0146] In another embodiment variant of the previous embodiments, the configuration parameters defined in SL-MultiPathConfig IE (or similar IE) may be included in RRCReconfiguration message directly and / or in ReconfigurationWithSync IE, then SL-MultiPathConfig IE (or similar IE) may not need to include in RRCRecon- figuration message with ReconfigurationWithSync for multi-path relaying function configuration on Remote UE and / or Relay UE.

[0147] Inter-DU direct path addition / change on top of indirect path

[0148] In a variant of the previous embodiments, in the multi-path relaying signalling and processing procedure of inter-DU direct path addition on top of indirect path, or changing from one direct path to the other direct path on top of indirect path, the multi-path L2 LI2N Remote UE 10 may establish the indirect path first via the L2 U2N Relay UE 12 to the indirect path serving gNB-DU2 34, where a C-RNTI (i.e. C- RNTI2) allocated by the gNB-DU2 34 will be assigned to the Remote UE 10 by the gNB-CU 30 via the legacy R17 sidelink relay procedure. Then, the gNB-CU 30 decides to add a direct path on top of the indirect path, or change to a new direct path from an old direct path on top of the indirect path. The direct path serving gNB-DU1 32 may allocate a new C-RNTI (i.e., C-RNTI1 ) for the Remote UE 10 on the direct path. The same SL-MultiPathConfig IE (or similar IE) defined above in the ReconfigurationWithSync IE which is further contained in the RRCReconfiguration message can be used to assign the two allocated C-RNTIs for indirect path and direct path by the indirect path serving gNB-DU2 34 and the direct path serving gNB-DU1 32 respectively. Upon receiving the RRCReconfiguration message by the L2 U2N Remote UE 10, the Remote UE 10 may configure and store the two C-RNTIs for direct path and indirect path respectively. In the following communication on the direct path, the Remote UE 10 will have the right C-RNTI for checking and decoding the PDCCH / DCI scheduling information transmitted by the direct path serving gNB-DU1 32.

[0149] In a variant of the previous embodiments, the multi-path Remote UE 10 may be assigned / configured a new C-RNTI for the direct path only. The Remote UE 10 may configure and store the C-RNTI, and override the C-RNTI value configured on the indirect path previously. In the following communication on the direct path, the Remote UE 10 will have the right C-RNTI for checking and decoding the PDCCH / DCI scheduling information transmitted by the direct path serving gNB / gNB- DU. Thus, in other words it is proposed a method for operating a UE, said UE operating in multi-path communication with a direct path and an indirect path in a communication network, the method comprising receiving, by the UE, from a base station an RRC message for configuring a new C-RNTI value, overriding, by the UE, a C-RNTI value configured on the indirect path, using, by the UE, the new C-RNTI value for decoding Control Information such as scheduling information transmitted on the direct path by a serving base station.

[0150] As mentioned above, the new C-RNTI value may be configured for the direct path communication.

[0151] Intra-DU indirect path addition / change on top of direct oath

[0152] In a variant of the previous embodiments, in the multi-path relaying signalling and processing procedure of intra-DU indirect path addition on top of direct path, or changing from one indirect path to the other indirect path on top of direct path, the multi-path L2 U2N Remote UE 10 may establish the direct path first to the serving gNB-DU / gNB-CU. Then, the gNB-CU 30 decides to add an indirect path on top of the direct path, or change to a new indirect path from an old indirect path on top of the direct path. The indirect path is connected to the same gNB-DU via the L2 U2N Relay UE 12. The same C-RNTI may be used or a new C-RNTI may be generated by gNB-DU. The gNB-CU 30 may use either the legacy R17 sidelink relay procedure, or the new SL-MultiPathConfig IE (or similar IE) defined above to configure the old C-RNTI or the new C-RNTI to the Remote UE 10. In the case of using the SL-MultiPathConfig IE (or similar IE) to carry the C-RNTI values for the direct path and the indirect path, directPathC-RNTI and indirectPathC-RNTI fields will have the same C-RNTI value. Upon receiving the RRCReconfiguration message by the L2 U2N Remote UE 10, the Remote UE 10 may configure and store the two C-RNTIs for direct path and indirect path respectively, or just configure and store one C-RNTI for the Remote UE 10 because they are the same. In the following communication on the direct path, the Remote UE 10 will have the right C-RNTI for checking and decoding the PDCCH / DCI scheduling information transmitted by the gNB-DU.

[0153] In a variant of the previous embodiments, the multi-path Remote UE 10 may be assigned / configured a new C-RNTI for the direct path only. The Remote UE 10 may configure and store the C-RNTI, and override the C-RNTI value configured on the indirect path previously. In the following communication on the direct path, the Remote UE 10 will have the right C-RNTI for checking and decoding the PDCCH / DCI scheduling information transmitted on the direct path by the serving gNB / gNB-DU.

[0154] Intra-DU direct path addition / change on top of indirect path

[0155] In a variant of the previous embodiments, in the multi-path relaying signalling and processing procedure of intra-DU direct path addition on top of indirect path, or changing from one direct path to the other direct path on top of indirect path, the multi-path L2 U2N Remote UE 10 may establish the indirect path first via the L2 U2N Relay UE 12 to the serving gNB-DU / gNB-CU. Then, the gNB-CU 30 decides to add a direct path on top of the indirect path, or change to a new direct path from an old direct path on top of the indirect path. The direct path is connected to the same gNB-DU over the Uu interface directly. The same C-RNTI may be used or a new C- RNTI may be generated by the gNB-DU. The gNB-CU 30 may use either the legacy R17 sidelink relay procedure, or the new SL-MultiPathConfig IE (or similar IE) defined above to configure the old C-RNTI or the new C-RNTI to the Remote UE 10. In the case of using the SL-MultiPathConfig IE (or similar IE) to carry the C-RNTI values for the indirect path and the direct path, indirectPathC-RNTI and directPathC- RNTI fields will have the same C-RNTI value. Upon receiving the RRCReconfigura- tion message by the L2 U2N Remote UE 10, the Remote UE 10 may configure and store the two C-RNTIs for indirect path and direct path respectively, or just configure and store one C-RNTI for the Remote UE 10 because they are the same. In the following communication on the direct path, the Remote UE 10 will have the right C- RNTI for checking and decoding the PDCCH / DCI scheduling information transmitted by the gNB / gNB-DU.

[0156] Inter-DU direct path release for L2 U2N Remote UE operating in multipath

[0157] In an embodiment that can be combined with any of the previous embodiments or used independently, the L2 U2N Remote UE 10 operating in multipath mode may measure the receiving signal quality on the serving cell of the direct path and may detect the receiving signal quality to be below a pre- configured / common / dedicated threshold, or a Radio Link Failure (RLF) may be detected on the direct path. Then, it may trigger a direct path release procedure by the gNB. If there are two C-RNTIs stored in the L2 U2N Remote UE 10, the L2 U2N Remote UE may discard the C-RNTI configured on the direct path and may only keep the C-RNTI configured on the indirect path. If there is only one C-RNTI stored in the Remote UE 10, the gNB / gNB-DU may send a RRCReconfiguration message to the Remote UE 10 via the indirect path to configure a new C-RNTI specially for the Remote UE 10 on the indirect path, so that the Remote UE 10 may have a valid C- RNTI for the legacy R17 L2 U2N relay operation.

[0158] In a variant of the previous embodiment, the indirect path serving gNB- DU (i.e., gNB-DU2 34) may allocate a new C-RNTI for the L2 U2N Remote UE 10. The gNB / gNB-CU may configure the newly allocated indirect path C-RNTI on the Remote UE 10. Upon receiving the configuration, the Remote UE 10 may configure and store the new C-RNTI for the indirect path, so that the Remote UE 10 may have a valid C-RNTI for the legacy R17 L2 U2N relay operation.

[0159] Inter-DU indirect path release for L2 U2N Remote UE operating in multi-path

[0160] In a variant of the previous embodiments, the L2 U2N Remote UE 10 operating in multi-path mode may measure the receiving signal quality on the PC5 link with the Relay UE 12, and / or the Relay UE 12 may measure the receiving signal quality on the Uu link on the serving cell of the indirect path and may detect the receiving signal quality either on PC5 link or Uu link to be below a pre-configured / com- mon / dedicated threshold, or a Radio Link Failure (RLF) may be detected on either the PC5 or Uu link of the Relay UE 12, then it may trigger the indirect path release procedure by the gNB. If there are two C-RNTIs stored in the Remote UE 10, the Remote UE 10 may discard the C-RNTI configured on the indirect path and may only keep the C-RNTI configured on the direct path for the Uu communications on the direct path. If there is one valid C-RNTI stored in the Remote UE 10, the Remote UE 10 and the gNB / gNB-DU may continue to use the current C-RNTI on the direct path for the communications on the direct path as a legacy UE.

[0161] In a variant of the previous embodiment, the direct path serving gNB- DU (i.e., gNB-DU1 32) may allocate a new C-RNTI for the L2 U2N Remote UE 10. The gNB / gNB-CU may configure the newly allocated direct path C-RNTI on the Remote UE 10. Upon receiving the configuration, the Remote UE 10 may configure and store the new C-RNTI for the direct path, so that the Remote UE 10 may have a valid C-RNTI for the legacy UE operation on the direct path.

[0162] Direct path release procedure for L2 U2N Remote UE operating in multi-path

[0163] In section 1 .7 of R2-2308950, the direct path release procedure for L2 U2N Remote UE operating in multi-path is discussed. It has been decided to leave the details of the contents in the RRCReconfiguration message for direct path release to stage 3.

[0164] In the stage 3 specification TS 38.331 , V18.0.0, in RRCReconfiguration message definition in clause 6.2.2, , for indirect path release, it is for further study whether to include an explicit "directPathRelease" flag in the reconfiguration procedure so that the UE can apply a simpler behaviour.

[0165] It has been proposed to introduce a “direct path release” flag in RRCReconfiguration message to release the direct path. However, this has not been agreed, and instead, it has been proposed that an explicit network indication (e.g. re- tainRelayPath) should be introduced for direct addition / change / release to indicate remote UE to maintain the PC5 unicast link with the source relay UE during Rel-17 I2D / D2I path switch procedures to maintain PC5 unicast link for indirect path in direct path addition / change / release procedure. The final agreement in RAN2 #125 meeting is that an explicit network indication is introduced for direct addition / change / release to indicate remote UE to maintain the PC5 unicast link with the source relay UE during Rel-17 I2D / D2I path switch procedures.

[0166] However, it is still not specified in the stage 3 specification on the details of contents in RRCReconfiguration message to release the direct path. It is an object of the following set of embodiments to resolve the issue of notifying the Remote UE to release the direct path.

[0167] In an embodiment that may be combined with any of the other embodiments or used independently, in direct path release procedure, the base station may send an RRCReconfiguration message to Remote UE operating in multi-path with direct path and indirect path working concurrently to release the direct path. The RRCReconfiguration message may contain an explicit or implicit network indication to indicate to the Remote UE to maintain the PC5 unicast link (e.g. explicit: retain Relay Path is set to true; implicit: a new C-RNTI for the PC5 link), and the RRCReconfiguration message may not contain any target serving cell information within spCellConfigCommon of reconfigurationWithSync or RRCReconfiguration message may not contain reconfigurationWithSync IE at all, in which case the Remote UE shall interpret this message by releasing the direct path in addition to maintaining the PC5 unicast link of the existing indirect path.

[0168] In another embodiment, in direct path release procedure, the base station may send a RRCReconfiguration message to Remote UE operating in multipath with direct path and indirect path working concurrently to release both the direct path and indirect path. The RRCReconfiguration message may contain an explicit or implicit network indication to indicate to the Remote UE to release the PC5 unicast link (e g. retainRelayPath is set to false), and the RRCReconfiguration message may not contain any target serving cell information within spCellConfigCommon of reconfigurationWithSync or RRCReconfiguration message may not contain reconfigurationWithSync IE at all, in which case the Remote UE shall interpret this message by releasing the direct path in addition to releasing the PC5 unicast link of the existing indirect path and releasing the indirect path thereof.

[0169] Thus, in accordance with a general definition of this embodiment, it is proposed a method for operating a UE, said UE operating in multi-path communication with a direct path and an indirect path in a communication network, the method comprising receiving from a base station a first RRC message for maintaining the indirect path, maintaining the indirect path and releasing the direct path upon determination of the absence of a target service in the message.

[0170] Alternatively, it is proposed a method for operating a UE, said UE operating in multi-path communication with a direct path and an indirect path in a communication network, the method comprising receiving from a base station a first RRC message for releasing the indirect path, releasing the indirect path and releasing the direct path upon determination of the absence of a target service in the message. Alternatively, it is proposed a method for operating a UE, said UE operating in multi-path communication with a direct path and an indirect path in a communication network, the method comprising receiving from a base station a first RRC message for releasing the direct path, maintaining the indirect path upon determination of the absence of target service in the message.

[0171] Alternatively, it is proposed a method for operating a UE, said UE operating in multi-path communication with a direct path and an indirect path in a communication network, the method comprising receiving from a base station a first RRC message for releasing the direct path, releasing the indirect path upon determination of the absence of target service in the message.

[0172] Configuring C-RNTI for L2 U2N Remote UE on the indirect path when direct path is released for L2 U2N Remote UE operating in multi-path

[0173] In TS 38.331 , V18.0.0, in clause 6.3.5, the Conditional Presence FirstRRCReconfig is redefined as “This field is mandatory present in the first RRCReconfiguration for L2 U2N Remote UE when PCell is on indirect path, i.e. MP configuration is not present. Otherwise, the field is absent" from what is defined in TS 38.331 , V17.7.0, “This field is mandatory present in the first RRCReconfiguration. Otherwise the field is absent.”.

[0174] The main reason to have this change in Rel-18 is to make sure that in indirect path addition on top of direct path (i.e. MP configuration is present), the sl- UEIdentityRemote-r17 field in SL-L2RemoteUE-Config-r17 becomes absent, so that there will be no new C-RNTI configured for the L2 U2N Remote UE on the indirect path, and the C-RNTI on the direct path will not be overridden. In the other case for a Rel-17 L2 U2N Remote UE not operating in multi-path, i.e., PCell is on indirect path and MP configuration is not present, the sl-UEIdentityRemote-r17 field in SL- L2RemoteUE-Config-r17 becomes mandatory, so that a C-RNTI is ensured to be configured for the L2 U2N Remote UE on the indirect path. □ 9

[0175] However, the RAN2 agreement of “An explicit network indication is introduced for direct addition / change / release to indicate remote UE to maintain the PC 5 unicast link with the source relay UE during Rel-17 I2D / D2I path switch procedures." agreed at RAN2 #125 meeting may imply the RRCReconfiguration message configured on a Remote UE operating in multi-path to release the direct path may not include sl-UEIdentityRemote-r17 in SL-L2RemoteUE-Config-r17 to configure the Remote UE at all according to the Conditional Presence FirstRRCReconfig for sl- UEIdentityRemote-r17 in SL-L2RemoteUE-Config-r17 “This field is mandatory present in the first RRCReconfiguration for L2 U2N Remote UE when PCell is on indirect path, i.e. MP configuration is not present. Otherwise the field is absent.", because direct path is not released yet when RRCReconfiguration message is configured on the Remote UE, and PCell is still on direct path. As a result, the L2 U2N Remote UE may not have any valid C-RNTI configured on the indirect path commonly agreed between the Remote UE and the network after direct path is released and the L2 U2N Remote UE operates in the Rel-17 L2 U2N Remote UE case. An object of the following embodiment is to resolve the issue of configuring a C-RNTI for an L2 U2N Remote UE on the indirect path after direct path is released and the L2 U2N Remote UE operates in Rel-17 L2 U2N Remote UE case.

[0176] In an embodiment that may be combined with any of the other embodiment or used independently, the RRCReconfiguration message may include a new sl-UEIdentityRemote-r18 field to configure Remote UE’s C-RNTI on the indirect path when or once the direct path is released and Remote UE operates in Rel-17 L2 U2N Remote UE case. This means that the Remote UE may only apply said C-RNTI after direct path release.

[0177] In an embodiment variant, the Conditional Presence FirstRRCReconfig for sl-UEIdentityRemote-r17 in SL-L2RemoteUE-Config-r17 may be rephrased to be mandatory present for the case of direct path release for Multi-path (MP) Remote UE when PCell is on direct path and to be mandatory present for the first RRCReconfiguration for L2 U2N Remote UE when PCell is on indirect path, i.e. MP configuration is not present.

[0178] In an embodiment variant, the network may send another RRCReconfiguration message to L2 U2N Remote UE after direct path is released, and the RRCReconfiguration message includes sl-UEIdentityRemote-r17 in SL-L2Re- moteUE-Config-r17 to configure C-RNTI for L2 U2N Remote UE on the indirect path. In another embodiment variant, the L2 U2N Remote UE includes a policy to apply a given C-RNTI when the direct path is released, e.g., it may apply the existing C-RNTI in the indirect path, or it may apply another previously received C- RNTI when the direct path is released.

[0179] Support more than one indirect path

[0180] In an embodiment that may be combined with any of the other embodiments or used independently, the multi-path L2 U2N Remote UE 10 may connect to the gNB over more than one L2 U2N Relay UE 12 which may be served by different gNB-DUs. As a result, there may be more than one indirect path between the L2 U2N Remote UE 10 and the gNB / gNB-CU. The SL-Multi PathConfig IE (or similar IE) may then be defined as below:

[0181] Selection of a single RNTI by the access devices

[0182] Fig. 5 shows a diagram according to an embodiment that may be combined with any of the other embodiments or may be used independently. The diagram shows a proposed signalling and processing procedure of the inter-DU indirect path addition on top of direct path for the multi-path L2 U2N Remote UE 10, which involves the gNB-CU 30 and the gNB-DUs 32, 34 to synchronize the allocated C- RNTI values in NG-RAN nodes.

[0183] The initial steps S501 to S527 are similar to the above steps S301 to After the gNB-CU 30 receives in step S528 the allocated C-RNTI (i.e. , C-RNTI2) from the gNB-DU2 34 serving the indirect path, the gNB-CU 30 knows that the Remote UE 10 is a multi-path capable UE from radio capability indication in the initial access / attach (e.g. using a field remoteUE-MultiPathOperation-L2 contained e.g. in the RelayParameters IE as described earlier) and it adds an indirect path on top of the direct path, so it may synchronize the indirect path with the direct path by instructing in step S529 the gNB-DU2 34 serving the indirect path to use the C-RNTI value allocated by the gNB-DU1 32 serving the direct path. Thus, the C-RNTI value is synchronized with the gNB-DU2 34 to C-RNTI1 . Then, the gNB-CU 30 may use the legacy R17 sidelink relay procedure to send in step S530 an RRCReconfigura- tion message including C-RNTI1 to configure C-RNTI (i.e., C-RNTI1 ) on the indirect path. Even though the Remote UE 10 may thus only configure and store one C- RNTI, because the C-RNTI value (i.e., C-RNTI1 ) has already been synchronized between the direct path serving gNB-DU1 32 and the indirect path serving gNB-DU2 34, the Remote UE 10 may still have the right C-RNTI to check and decode PDCCH / DCI scheduling information transmitted by the direct path serving gNB-DU1 32. By using this procedure, the same C-RNTI value may be used (i.e., shared) for both the direct path and indirect path. The benefit is that the Remote UE 10 may only need to store and use a single C-RNTI, and that it does not impact the legacy R17 sidelink procedure.

[0184] In an embodiment variant, the gNB-DU1 32 and the gNB-DU2 34 in Fig. 5 may agree on the C-RNTI to be used for the communication with the Remote UE 10 over the direct and indirect paths. This agreement may be done directly or indirectly, this agreement may be coordinated by the gNB-CU 30 or done in a distributed manner by both gNB-DUs 32, 34. The gNBs may also inform the Remote UE 10 about the fact that the C-RNTI is used for communication over both the direct and indirect paths and the Remote UE 10 may store said configuration.

[0185] In an example, if the gNB-DU1 32 is in charge of the direct path and the gNB-DU2 34 is in charge of the indirect path, and the gNB-DU2 34 may allocate a new C-RNTI to the Remote UE 10 for the indirect path, the gNB-DU2 34 may indicate the allocated C-RNTI to the gNB-DU1 32. This indication may be done through the gNB-CU 30, e.g., through the F1 interface which is a point-to-point interface between endpoints (which means a point-to-point logical interface) and which supports Control Plane (CP) and User Plane (UP separation between the radio network layer and the transport network layer to enable exchange of UE-associated information and non-U E-associated information. In this case, the gNB-DU2 34 may provide the indication of the determined C-RNTI, update the gNB-CU 30, and the gNB-CU 30 may inform the gNB-DU1 32. The gNB-CU 30 may then request the Remote UE 10 to start using the new C-RNTI or may start using said C-RNTI for the Remote UE 10 directly if the gNB-DU2 34 is the one assigning said C-RNTI to the Remote UE 10. gNB-DU1 32 may use the assigned C-RNTI for subsequent procedures with the Remote UE. Additionally or alternatively, a direct interface between the gNB-DU1 32 and the gNB-DU2 34 may be defined and used, instead of communicating via the gNB-CU 30. In this case, this interface may then be used to directly exchange said information between both gNB-DUs 32, 34.

[0186] In a further example, the gNB-DU1 32 may inform the gNB-DU2 34 about the C-RNTI in use by the Remote UE 10. The gNB-DU2 34 may then allocate said C-RNTI to the Remote UE 10. If said C-RNTI was used by the gNB-DU2 34 for addressing any other UE, the gNB-DU2 34 may reallocate a new C-RNTI' to the other UE.

[0187] In a further example, when the gNB-DU1 32 or the gNB-DU2 34 informs each other, they may also include an implicit or explicit time or context that determines when to start using the allocated or used or determined C-RNTI. This has the benefit of synchronizing the change / switch of C-RNTIs.

[0188] In a further example, the gNB-DU1 32 and the gNB-DU2 34 may have a fixed allocated range of C-RNTIs for multi-path communication over a direct and indirect path.

[0189] In a further example, the multi-path L2 U2N Remote UE 10 may connect to the gNB1 on the direct path and may connect to the gNB2 on the indirect path. gNB1 and gNB2 may be two different base stations 20. gNB1 may configure a C-RNTI (i.e. , C-RNTI1 ) on the direct path, and gNB2 may configure a C-RNTI (i.e. , C-RNTI2) on the indirect path using legacy procedure. gNB1 and gNB2 may be interconnected to exchange messages in the two directions, e.g., using the XnAP protocol.

[0190] In an embodiment that may be combined with any of the other embodiments or used independently, if a C-RNTI is selected / allocated / proposed to be used by a gNB-DU, then the gNB-CU or another gNB-DU that may receive the C-RNTI may detect that the C-RNTI is already in use. If it determines that the C-RNTI is not used or not to be used for multi-path relay communication, then it may send a message to the gNB-CU / gNB-DU that selected / allocated / proposed the C-RNTI to reject the C-RNTI and / or ask for a different C-RNTI. Additionally or alternatively, the gNB- CU or gNB-DU that receives the C-RNTI (i.e. , C-RNTI1 ) and detects that C-RNTI1 is already in use for a UE may resolve the conflict by allocating a different C-RNTI2 to the UE that is currently served by the respective C-RNTI.

[0191] In embodiments, a radio network identifier may be selected - e.g.,by a second access device -- for communication with a UE over a direct path managed by a first access device and an indirect path managed by a second access device wherein: the second access device determines a radio network identifier for communication with the UE, the second access device informs the first access device about the radio network identifier, the second access device starts using the radio network identifier for the communication with the UE over the indirect path.

[0192] In embodiments, a radio network identifier may be communicated - e.g., by a first access device - for communication with a UE over a direct path managed by the first access device and an indirect path managed by a second access device wherein: the first access device determines a radio network identifier to be used for communication with the UE, the first access device informs the second access device about the radio network identifier.

[0193] Reporting of cell information by the access devices for multi-path

[0194] As described above, the multi-path L2 U2N Remote UE 10 may have one (primary) serving cell in the direct path under the gNB-DU1 32 and may have another (primary or secondary) serving cell in the indirect path through the L2 U2N Relay UE 12 under the gNB-DU2 34. Each serving cell may have a different cell ID. This may lead to a problem during a network registration procedure, or network service access procedure, or localization-based procedure where the procedure is based on the cell ID used to serve the UE (e.g., during the UE location reporting procedure as specified in clause 4.10 of 3GPP TS 23.502).

[0195] The following embodiments that may be combined with any of the other embodiments or used independently may address this problem.

[0196] In an embodiment, a network base station (e.g., the gNB-CU 30) or other access device may be configured (e.g., by means of a policy) or requested (e.g., using a Location Reporting Control message from an LMF or from the AMF) to report (e.g. in a Location Report) one or more cell IDs for multi-path communication of a U2N Remote UE in the UE location information reporting, upon which the gNB- CU 30 may report the serving cell ID and / or the one or more cell IDs of one or more network base stations (e.g., gNB-DUs 32, 34) involved in multi-path communication for a particular UE to the core network, e.g., to an AMF, GLMC, LMF. This allows the core network to, e.g., determine the location of the UE. The policy or request configured or transmitted to the network base station may also include a request / instruc- tion / condition on whether to include information about whether the reported cell ID corresponds to one of the direct or indirect paths, and / or whether to include all cel I- IDs for all network base stations in the report or only a subset thereof. Based on the policy or request, the network base station may include the requested information in its report to the core network.

[0197] In a related embodiment, a network base station may be configured or requested to report the primary cell’s cell ID to the core network. Regarding which serving cell may be configured as the primary cell and / or which serving cell needs to be reported, it may be decided by the 3GPP specification, such as the specification may specify to use the direct path’s primary serving cell as the primary cell of the multi-path L2 U2N Remote UE 10; it can also be decided by a configuration or request received from the 0AM and / or AMF.

[0198] In a related embodiment, a network base station may be configured or requested to report the cell ID of the cell that has the smallest coverage area from amongst the cell IDs of the multiple paths in multi-path communication (e.g., if one of the cells is from a network base station in a non-terrestrial network with a large coverage area, whereas another cell may be from a terrestrial network with a smaller coverage area).

[0199] In a related embodiment, a network base station may be configured or requested to report the cell ID of the cell that serves a Relay UE to which the Remote UE is connected via multi-path communication and that has the best signal to the Remote UE (e.g., for which the measurement reports received from the relay UE or remote UE have the highest SL-RSRP or SD-RSRP for the PC5 communication) and / or that has the smallest distance to the Remote UE (e.g. based on transmit power information or SL-RSRP or SD-RSRP or timing / timing advance reports (e.g., UE RX-TX), distance measurements from / between the Remote UE or Relay UE). This is because in case multiple Relay UEs are connected to the Remote UE, the one with the strongest signal is likely to be the closest one. The measurements or summary or report thereof may be reported by the network base station (e.g., as metadata) in addition to the reported cell ID(s).

[0200] In a related embodiment, the network base station may be configured or requested to report the cell ID of the cell that serves a Relay UE to which the Remote UE is connected via multi-path communication that has the least amount of hops between the Remote UE and the base station. To this end, the Relay UEs or Remote UEs may need to report the number of hops between themselves and the network, and / or the number of hops is determined by adding an attribute (e.g. hop counter) to one or more messages exchanged between the respective UE and the network whereby that attribute may be increased in value every time the message is forwarded. The number of hops between itself and the Remote UE may be reported by the network base station (e.g., as metadata) in addition to the reported cell ID(s).

[0201] In a related embodiment, a network base station may report both cell IDs of the direct path and indirect path or of two indirect paths to the core network. Furthermore, the network base station may also include additional information (metadata) related to the cell(s), such as one or more of cell size, coverage area, transmission power of transmission reception point (TRP), whether it is the cell for a direct or indirect path, the location and / or transmission power and / or coverage area of relay UEs in an indirect path, reference signal received power / strength of Uu interface of multi-path L2 U2N Remote UE 10 on the direct path, reference signal received power / strength of sidelink reference signal (SL-RSRP) and / or sidelink discovery reference signal (SD-RSRP) of the PC5 unicast link between the Remote UE 10 and the Relay UE 12, reference signal received power / strength of Uu interface of the L2 U2N Relay UE 12 with its connected serving cell, etc. in the report to the core network. Which information to include may be based on information in the policy or request (e.g., Location Reporting Control message) about which additional information should be included.

[0202] In a related embodiment, the additional information (metadata) may also include relay UE identification information, e.g., an identifier provided or maintained by the relay UE or an identifier of the relay UE stored in the radio access network (e.g. in a network base station). Examples of such identifiers include e.g., the NG-5G-S-TMSI (Temporary Mobile Subscriber Identity), 5G-GUTI (Globally Unique Temporary UE Identity) or 5G-SUCI (Subscription Concealed Identifier) or User Info / User Info ID.

[0203] In a related embodiment, the core network may use the additional information received from the network base station to determine the use of the reported cell ID(s). This has the advantage of improving the localization accuracy of a cellbased positioning procedure, e.g., it can be used to determine that the UE is located in, e.g., the intersection of the coverage area and / or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of both cells; or the intersection of the coverage area and / or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of the direct-path cell and the coverage area and / or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of the relay connected to the indirect- path cell. Or in case of two indirect paths, the intersection of the coverage area and / or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of a first indirect-path cell and the coverage area and / or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of the relay connected to a second indirect-path cell.

[0204] Additionally or alternatively, the network base station may determine which cel l-ID(s) to include in the report based on one or more of the above mentioned additional information and / or based on criteria defined in the policy or request.

[0205] In an embodiment, the reported cell ID(s) may be used (e.g., by a core network function such as AMF, LMF, GMLC) as an indication of UE / user’s location information, which may be further used for positioning of UE / user. In a further embodiment, the UE may request and be requested, e.g., by a network function in the core network, to perform a localization procedure based on its multi-path communication whereby the user equipment may be requested to transmit a measurement report related to the multi-path connection whereby the report may include the connection information including one or more of cell-ID of the access device (e g. network base station), access device coverage, reception power of the access devices, whether it is the access device for a direct or indirect path, the location and / or transmission power and / or coverage area of relay UEs in an indirect path, etc. related to the direct and indirect paths.

[0206] In a further embodiment, the reported cell ID(s) may be used by a core network function such as AMF to determine that one or more of the reported cell ID(s) (e.g., for the indirect paths) are located in another country or are located in an area with communication restrictions or are too far apart from other reported cell ID(s) (e.g., the cell ID reported for the direct path). In such case, the core network function may instruct (e.g., by providing a message via Next Generation Application Protocol (NG-AP) interface that provides a UE and an AMF via NAS signaling transport) the radio access network (e.g., one or more network base stations) to disconnect the UE from the one or more reported cell ID(s), e.g., that are located in another country or are located in an area with communication restrictions or are too far apart from other reported cell I D(s), etc. Additionally or alternatively, the core network function may instruct (e.g., by providing a message via NG-AP interface) the radio access network (e.g., one or more network base stations) to disable or not use multi-path communication for the respective UE, and may also include a condition (e.g., which cells should not be used for indirect path of a multi-path communication, or which area multi-path communication should be disabled or maximum distance between cells used for multi-path communication). Additionally or alternatively, the core network function (e.g., AMF) or radio access network (e.g., one of the network base stations) may request the UE to disconnect one or more of the paths used for its multi-path communication (e.g., by transmitting a NAS message to the UE that includes one or more cell-IDs, relay UE IDs, path IDs to disconnect from) and / or may request the UE to disconnect completely and register again to the network. Additionally or alternatively, the core network function (e.g., AMF) or radio access network (e.g., one of the network base stations) may request a UE (e.g. Remote UE or Relay UE) to disconnect one or more of the paths used for its multi-path communication (e.g. , by transmitting a NAS message to the UE that includes one or more cell-IDs, relay UE IDs, path IDs to disconnect from) and / or may request the UE to disconnect completely and register again to the network, if the number of hops between that UE and the radio access network exceeds a pre-configured number of hops.

[0207] In an embodiment that may be combined with any of the other embodiments or used independently, a network access device (e.g., the gNB-CU 30) may be configured (e.g., by means of a policy) or requested to not enable multi-path communication in certain areas (e.g., around the border of a country) and / or to not enable a certain path in multi-path communication if that path is in a different country from other paths in the multi-path communication and / or to not enable a certain path in multi-path communication if the cell used for that path exceeds a maximum distance or number of hops between that cell and other cells used for multi-path communication (e.g., the cell used for direct communication with the UE). This configuration or policy may be deployed by the 0AM or the AMF, e.g., the AMF may retrieve the location of a first access device and inform the first access device of the identity of a second access device with which it is allowed or disallowed to interact for a given communication service, e.g., enable a multi-path communication.

[0208] In an embodiment that can be combined with any of the other embodiments or used independently, NG-RAN may report either the cell information of direct path, or indirect path or both together with metadata information of the related cell information to the AMF / CN in the Location Report / UserLocationlnformation message of the NGAP protocol, and the UserLocationlnformationNR may be expanded to include the above information as below.

[0209] UserLocationlnformationNR ::= SEQUENCE { nR-CGI NR-CGI, tAI TAI, timestamp TimeStamp OPTIONAL, iE-Extensions ProtocolExtensionContainer { {UserLocationlnformationNR-ExtlEs} } OPTIONAL,

[0210] UserLocationlnformationNR-ExtlEs NGAP-PROTOCOL-EXTENSION ::= {

[0211] { ID id-PSCelllnformation CRITICALITY ignore EXTENSION NGRAN-CGI PRESENCE optional }|

[0212] { ID id-NID CRITICALITY reject EXTENSION NID PRESENCE optional }|

[0213] { ID id-NRNTNTAIInformation CRITICALITY ignore EXTENSION NRNTNTAIInformation PRESENCE optional }|

[0214] { ID id-MPDirectPathCelllnformation CRITICALITY ignore EXTENSION NGRAN-CGI PRESENCE optional )l

[0215] { ID id-MPIndirectPathCelllnformation CRITICALITY ignore EXTENSION NGRAN-CGI PRESENCE optional 1,

[0216] }

[0217] In another embodiment that can be combined with any of the other embodiments or used independently, a network base station may be configured or requested to report (e.g., in a Location Report such as UserLocationlnformationNR as described above, extended for this purpose) a (rough) location of a UE that is connected using multi-path communication via two or more direct and / or indirect paths, whereby the network base station possibly in cooperation with other network base stations may use the information of the one or more cell-IDs of the network base stations involved in the multi-path communication of the UE together with measurement reports related to the UE (e.g., received from the UE itself, from one or more relay UEs, or from one or more network base stations). In an example, the network base station may receive measurement information from a Remote UE and / or Relay UE used for one of the indirect paths to determine (rough) distance between the Relay UE and the Remote UE (e.g., based on transmit power information or SL-RSRP or SD-RSRP or timing / timing advance reports (e.g. UE RX-TX), distance measurements from / between the Remote UE or Relay UE). Additionally or alternatively, the network base station may obtain measurement information (e.g., from the Remote UE or one or more of the network base stations involved in the multi-path communication) related to the Remote UE’s or Relay UE’s direct communication path to one or more of the network base station involved in the multi-path communication, and may use this together with e.g. additional information (metadata) related to the cell(s), such as one or more of cell size, coverage area, transmission power of transmission reception point (TRP), location of the TRP, whether it is the cell for the direct or indirect path, to determine a (rough) distance between the Remote UE and one or more of the network base stations involved in the multi-path communication and / or to determine whether or not the Remote UE is located in: the intersection of the coverage area and / or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of both cells; or the intersection of the coverage area and / or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of the direct-path cell and the coverage area and / or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of the relay connected to the indirect- path cell. Or in case of two indirect paths, the intersection of the coverage area and / or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of a first indirect-path cell and the coverage area and / or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of the relay connected to a second indirect-path cell.

[0218] The network base station may report the acquired information about the (rough) distance between the Remote LIE and one or more Relay UEs or network base stations and / or whether the Remote UE is located in an intersection or certain radius from the center of the cell or other reference point to the core network (e.g., in a location report), and / or may determine a (rough) location of the Remote UE based on the acquired information (e.g., using trilateration or triangulation based on e.g. the (rough) distances or radiuses) and report the (rough) location of the Remote UE to the core network (e.g. in a location report)

[0219] Thus, more general, determination of the location of a user equipment connected over one or more direct paths managed by one or more first access devices and one or more indirect paths managed by one or more second access device, or two or more direct paths managed by two or more first access devices, or two or more indirect paths managed by two or more second access devices, may be achieved by:

[0220] - requesting a connection information related to the user equipment, where the connection information may include one or more of cell-ID of the access device, access device coverage, transmission power of the access device, (rough) location of the user equipment or (rough) dis- tance / angle to one or more access devices, whether the reported cell- ID is from the access device for the direct or an indirect path, the location and / or transmission power and / or coverage area of relay devices in the indirect path, or related measurement information (e.g., RSRP, timing / timing advance information) or (rough) distance / angle to one or more relay devices, etc. related to the direct and indirect paths,

[0221] - receiving the connection information reports related to the direct and indirect paths, and

[0222] - determining the location of the user equipment.

[0223] In general, this may be implemented in a user equipment for determining the location of the user equipment connected over a direct path or indirect path to a first access device and over an indirect path to a second access device , by configuring the user equipment to:

[0224] - send a localization request to a core network or receive a localization request from the core network indicating a localization method based on the multi-path direct and indirect connections to the first and second access devices,

[0225] - send a connection information report to the core network including one or more of cell-ID of the access device, access device coverage, reception power of the access devices, whether it is the access device for a direct or indirect path, the location and / or transmission power and / or coverage area of relay devices in an indirect path, etc. related to the direct and indirect paths.

[0226] Reporting of cell information by the access devices for non-multi-path

[0227] Several of the above described extensions to location reporting in case of multi-path relaying may also be useful for improving the location reporting of a Remote LIE and / or Relay LIE involved in non-multi-path communication, e.g. using a single indirect connection between a Remote UE and a base station via one or more U2N Relay UEs (whereby each Relay UE may add an additional hop in a multiple hop relay connection). Therefore in an embodiment that may be combined with any of the other embodiments or used independently, the network base station may be configured or requested to report (e.g., in a Location Report such as UserLocationln- formationNR as described above, extended for this purpose) the cell ID of the cell that serves a Relay UE to which the Remote UE is connected via an indirect communication via one or more hops, whereby the number of hops between itself and the Remote UE may be reported by the network base station (e.g., as metadata) in addition to the reported cell ID(s). Additionally or alternatively, the network base station may be configured or requested to report an identifier of one or more of the Relay UEs involved in the indirect connection between the Remote UE and the respective base station.

[0228] To this end, the Relay UEs or Remote UEs may need to report the number of hops between themselves and the network, and / or the number of hops may be determined by adding an attribute (e.g. hop counter) to one or more messages exchanged between the respective UE and the network whereby that attribute may be increased in value every time the message is forwarded. Furthermore, the Relay UEs or Remote UEs may need to report an identifier of the Relay UE to which it is connected in the indirect path, and / or the identifiers for the Relay UEs on the indirect path may be determined by adding an atttribute (e.g. list of Relay UE identifiers) to one or more messages exchanged between the respective UE and the network. Thus, every relay UE that forwards the message may add its own identifier to that attribute. A relay UE identifier could be an identifier provided or maintained by the relay UE or an identifier of the relay UE stored in the radio access network (e.g. in a network base station). Examples of such identifiers include e.g., the NG-5G-S-TMSI (Temporary Mobile Subscriber Identity), 5G-GUTI (Globally Unique Temporary UE Identity) or 5G-SUCI (Subscription Concealed Identifier) or User Info / User Info ID.

[0229] Additionally or alternatively, the core network function (e.g., AMF) or radio access network (e.g., one of the network base stations) may request a UE (e.g. Remote UE or Relay UE) to disconnect its indirect communication path (e.g., by transmitting a NAS message to the UE that includes one or more cell-IDs, relay UE IDs, path IDs to disconnect from) and / or may request the UE to disconnect completely and register again to the network, if the number of hops between that UE and the radio access network exceeds a pre-configured number of hops.

[0230] On the security implications of a maintained PC5 unicast link on direct path addition / chanqe on top of unchanged indirect path

[0231] In certain scenarios, the U2N direct / indirect paths may be added or changed.

[0232] Fig. 6 schematically shows a signaling and processing diagram for indirect path change under a single procedure, involving a Remote UE (REM-UE), a source Relay UE (S-REL-UE), a target Relay UE (T-REL-UE) and gNB or other network access advice.

[0233] In step S600, the source Relay UE is used to provide an indirect path (UL / DL IDP) for UL / DL data between the Remote UE and the gNB on top of a direct path (UL / DL DP) between the Remote UE and the gNB.

[0234] Then, in step S601 , information (MCR) for measurement, configuration and reporting is exchanged between at least some of the Remote UE, the source Relay UE, the target Relay UE and the gNB. Based on the exchanged information, the gNB may decide in step S602 to change the indirect path (DEC CHG IDP), e.g., triggered by non-sufficient transmission quality or the like. As a result, the gNB transmits respective RRC reconfiguration messages (RRC RECON) to the source Relay UE and the target Relay UE (that may have selected based on the exchanged information or other available information about potentially available Relay UEs) in steps S603a and S603b. Additionally, the gNB transmits an additional RRC reconfiguration message to the Remote UE in step S604.

[0235] In step S605, an RRC connection establishment (PC5-RRC CON EST) is performed between the Remote UE and the target Relay UE via the PC5 interface. In response, respective RRC reconfiguration complete messages (RRC RECON COMPL) are sent in steps S606a and S606b from the Remote UE to the gNB via the direct path and the indirect path (via the target Relay UE) to the gNB. Then, as a result, UL / DL data can be exchanged in step S607 between the UE and the gNB using the direct path (UL / DL DP-D) and a new indirect path (UL / DL IDP-D) via the target Relay UE.

[0236] Fig. 7 schematically shows a still further signaling and processing diagram for direct path change under a single procedure, involving a Remote UE (REM- UE), a Relay UE (REL-UE), and a gNB or other access device that controls a source primary Cell (PCell) (S-PC), the Relay UEs serving cell (REL-UE-SC) UE and a target PCell (T-PC).

[0237] In a handover scenario as shown in Fig. 7, a cell change may be triggered by layer 3 (L3) measurements and may be done by RRC signaling (i.e. , reconfiguration with synchronization information element) for change of a PCell.

[0238] In step S700, a direct path (UL / DL DP) between the Remote UE and the source PCell of the gNB is provided. In addition, the Relay UE is used to provide an indirect path (UL / DL IDP) for UL / DL data between the Remote UE and the gNB’s serving cell of the Relay UE.

[0239] Then, in step S701 , information (MCR) for measurement, configuration and reporting is exchanged between at least some of the Remote UE, the Relay UE, the source PCell and the Relay UE’s serving cell. Based on the exchanged information, the gNB may decide in step S702 to change the PCell of the indirect path (DEC CHG PC) from the source PCell to the target PCell, e.g., triggered by non-suf- ficient transmission quality or the like. As a result, an RRC reconfiguration operation (RRC RECON) is performed in step S703 between the Relay UE and the Relay UE’s serving cell of the gNB. In response, the source PCell of the gNB transmits an RRC reconfiguration messages (RRC RECON MSG) with information about the target PCell to the Remote UE. In response thereto, the Remote UE initiates in step S705 a random access operation (RAN ACC TC) towards the target PCell. After completion of the random access operation, the Remote UE transmits respective RRC reconfiguration complete messages (RRC RECON COMPL MSG) to the target PCell in step S706a and to the Relay UE’s serving cell in step S706b.

[0240] Then, as a result, UL / DL data can be exchanged in step S707 between the UE and the gNB using the new direct path (UL / DL DP-D) to the target PCell and the indirect path (UL / DL IDP-D) via the Relay UE to the Relay UE’s serving cell.

[0241] As an exemplary challenge e.g. for the direct path addition / change procedure of Fig. 7, a PCell handover (HO) procedure with RRCReconfiguration- WithSync may be used to camp to the target PCell. RRCReconfiguration With Sync may allow performing masterKey Update so that the L2 U2N Remote UE may be configured to use a new set of cryptographic keys for data / signaling radio bearers (SRBs / DRBs) after PCell HO, i.e., direct path addition / change, and start to transmit data with new keys in the PDCP. However, it may be possible that some data which was protected by the old set of keys on the indirect path may have been transmitted on the indirect path and stay in the PDCP buffer at the access device, or the data still stays in the PDCP RLC buffer of the Relay UE and will be transmitted to the gNB later. In this case, the access device may not be able to security process those packets anymore because it now has the new set of keys.

[0242] Another particular challenge in the above procedures of Figs. 6 and 7 for path addition and / or change relates to how security keying materials, e.g., AS keys, can be updated and how protected information that may have been already exchanged can be processed. A change of keys may lead to a situation in which one of the end points receives some information that is protected with cryptographic keys that are not valid / available anymore because keys were updated.

[0243] Fig. 8 schematically shows a signaling and processing diagram for key update. In an example, this key update procedure may be related to a dual connectivity procedure as defined e.g. in Clause 6.10 in TS 33.501.

[0244] The dual connectivity procedure involves security functions for supporting a UE that is simultaneously connected to more than one NG-RAN node (e.g., multi-radio dual connectivity (MR-DC) with 5GC as described in TS 37.340), wherein the UE may be connected to one node (e.g., a ng-eNB) that acts as a master node (MN) and one node (e.g., a gNB) that acts as a secondary node (SN). In an example, The SN may be connected to the 5GC and the MN may be connected to the SN via an Xn interface.

[0245] When the MN is executing an SN addition procedure (i.e. , initial offload of one or more radio bearers to the SN), or an SN modification procedure (e.g., as in clauses 10.2.2 and 10.3.2 in TS 37.340) which requires an update of a key KSN for the SN, the MN may derive the KSN (e.g., as defined in clause 6.10.3.2). The MN may maintain a SN counter (e.g., as defined in clause 6.10.3.1 ).

[0246] When executing the procedure for adding subsequent radio bearer(s) to the same SN, the MN may, for each new radio bearer, assign a radio bearer identity that has not previously been used since the last KSN change. If the MN cannot allocate an unused radio bearer identity for a new radio bearer in the SN, e.g., due to radio bearer identity space exhaustion, the MN may increment the SN counter and compute a fresh KSN and may then perform a SN modification procedure to update the KSN.

[0247] The dual connectivity procedure with activation of encryption / decryp- tion and integrity protection follows the steps outlined in Fig. 8.

[0248] In step S801 , the UE and the MN establish an RRC connection (RRC CON EST). Then, in step S802, the MN sends an SN addition / modification request (SN ADD / MOD REQ) to the SN (e.g., over the Xn-C interface) to negotiate the available resources, configuration and algorithms at the SN. The MN computes and delivers the KSN to the SN if a new key is needed. The UE security capabilities (e.g., as in subclause 6.10.4) and the UP security policy received from the session management function (SMF) may also be sent to the SN. In case of a packet data unit (PDU) split, UP integrity protection and ciphering activation decision from MN may be also included (e.g., as described in subclause 6.10.4).

[0249] In step S803 (CAP NEG, UP PROT, AL SEL), the SN performs capability negotiation to allocate necessary resources and chooses a ciphering algorithm and integrity algorithm which has the highest priority from its configured list and is also present in the UE security capability. If a new KSN was delivered to the SN, then the SN calculates the needed RRC. User plane (UP) keys may be derived at the same time when the RRC key is derived. The SN may also activate the UP security policy (e.g., as described in subclause 6.10.4). In step S804, the SN sends an SN addition / modification acknowledge (SN SDD / MOD REQ ACK) to the MN indicating availability of requested resources and identifiers for the selected algorithm(s) for the requested data radio bearers (DRBs) and / or signaling radio bearer (SRB) for the UE. In addition, the UP integrity protection and encryption indications may be sent to the MN.

[0250] In step S805, the MN sends an RRC connection reconfiguration request (RRC CON RECON) to the UE instructing it to configure the new DRBs and / or SRB for the SN. The MN may include the SN counter parameter to indicate that a new KSN is needed and the UE may compute the KSN for the SN. The MN forwards the UE configuration parameters (which contain the algorithm identifier(s) received from the SN in step S804), and UP integrity protection and encryption indications (received from the SN in step S804) to the UE (cf. subclause 6.10.3.3 for further details).

[0251] In step 806, the UE accepts the RRC connection reconfiguration request after validating its integrity. The UE may compute the KSN for the SN if an SN counter parameter was included. The UE may also compute the needed RRC and UP keys and activate the RRC and UP protection as per indications received for the associated SRB and / or DRBs respectively. The UE then sends an RRC reconfiguration complete (RRC CON RECON COMPL) to the MN. The UE may activate the chosen encryption / decryption and integrity protection keys with the SN at this point.

[0252] In step S807, the MN sends an SN reconfiguration complete (SN RECON COMPL) to the SN (e.g., over the Xn-C interface) to inform the SN of the configuration result. On receipt of this message, the SN may activate the chosen encryption / decryption and integrity protection with UE in steps S806a and S807a (ACT CIPH + IN-PRO). If SN does not activate encryption / decryption and integrity protection with the UE at this stage, the SN may activate encryption / decryption and integrity protection upon receiving a random access request from the UE in step S808 (RAN ACC PROC).

[0253] In an embodiment that may be combined with any of the other embodiment or used independently, for regular user data (e.g. data send in the UP, e.g. using IP), the access device (e.g., gNB) may be configured with a policy determining that UP data that cannot be securely processed is to be discarded, while the end points (Remote UE and / or access device) may send a request triggering the retransmission. In a further embodiment, the end points (Remote UE and / or access device) may be configured (e.g., by means of a policy) with a small time or counter window that determines the time that needs to pass before discarding old keys and / or enabling new keys. This may allow having two sets of keys active at the same time and may allow processing data that may have been protected with the old keys when the new set of keys is already active. The configuration may also determine which keys should be used first, e.g., the old keys.

[0254] In a further embodiment, prior to execution of a key update command, an old U2N relay (e.g., Relay UE) may be instructed to release the connection (so that all buffered RLC messages are released).

[0255] In a further embodiment, prior to execution of a key update command, the access device (e.g., gNB) may be required to empty the PDCP buffer and only then indicate to the Remote UE the new path / set of keys.

[0256] In a further embodiment, upon execution of a key update command, the Remote UE may be configured to send the RRC reconfiguration complete message over the direct path, and not over the indirect path. This has the advantage of making sure that the message is not kept in the buffer of the U2N relay and cannot be processed correctly.

[0257] In a further embodiment, once the Remote UE sends the RRC reconfiguration complete message, the Remote UE may be configured to only send data over the direct path until a timer expires and / or data is received through the indirect path. This has the advantage of making sure that the message is not kept in the buffer of the U2N relay and cannot be processed correctly.

[0258] While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive. The invention can be applied to various types of UEs or terminal devices in various types of wireless networks, such as mobile phone, vital signs monitoring / telemetry devices, smartwatches, detectors, vehicles (for vehicle-to-vehicle (V2V) communication or more general vehicle-to-eve- rything (V2X) communication), V2X devices, Internet of Things (loT) hubs, loT devices, including low-power medical sensors for health monitoring, medical (emergency) diagnosis and treatment devices, for hospital use or first-responder use, virtual reality (VR) headsets, etc. Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. 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. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in the text, the invention may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being redefined herein to be restricted to include any specific characteristics of the features or aspects of the invention with which that terminology is associated. Additionally, the expression “at least one of A, B, and C” is to be understood as disjunctive, i.e., as “A and / or B and / or C”.

[0259] A single unit or device may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0260] The described operations like those indicated in the above embodiments may be implemented as program code means of a computer program and / or as dedicated hardware of the related network device or function, respectively. The computer program may be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

CLAIMS1. A communication device in a wireless network, wherein the device supports multi-path communication, the communication device being adapted to:- connect to a first access device through a direct path if the communication device is in coverage of the first access device; and- connect to a second access device through an indirect path via another device, in particular a relay device; and- receive a first configuration information from the first or second access device either through the direct path or through the indirect path or both, wherein the first configuration information includes at least a parameter about a first radio network temporary identifier, RNTI, assigned to the direct path for use by the first access device to transmit a scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, uplink and / or sidelink; and- receive a second configuration information from the first or second access device through the direct path and / or through the indirect path, wherein the second configuration information includes a parameter about a second RNTI assigned to the indirect path, and- use the first RNTI to decode the scheduling information transmitted from the first access device or use the second RNTI to decode the scheduling information transmitted from the first access device whilst performing multi-path communication, depending on the received first and second configuration information.

2. The communication device of claims 1 , wherein the second configuration information further includes one or more of the following parameters:- an optional parameter indicating that the second RNTI can be used instead of the first RNTI to receive and / or decode information from the first access device, or- an optional parameter indicating that the first RNTI needs to be used instead of the second RNTI to receive and / or decode information from the first access device, or> >- an optional parameter indicating a time to use or to switch between the first RNTI and second RNTI to receive and / or decode information from the first access device.

3. The communication device of claim 1 or 2, wherein the first and second configuration information is combined in a single message.

4. The communication device of claim 1 , 2, or 3, wherein the communication device stores both the first and second RNTIs.

5. The communication device of claim 4, wherein the communication device is configured to select which of the first RNTI and the second RNTI to use or to switch between the first RNTI and second RNTI based on received optional parameters.

6. The communication device of any of the previous claims, wherein the first and / or second configuration information indicates the number of RNTIs to be used and stored and / or a communication purpose of an RNTI.

7. The communication device of any of the previous claims, wherein the first access device and the second access device, to which the communication device is connected, are the same access device.

8. The communication device of any of the previous claims, wherein the communication device is connected to the first access device and the second access device, said first and second access devices being different distributed units belonging to the same centralized unit of a single access device.

9. The communication device of any of the previous claims, wherein the first RNTI and the second RNTI are both cell-RNTIs.

10. The communication device of any of the previous claims, being further adapted to:send a localization request to a core network or receive a localization request from the core network indicating a localization method through the direct and indirect paths to the first and second access devices, respectively, send a connection information report to the core network including one or more of an access device cell identity, an access device coverage, an access device reception power, information about whether an access device is used for the direct or the indirect path, a location and / or transmission power and / or coverage area of one or more relay devices in the indirect path, related to the direct and indirect paths.11 . The communication device of any of the previous claims, being configured with a time or counter window that determines a time that needs to pass before discarding old encryption keys and / or enabling new encryption keys.

12. The communication device of any of the previous claims, being configured to instruct a relay to release a connection of the indirect path prior to the execution of a key update command.

13. The communication device of claim 12, being configured to send a reconfiguration complete message over the direct path, but not over the indirect path, when the key update command is executed.

14. The communication device of claim 13, being further configured to send data over the direct path until a timer expires and / or data is received through the indirect path.

15. An access device in a wireless network, wherein the access device supports multi-path communication with a communication device, the access device being adapted to:- connect to the communication device through a direct path if the communication device is in coverage of the access device; and- connect to the communication device through an indirect path via another device, in particular a relay device; and- determine that the communication device via each of the direct path and the indirect path is the same device; and- generate and send configuration information to the communication device through the direct path and / or through the indirect path, wherein the configuration information includes at least a parameter about a radio network temporary identifier, RNTI, which may be used by the access device to transmit a scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, uplink and / or sidelink; and wherein the base station arranges for the RNTI to be shared across both paths.

16. The access device of claim 15, being adapted to: generate and share a single RNTI across the direct path and the indirect path.

17. The access device of claim 15 or 16, further being adapted to: request a connection information report related to the communication device, where the connection information report includes one or more of an access device cell identity, an access device coverage, an access device transmission power, a rough location of the communication device or a rough distance and / or angle to one or more of the first and second access devices, information about whether a reported cell identity is from the first access device for the direct path or the second access device for the indirect path, a location and / or transmission power and / or coverage area of relay devices in the indirect path, or related measurement information, timing and / or timing advance information in particular, or a rough distance and / or angle to one or more relay devices, related to the direct and indirect paths, receive the connection information report related to the direct and indirect paths, and determine the location of the communication device.

18. The access device of any of claims 15 to 17, further being configured to discard user plane data that cannot be securely processed.

19. The access device of any of claims 15 to 18, further being configured to report a cell identity of a cell that serves a relay device to which thecommunication device is connected via multi-path communication and that has the best signal quality and / or the smallest distance to the communication device.

20. A wireless network comprising an access device as claimed any one of claims 15 to 19, and at least one communication device as claimed in any of claims 1 to 14.21 . A method for operating a communication device which supports multi-path communication, wherein the method comprising:- the communication device connecting to a first access device through a direct path if the communication device is in coverage of the first access device; and- the communication device connecting to a second access device through an indirect path via another device, in particular a relay device; and- the communication device receiving a first configuration information from the first or second access device through the direct path and / or through the indirect path, wherein the first configuration information includes at least a parameter about a first radio network temporary identifier, RNTI, assigned to the direct path for use by the first access device to transmit a scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, uplink and / or sidelink; and- the communication device receiving a second configuration information from the first or second access device through the direct path and / or through the indirect path, wherein the second configuration information includes a parameter about a second radio network temporary identifier, RNTI, assigned to the indirect path, and- the communication device using the first RNTI to decode the scheduling information transmitted from the first access device or use the second RNTI to decode the scheduling information transmitted from the first access device whilst performing multi-path communication, depending on the received first and second configuration information.

22. The method of claim 21 , wherein the second configuration information further includes one or more of the following parameters:- an optional parameter indicating that the second RNTI can be used instead of the first RNTI to receive and / or decode information from the first access device, or- an optional parameter indicating that the first RNTI needs to be used instead of the second RNTI to receive and / or decode information from the first access device, or- an optional parameter indicating a time to use or to switch between the first RNTI and second RNTI to receive and / or decode information from the first access device.

23. The method of claim 21 or 22, wherein the first and second configuration information is combined in a single message.

24. The method of claim 21 , 22 or 23, wherein the communication device stores both the first and second RNTIs.

25. The method of claim 24, wherein the communication device selects which of the first RNTI and the second RNTI to use, or switches between the first RNTI and the second RNTI based on received optional parameters.

26. The method of any of claims 21 -25, wherein the configuration information indicates the number of RNTIs to be used and stored, and / or a communication purpose of an RNTI.

27. The method of any of claims 21-26, wherein the communication device is connected to the first base station device and the second base station device, said first and second base station devices being different distributed units belonging to the same centralized unit of a single base station device.

28. The method of any of claims 21 to 27, wherein the first RNTI and the second RNTI are both cell-RNTIs.

29. The method of any of claims 21 to 28, further comprising:requesting by an access device a connection information report related to a communication device, where the connection information report includes one or more of an access device cell identity, an access device coverage, an access device transmission power, a rough location of the communication device or a rough distance and / or angle to one or more of the first and second access devices, information about whether a reported cell identity is from the first access device for the direct path or the second access device for the indirect path, a location and / or transmission power and / or coverage area of relay devices in the indirect path, or related measurement information, timing and / or timing advance information in particular, or a rough distance and / or angle to one or more relay devices, related to the direct and indirect paths, receiving from the communication device the connection information report related to the direct and indirect paths, and determining the location of the communication device.

30. A computer program product comprising code which once executed on a computer is adapted to generate instructions for executing the method of any of claims 21-29.

Images