Lateral link relay multipath relay apparatus and method of operating 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:-if the communication device is within the coverage of a first access device, connect to the first access device through a direct path; and-connecting to a second access device via an indirect path via another device, in particular a relay device; and-receiving first configuration information from the first access device or the second access device over the direct path or over the indirect path or both, where the first configuration information comprises at least a parameter regarding a first Radio Network Temporary Identifier, RNTI, and-receiving the first configuration information from the first access device or the second access device over the direct path or over the indirect path or both. The first radio network temporary identifier, RNTI, is assigned to the direct path for the first access device to transmit scheduling information to the communication device over the direct path, and wherein the scheduling information may be a downlink, an uplink, and a sidelink; and-receiving second configuration information from the first access device or the second access device via the direct path and / or via the indirect path, where the second configuration information comprises parameters about a second RNTI assigned to the indirect path; and-decoding scheduling information transmitted from the first access device using the first RNTI or decoding scheduling information transmitted from the first access device using the second RNTI while performing the multipath communication in dependence on the received first and second configuration information.

Description

TECHNICAL FIELD

[0001] The present invention relates to sidelink relay multi-path relaying in 5G New Radio (NR) wireless communication systems. BACKGROUND

[0002] In the 3rd Generation Partnership Project (3GPP) New Radio (NR) Release 18 (R18) specification, Layer 2 (L2) UE-to-Network (U2N) sidelink relaying is enhanced to support multi-path relaying as defined in the Work Item Description (WID) RP-223501. An L2 U2N Remote User Equipment (UE) with multi-path relaying functionality within the network coverage of a base station can establish two communication paths with the same base station, i.e. a direct path directly via the NR Radio Air Interface (Uu interface) of the L2 U2N Remote UE and an indirect path via the L2 U2N Relay UE. However, in this specification, the case with multiple indirect paths without a direct path is also considered as multi-path relaying.

[0003] There are at least two use cases for L2 U2N sidelink relay multi-path relaying: - allowing the L2 U2N Remote UE to use split bearers / dual connectivity mechanisms to aggregate user traffic sent / received to / from the base station over the two paths; - allowing the L2 U2N Remote UE to use duplicated bearers / PDCP duplication to improve reliability and reduce latency for communication with the base station.

[0004] The scope of R18 L2 U2N sidelink relay multi-path relaying is limited to the case where the multi-path L2 U2N Remote UE is connected to the same base station (e.g. gNB and / or gNB-CU) on both the direct path and the indirect path, but in the 5G NR CU-DU split architecture, the two paths can belong to different serving cells and gNB-DUs.

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

[0006] In Release 17 (R17) sidelink relay, an L2 U2N remote UE can be connected to a gNB / gNB-CU on either the direct path or the indirect path but not both at the same time. The path switching 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 5G NR gNBCU-DU split architecture is defined in 3GPP specification TS 38.401 V17.5.0, clause 8.19.4.

[0007] TS 38.401 V17.5.0, clause 8.19.4.1 Figure 8 .19.4.1-1 describes the R17 L2 U2N remote UE direct-to-indirect path switching procedure in the inter-DU case as follows: Initially, the L2 U2N remote UE (i.e., a legacy UE within the coverage of a serving cell) is connected to the source gNB-DU and gNB-CU on the direct path.

[0008] The source gNB-DU will follow the UE initial access procedure defined in clause 8.1 of TS 38.401 V17.5.0 UE Initial Access procedure ) to allocate a cell radio network temporary identifier (C-RNTI) for the remote UE and inform the gNB-CU of the allocated C-RNTI, which the gNB-CU will then assign to the remote UE in the DL RRC MESSAGE TRANSFER message encapsulated in the RRCSetup message via the source gNB-DU. RRCSetup The masterCellGroup IE in the newUE-Identity message contains the field to configure the C-RNTI value for the remote UE with synchronous RRC reconfiguration.

[0009] Similarly, in the RRC reestablishment and / or RRC resume procedure, the source gNB-DU can follow a similar procedure to allocate a new C-RNTI for the remote UE and inform the gNB-CU of the allocated new C-RNTI, which the gNB-CU will then assign to the remote UE in the DL RRC MESSAGE TRANSFER message encapsulated in the RRCReestablishment and / or RRCResume message via the source gNB-DU, as defined in clauses 8.7 and 8.6.2 of TS 38.401 V17.5.0, respectively.

[0010] The source gNB-DU will use its assigned C-RNTI to scramble / mask the downlink control information (DCI) sent on the physical downlink control channel (PDCCH) for sending scheduling information for the physical downlink shared channel (PDSCH) / physical uplink shared channel (PUSCH) / physical uplink control channel (PUCCH) for the remote UE; and the remote UE will use the assigned C-RNTI to check the scrambled / masked DCI scheduling information on the PDCCH and detect if there is any scheduling assignment / grant from the source gNB-DU destined for this remote UE. In case of carrier aggregation where the remote UE can be connected to multiple serving cells (SCells) of a gNB-DU, the same C-RNTI assigned by the gNB-DU is used for PDCCH / DCI scrambling / masking and detection / checking.

[0011] The gNB-CU can then decide to switch the remote UE from the direct path to the indirect path after evaluating the measurement report from the remote UE.

[0012] In step 4, the gNB-CU requests the target gNB-DU serving the target relay UE to establish a new indirect path via UE CONTEXT SETUP REQUEST The message establishes the UE context for the remote UE.

[0013] In step 5, the target gNB-DU will return the new C-RNTI assigned for the remote UE in the UE CONTEXT SETUP RESPONSE message.

[0014] Then, in step 6, the gNB-CU will encapsulate the UE CONTEXT MODIFICATION message in the REQUEST message sent to the source gNB-DU. RRCReconfiguration The new C-RNTI is assigned to the remote UE in the RRCReconfiguration message, which the source gNB-DU will extract and forward to the remote UE over the direct path. This new C-RNTI value is carried in the RRCReconfiguration sl-L2RemoteUE-Config information element (IE) included in the sl- UEIdentityRemote field.

[0015] From now on, the remote UE (i.e., L2 U2N remote UE) is fully switched from the direct path to the indirect path. When a C-RNTI is needed, the remote UE will use the C-RNTI value newly assigned by the target gNB-DU on the indirect path.

[0016] However, in the case of inter-DU multi-path relaying, a multi-path L2 U2N remote UE (i.e., a multi-path remote UE) has connections to a gNB / gNB-CU both over a direct path and an indirect path via a respective serving gNB-DU at the same time. As 3GPP TDoc R3-230947 (Addition of indirect path over direct path inter-DU) shows in Figure 8 xx.2, if the same R17 sidelink relaying procedure is used, the new C-RNTI assigned by the gNB-DU2 on the indirect path (similar to the target gNB-DU in TS 38.401 V17.5.0 Figure 8 .19.4.1-1) will override the C-RNTI assigned by the gNB-DU1 on the direct path (similar to the source gNB-DU in TS 38.401 V17.5.0 Figure 8 .19.4.1-1). Then, the remote UE will use the updated new C-RNTI value as its current C-RNTI. However, the gNB-DU1 will continue to use the old C-RNTI to scramble / mask PDCCH / DCI for sending scheduling information for PDSCH / PUSCH / PUCCH to the remote UE on the direct path. As a result, the multi-path remote UE will not be able to successfully check and decode the scrambled / masked PDCCH / DCI scheduling information on the direct path with this new C-RNTI value. The direct path then completely fails. SUMMARY

[0017] From the above description of the problem, it is clear that in the inter-DU case, when an indirect path is added over a direct path, the C-RNTI assigned to a multi-path capable L2 U2N remote UE on the direct path will be overridden by the new C-RNTI assigned on the indirect path. This situation occurs 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 conventional R17 sidelink relaying path switching 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).

[0018] It is an object of the present invention to overcome this direct path C-RNTI override problem for a multi-path L2 U2N remote UE, so that the direct path of the multi-path does not fail due to a wrong C-RNTI assigned to the remote UE.

[0019] It is also an object of the present invention to provide a solution for how to perform location reporting for remote UE and / or relay UE, in particular in case of multipath relay communication.

[0020] It is also an object of the present invention to provide a method for improving security procedures in case of multipath relay communication.

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

[0022] According to a first aspect, a communication device (e.g. mobile, or fixed, or intermittently mobile and fixed UE) in a wireless network is provided, wherein the communication device supports multipath relay. The communication device can be adapted to: - connect to a first access device via a direct path, if the communication device is within a coverage area of the first access device; and - connect to a second access device via an indirect path via another device (e.g. a relay device); and - receive first configuration information from the first access device or the second access device via the direct path or via the indirect path or both, wherein the first configuration information comprises at least parameters regarding a first radio network temporary identifier (RNTI) assigned to the direct path for the first access device to send scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, uplink and sidelink; and - receive second configuration information from the first access device or the second access device via the direct path or the indirect path or both, wherein the second configuration information comprises parameters regarding a second radio network temporary identifier (RNTI) assigned to the indirect path, and - in dependence of the received first configuration information and second configuration information, use the first RNTI to decode scheduling information sent from the first access device or use the second RNTI to decode scheduling information sent from the first access device while performing multipath communication.

[0023] 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 multipath communication with a communication device according to the first aspect, the access device is adapted to: - connect to the communication device via a direct path, if the communication device is within a coverage area of the access device; and - connecting to the communication device through an indirect path via another device (e.g., a relay device); and - determining that the communication device via each of the direct path and the indirect path is the same device; and - generating and sending configuration information to the communication device via the direct path or the indirect path or both, wherein the configuration information comprises at least parameters on a radio network temporary identifier (RNTI) that can be used by the access device to send 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 the RNTI to be shared across both paths.

[0024] According to a third aspect, there is provided a wireless network comprising an access device according to the second aspect and at least one communication device according to the first aspect.

[0025] According to a fourth aspect, there is provided a method of operating a communication device supporting multi-path communication, wherein the method comprises: - if the communication device is within coverage of a first access device, the communication device connects to the first access device through a direct path; and - the communication device connects to a second access device through an indirect path via another device (e.g., a relay device); and - the communication device receives first configuration information from the first access device or the second access device through the direct path or through the indirect path or both, wherein the first configuration information comprises at least parameters on a first radio network temporary identifier (RNTI) that is assigned to the direct path for the first access device to send scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, uplink, and sidelink; and - the communication device receives second configuration information from the first access device or the second access device through the direct path or through the indirect path or both, wherein the second configuration information comprises parameters on a second radio network temporary identifier (RNTI) that is assigned to the indirect path, and - in accordance with the received first configuration information and second configuration information, the communication device decodes scheduling information sent from the first access device using the first RNTI or decodes scheduling information sent from the first access device using the second RNTI while performing multi-path communication.

[0026] Finally, according to a sixth aspect, there is provided a computer program product, which can comprise code means for producing the steps of the method according to the second aspect when run on a computer device.

[0027] According to a first option, which can be combined with any of the first to fifth aspects, the second configuration information can further comprise one or more of the following parameters: - an optional parameter indicating that the information from the first access device can be received and / or decoded using the second RNTI instead of the first RNTI, or - an optional parameter indicating that the information from the first access device needs to be received and / or decoded using the first RNTI instead of the second RNTI, or - an optional parameter indicating a time when the information from the first access device is to be received and / or decoded using the first RNTI and the second RNTI or indicating a time when to switch between the first RNTI and the second RNTI for receiving and / or decoding the information from the first access device.

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

[0029] According to a third option, which can be combined with the first or second option or any of the first to fifth aspects, the communication device can store both the first RNTI and the second RNTI.

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

[0031] According to a fifth option, which can be combined with any of the first to fourth options or any of the first to fifth aspects, the first configuration information and / or the second configuration information can indicate a number of RNTIs to use and store and / or a communication purpose of the RNTIs.

[0032] According to a sixth option, which can 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 can be the same access device.

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

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

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

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

[0037] According to an eleventh option, which can be combined with any of the first to tenth options or any of the first to fifth aspects, the communication device can be further adapted to: - send a positioning request to or receive a positioning request from the core network indicating a positioning method, respectively through a direct path to a first access device and an indirect path to a second access device, - send a connection information report to the core network, the connection information report comprising one or more of the following related to the direct and indirect paths: access device cell identity, access device coverage, access device received power, information on whether an access device is for a direct path or an indirect path, location and / or transmission power and / or coverage area of one or more relay devices in an indirect path.

[0038] According to a twelfth option, which can be combined with any of the first to eleventh options or any of the first to fifth aspects, the communication device can be configured with a time or counter window for determining a time that needs to elapse before discarding an old encryption key and / or enabling a new encryption key.

[0039] According to a thirteenth option, which can be combined with any of the first to twelfth options or any of the first to fifth aspects, the communication device can be configured to instruct a relay to release a connection of an indirect path before executing a key update command.

[0040] In an example of the thirteenth option, the communication device can be configured to transmit the reconfiguration complete message over the direct path but not over the indirect path when executing the key update command.

[0041] According to a fourteenth option, which can be combined with any of the first to thirteenth options or any of the first to fifth aspects, the communication device can be configured to transmit data over the direct path until expiry of a timer and / or until data is received over the indirect path.

[0042] According to a fifteenth option, which can be combined with any of the first to fourteenth options or any of the first to fifth aspects, the access device can be adapted to: request a connection information report related to the communication device, wherein the connection information report comprises one or more of the following related to the direct path and the indirect path: an access device cell identity, an access device coverage, an access device transmit power, a coarse position of the communication device, or a coarse distance and / or angle to one or more of the first access device and the second access device, information on whether the reported cell identity is from the first access device for the direct path or the second access device for the indirect path, a position and / or transmit power and / or coverage area of a relay device in the indirect path, or related measurement information, in particular timing and / or timing advance information, or a coarse distance and / or angle to one or more relay devices; receive the connection information report related to the direct path and the indirect path, and determine a position of the communication device.

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

[0044] According to a seventeenth option, which can be combined with any of the first to sixteenth options or any of the first to fifth aspects, the access device can be configured to report a cell identity of a cell serving a relay device to which the communication device is connected via the multi-path communication and having a best signal quality and / or a smallest distance to the communication device.

[0045] According to an eighteenth option, which can be combined with any of the first to seventeenth options or any of the first to fifth aspects, the method can further comprise: - the access device requests a connection information report related to the communication device, wherein the connection information report comprises one or more of the following related to the direct path and the indirect path: an access device cell identity, an access device coverage, an access device transmit power, a coarse position of the communication device, or a coarse distance and / or angle to one or more of the first access device and the second access device, information on whether the reported cell identity is from the first access device for the direct path or the second access device for the indirect path, a position and / or transmit power and / or coverage area of a relay device in the indirect path, or related measurement information, in particular timing and / or timing advance information, or a coarse distance and / or angle to one or more relay devices; - receiving the connection information report related to the direct path and the indirect path from the communication device, and - determining a position of the communication device.

[0046] It is noted that the above-described apparatus of the first aspect can be implemented based on discrete hardware circuitry with discrete hardware components, integrated chips or chip module arrangements, or based on signal processing means or chips controlled by software routines or programs stored in a memory, written on a computer readable medium or downloaded from a network such as the Internet.

[0047] It is to 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 can have similar and / or identical preferred embodiments, in particular as defined in the dependent claims.

[0048] It is further to be understood that preferred embodiments of the present application can also be any combination of the dependent claims or above embodiments with the corresponding independent claims.

[0049] These and other aspects of the present application are apparent from the description which follows, taken in connection with the accompanying drawings, and will be elaborated during the course of the description. BRIEF DESCRIPTION OF DRAWINGS

[0050] In the following drawings: Figure 1 A schematic diagram of a sidelink relay multi-path relay system is shown schematically; Figure 2 A schematic diagram of sidelink relay multi-path relaying in a gNB CU-DU split architecture is shown schematically; Figure 3Signaling and processing procedures for inter-DU indirect path addition over direct path of multi-path remote UE employing legacy sidelink relay path switch procedures are schematically illustrated; Figure 4 Signaling and processing procedures for inter-DU indirect path addition over direct path of multi-path remote UE according to embodiments are schematically illustrated; Figure 5 Another signaling and processing procedures for inter-DU indirect path addition over direct path of multi-path remote UE according to embodiments are schematically illustrated; Figure 6 Signaling and processing schematic for indirect path change under a single procedure are schematically illustrated; Figure 7 Signaling and processing schematic for direct path change under a single procedure are schematically illustrated; Figure 8 Signaling and processing schematic for key update are schematically illustrated. DETAILED DESCRIPTION

[0051] Various embodiments of the present invention are now described based on a 5G cellular network enabling UE-to-Network Relay functionality, wherein 4G network elements can be incorporated in the proposed 5G solution. Furthermore, at least some of the following embodiments are described based on the 5G NR radio access technology.

[0052] Throughout this disclosure, the abbreviation "gNB" (a 5G term) is intended to refer to access devices such as cellular base stations or Wi-Fi access points. A gNB is part of a Radio Access Network (RAN) that provides an interface to functions within the Core Network (CN). The RAN is part of a wireless communications network that implements Radio Access Technology (RAT). Conceptually, it resides between communication devices such as mobile phones, computers, or any remotely controlled machine and provides connectivity to its CN. The CN is the core part of the communications network that provides numerous services to customers interconnected via the RAN. More specifically, it directs communication flows through the communications network and possibly other networks. Furthermore, the 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 services. The AMF also manages the mobility of a UE when it roams from one gNB to another for session / service continuity. Additionally, Information Elements (IEs) specify (a set of) information that may be included within signaling messages or data streams sent through the interface (examples may include QoS (Quality of Service) definitions, setting parameters, user identifiers, etc.). Location Management Function (LMF) is a network entity defined in the 5G core network that provides positioning capabilities by determining the geographic location of mobile devices based on downlink, uplink, and sidelink location measurement radio signals. Additionally, the Gateway Mobile Location Center (GMLC) is used for active mobile positioning, meaning it triggers specific activities on the network to retrieve subscriber locations in real time. To improve positioning accuracy, the GMLC can connect to additional precise location components in the network. The GMLC may contain the functionality required to support LCS (Location Services). More than one GMLC can exist in a PLMN (Public Land Mobile Network). The GMLC is the first node for external LCS clients to access the network. Furthermore, the abbreviation "OAM" (Operation, Administration, and Management or Maintenance) is understood to specify the processes, activities, tools, and standards involved in operating, controlling, managing, and maintaining any system.

[0053] In 3GPP specifications 23.304 and 24.501 for 5G networks, the so-called Proximity Service (ProSe) functionality is defined to enable connectivity of cellular communication devices (e.g. UEs) that are temporarily not in the coverage of an access device (gNB) and others. This particular functionality is referred to as ProSe UE-to-Network Relay or Relay UE. A Relay UE is a communication device that helps another UE to communicate with a gNB (i.e. an access device) by relaying application and network data traffic in both directions between the other UE and the gNB. The local communication between the Relay UE and the other UE is referred to as D2D communication or sidelink communication or PC5 communication. The abbreviation "PC5" designates the interface for sidelink communication defined by ProSe. Furthermore, the abbreviation "UL" is used for the uplink direction from a communication device (e.g. UE) to an access device (e.g. gNB), the abbreviation "DL" is used for the downlink direction from an access device (e.g. gNB) to a communication device (e.g. UE), and the abbreviation "SL" is used for the sidelink communication between two or more communication devices (e.g. UEs). Once a relay relationship is established, a UE can be connected via the Relay UE and act in the role of a "Remote UE". This situation means that the Remote UE has an indirect network connection to the CN, instead of the normal case of a direct network connection (see 3GPP specification TS 22.261 v16.10.0).

[0054] Furthermore, 3GPP technical reports TR 23.733 v15.1.0 and TR 36.746 v15.1.1 provide a study on architecture enhancements to enable IoT devices (acting as Remote UEs) to operate with very low power, for example by connecting to a wider network using a Relay UE. Because the Relay UE is physically very close, very low power transmission can be used to reach the Relay UE. This work also includes security, speed and stability improvements to ProSe. These extensions of ProSe are referred to as Enhanced ProSe ("eProSe"). One proposed improvement in eProSe is an enhanced relay architecture that operates in the second protocol layer (i.e. L2), which aims to provide end-to-end Internet Protocol (IP) packet transport and Packet Data Convergence Protocol (PDCP) packet transport for application and / or user data to Remote communication devices. The benefit of this architecture is that the Remote communication devices become directly visible as registered entities in the CN, which is relevant for monitoring and billing purposes and for improved control of the communication devices by the access devices.

[0055] Furthermore, an element for implementing the scheduling mechanism can be the Radio Resource Control (RRC) protocol, which can operate end-to-end to the UE (potentially over one or more hops considering the above-mentioned relay architecture over a second protocol layer (i.e. L2)). Another element can be the use of Downlink Control Information (DCI), which is a short message sent in a low bit rate control channel (e.g. Physical Downlink Control Channel (PDCCH)) with special blindly detectable modulation or coding. Here, various DCI formats can be defined with different information content.

[0056] The following embodiments are described in connection with multi-path relay in sidelink relay in a 3GPP 5G NR wireless communication system, e.g. as shown in Figure 1

[0057] It is noted that throughout the present disclosure only those structural elements and functions are shown which are useful for understanding the embodiments. Other structural elements and functions are omitted for reasons of clarity.

[0058] Referring to Figure 1 , a multi-path L2 U2N Remote UE (REM-UE) 10 is connected to a base station (BS) 20 over a direct path (DP) and an indirect path (IP) at the same time, wherein the direct path comprises a Uu interface between the L2 U2N Remote UE 10 and the base station 20, and the indirect path comprises 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 the Remote UE 10 and the Relay UE 12 are located within a coverage area (COV) of the base station 20.

[0059] Figure 2 ​A schematic diagram of sidelink relay multi-path relaying in a Next Generation Radio Access Network (NG-RAN) CU-DU split architecture is shown schematically, where on a direct path (DP) a multi-path L2 U2N remote UE 10 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 in turn is 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 the same central unit gNB-CU 30 of the split architecture. A legacy L2 U2N relay UE 12 (3GPP R17) can indicate support for R17 L2 U2N relay functionality to the NG-RAN and AMF by using an indication field relayUE-Operation-L2-r17 ASN.1 IE included in the UE-NR-Capability ASN.1 IE defined in clause 6.3.3 of TS 38.331 V17.5.0.

[0060] In Figure 2 , it is assumed that the multi-path L2 U2N remote UE 10 first connects to the gNB-CU 30 via the gNB-DU1 32 on the direct path; during direct path establishment, the L2 U2N remote UE 10 indicates its support for R18 sidelink relay multi-path relaying to the gNB-CU 30 and the 5G core Access and Mobility Management Function (AMF, not shown) in a Non-Access Stratum (NAS) message in initial access / attach in a UERadioCapability IE; then at a later time, based on a measurement report received from the L2 U2N remote UE 10 on the direct path, the gNB-CU 30 decides to add an indirect path for the L2 U2N remote UE 10 to use multi-path relaying functionality. The selected indirect path is routed via a L2 U2N relay UE 12 served by the gNB-DU2 34, which is an inter-DU indirect path addition on top of the direct path procedure for the multi-path L2 U2N remote UE 10. NAS is a functional layer running between the UE and the CN, which supports traffic and signaling messages between the CN and the UE.

[0061] In Figure 2In one variant, the multi-path L2 U2N remote UE 10 can first connect to the gNB-CU 30 via the gNB-DU2 34 on the indirect path; the L2 U2N remote UE 10 can 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 can then indicate its support for R18 sidelink relay multi-path relaying in the NAS message in the initial access / attach to the gNB-CU 30 and the AMF; then at a later time, based on the measurement report received from the L2 U2N remote UE 10 on the indirect path, the gNB-CU 30 can decide to add the direct path for the L2 U2N remote UE 10 to use the multi-path relaying functionality. The direct path is served by the gNB-DU1 32, which is the inter-DU direct path addition on top of the indirect path procedure for the multi-path L2 U2N remote UE 10. UERadioCapability IE to the gNB-CU 30 and the AMF; then at a later time, based on the measurement report received from the L2 U2N remote UE 10 on the indirect path, the gNB-CU 30 can decide to add the direct path for the L2 U2N remote UE 10 to use the multi-path relaying functionality. The direct path is served by the gNB-DU1 32, which is the inter-DU direct path addition on top of the indirect path procedure for the multi-path L2 U2N remote UE 10.

[0062] Indication on support of multi-path relay functionality In some embodiments, the multi-path L2 U2N remote UE 10 and / or the multi-path L2 U2N relay UE 12 (3GPP R18) can indicate support for the multi-path relaying functionality to the NG-RAN and the AMF respectively by using, for example, the indication fields remoteUE-MultiPathOperation-L2 and relayUE- MultiPathOperation-L2 which are contained in, for example, the RelayParameters-r18 ASN.1 IE defined in RelayParameters- r18 clause 6.3.3 of TS 38.331 V17.5.0. UE-NR- Capability

[0063] According to this variant, it is thus proposed that the UE sends a relay service support indication which indicates support for relay UE multi-path communication.

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

[0065] Figure 3 ​Figure 1 is a schematic diagram illustrating multi-path relay signaling and processing procedures for inter-DU indirect path addition over direct path employing legacy R17 sidelink relay direct-to-indirect path switching procedure. The detailed description can be found in TS 38.401 V17.5.0, clause 8.19.4.1-1 and 3GPP TDoc R3-230947, xx.2. Figure 8 .19.4.1-1 and 3GPP TDoc R3-230947, xx.2. Figure 8

[0066] ​In step S301, the remote UE 10 sends an RRC setup request to the gNB-DU1 32, which allocates a first C-RNTI (C-RNTI1) to the remote UE 10 in step S302. Then, in step S303, the gNB-DU1 performs an initial UL RRC messaging with the allocated C-RNTI1 to the gNB-CU 30, which stores the C-RNTI1 in step S304 and responds with a DL RRC messaging in step S305. In response to the DL RRC messaging, in step S306, the gNB-DU1 32 sends an RRC setup response with the allocated C-RNTI1 to the remote UE 10. Then, the remote UE 10 configures the C-RNTI1 in step S307 and responds with an RRC setup complete message to the gNB-DU1 32 in step S308. Thereafter, the gNB-DU1 32 initiates an UL RRC messaging 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 transferred by the gNB-CU 30 to the gNB-DU1 32 in step S312. In step S313, the gNB-DU1 32 sends a security mode command to the remote UE 10 and responds with a UE context setup response to the gNB-CU 30 in step S314. After security mode completion, 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 messaging to the gNB-CU 30 in step S316, which responds with a DL RRC messaging 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 with an RRC reconfiguration complete message in step S319. The gNB-DU1 32 initiates an UL RRC messaging to the gNB-CU 30 in step S320, which sends an initial context setup response to the AMF in step S321. Thereafter, in step S322, DL / UL data can be transferred from the remote UE 10 to the gNB-CU 30 via the gNB-DU1 32 over the direct path. Then, direct data transfer is followed by measurement configuration and reporting in step S323.

[0067] In step S324, the gNB-CU 30 decides to add the 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 to the UE context setup request allocates a new C-RNTI (C-RNTI2) to the remote UE 10 in step S327 and responds to the gNB-CU 30 with a UE context setup response in step S328. In a subsequent step S329, the gNB-CU 30 stores the new C-RNTI2. Then, in step S330, the gNB-CU 30 initiates a DL RRC messaging 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 a PC5 connection setup with the relay UE 12 in step S332 and configures and stores the received C-RNTI2 in step S333. Then, the remote UE 10 responds to the gNB-DU1 32 with an RRC reconfiguration complete message in step S334. The gNB-DU1 32 initiates a corresponding UL RRC messaging to the gNB-CU 30 in step S335.

[0068] However, in a subsequent step S336, the direct path transmission fails because a different C-RNTI (i.e., C-RNTI2) is configured at the remote UE 10 compared to the gNB-DU1 32 (i.e., C-RNTI1). As a result, in step S337, only the indirect path via the relay UE 12 is used for transmitting DL / UL data.

[0069] Thus, in the above described R17 direct path to indirect path switching procedure, the direct path needs to be released at the end and only the indirect path is left.

[0070] However, as indicated in the initial part above, when using the legacy R17 sidelink relay direct path to indirect path switching procedure, Figure 3 the L2 U2N remote UE 10 will end up in a state where the first assigned C-RNTI (i.e., C-RNTI1) on the direct path allocated by the direct path serving gNB-DU1 32 will be overwritten by the second assigned C-RNTI (i.e., C-RNTI2) on the indirect path allocated by the indirect path serving gNB-DU2 34 using the R17 sidelink relay procedure.

[0071] As a result, the multi-path L2 U2N remote UE 10 stores a different C-RNTI (i.e., C-RNTI2) to detect and inspect the PDCCH / DCI scheduling information on the direct path scrambled / masked by gNB-DU1 32 with C-RNTI1. As such, the L2 U2N remote UE 10 will not be able to decode the PDCCH / DCI scheduling information from gNB-DU1 32 and the direct path completely fails.

[0072] Inter-DU indirect path addition and / or change over direct path Figure 4 is a schematic diagram according to an embodiment of the present application. The schematic diagram illustrates a multi-path relaying signaling and processing procedure for inter-DU indirect path addition over the direct path.

[0073] The initial steps S401-S423 are similar to the above described steps S301-S323 and are not repeated here.

[0074] In step S424, the gNB-CU 30 decides to add an indirect path via the relay UE 12 and 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 to the UE context setup request, allocates a new C-RNTI (C-RNTI2) to the remote UE 10 in step S427 and responds to the gNB-CU 30 with a UE context setup response in step S428. In a subsequent step S429, the gNB-CU 30 stores the new C-RNTI2. Then, in step S430, the gNB-CU 30 initiates a DL RRC messaging for RRC reconfiguration to the gNB-DU1 32, which can include a newly defined IE SL-MultiPathConfig directPathC-RNTI : C-RNTI1, indirectPathC-RNTI : C-RNTI2, or similar IE. 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 message with the SL-MultiPathConfig ​IE (or similar IE) (with C-RNTI information) RRC Reconfiguration, the remote UE 10 performs in step S432 a PC5 connection setup with the relay UE 12 and configures and stores in step S433 the received C-RNTI information. 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.

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

[0076] Thus, it is possible to have ReconfigurationWithSync A new SL- MultiPathConfig IE (or similar IE) that ReconfigurationWithSync IE further contains in RRCReconfiguration . RRCReconfiguration The detailed definition of the

[0077] 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 reception of the RRCReconfiguration message by the L2U2N remote UE 10, the remote UE 10 can configure and store the two C-RNTIs for the direct and indirect paths, respectively. In subsequent communication on the direct path, the remote UE 10 will now have the correct C-RNTI (i.e. C-RNTI1) for checking and decoding PDCCH / DCI scheduling information transmitted by the direct path serving gNB-DU1 32.

[0078] In a variant of the previous embodiment, the gNB / gNB-CU 30 can initiate the new RRCReconfiguration message via an RRC Reconfiguration message. SL-MultiPathConfigThe service cell information (such as physical cell ID, carrier information, etc.) for direct path, indirect path, or both is configured in the IE (or similar IE). The remote UE 10 can configure and store the configured service cell information for direct path, indirect path, or both in the local storage.

[0079] In another variant of the previous embodiment, the gNB / gNB-CU 30 can assign only one C-RNTI value to the remote UE 10 by using the new SL- MultiPathConfig The IE (or similar IE) can contain only one of the fields directPathC-RNTI or indirectPathC-RNTI and skip the other field to assign only one C-RNTI value to the remote UE 10.

[0080] In another variant of the previous embodiment, for the procedure of adding indirect path over direct path or changing from one indirect path to another indirect path over direct path, the gNB / gNB-CU 30 can assign only one C-RNTI value to the remote UE 10, where only the new SL-MultiPathConfig IE (or similar IE) contains indirectPathC-RNTI field. Upon receiving the RRCReconfiguration message by the L2 U2N remote UE 10, the remote UE 10 can keep the current configured directPathC-RNTI value for direct path and only update the C-RNTI value for indirect path.

[0081] In another variant of the previous embodiment, for the procedure of adding indirect path over direct path or changing from one indirect path to another indirect path over direct path, the gNB / gNB-CU 30 can assign only the C-RNTI allocated by the direct path serving gNB-DU (i.e., gNB-DU1 32) to the multi-path L2 U2N remote UE 10, as only direct path C-RNTI is available for multi-path remote UE operation to receive scheduling information from gNB (i.e., gNB-CU 30) and / or direct path serving gNB-DU (i.e., gNB-DU1 32). In this case, SL-MultiPathConfig The IE (or similar IE) can contain only the directPathC-RNTI field as defined below.

[0082] In another variant of the previous embodiments, for the process of adding an indirect path over the direct path or changing from one indirect path to another indirect path over the direct path, the gNB / gNB-CU 30 can not assign any new C-RNTI to the remote UE 10 at all, so that the remote UE 10 can continue to use the current C-RNTI (i.e., C-RNTI1) on the direct path. In this case, SL-MultiPathConfig The IE (or similar IE) can be defined as above to make the C-RNTI related field optional, so that the C-RNTI related field is not configured on the remote UE 10. SL-MultiPathConfig The IE (or similar IE) can not contain the C-RNTI related field.

[0083] In another variant of the previous embodiments, for the process of adding an indirect path over the direct path or changing from one indirect path to another indirect path over the direct path, the gNB / gNB-CU 30 can not assign any new C-RNTI to the remote UE 10 at all, so that the remote UE 10 can continue to use the current C-RNTI (i.e., C.RNTI1) on the direct path. In this case, SL-MultiPathConfig The IE (or similar IE) can not contain any C-RNTI related field as shown below.

[0084] In another variant of the previous embodiments, the gNB / gNB-CU 30 can configure the direct path of a multi-path remote UE as the primary path in the multi-path configuration, and for the process of adding an indirect path over the direct path or changing from one indirect path to another indirect path over the direct path, the remote UE can ignore any new C-RNTI value assigned to it and can continue to use the current C-RNTI on the direct path.

[0085] In another variant of the previous embodiments, for the process of adding an indirect path over the direct path or changing from one indirect path to another indirect path over the direct path, the remote UE 10 can ignore any new C-RNTI value assigned to it and can continue to use the current C-RNTI on the direct path for communication on the direct path.

[0086] In yet another variant of the previous embodiments, at least during the time of multipath session activity, or until the remote UE 10 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 the same parameter as the C-RNTI allocated for the indirect path, or a parameter indicating that the previously allocated C-RNTI will not be used for the direct path anymore, or a parameter indicating a new C-RNTI value covering the C-RNTIs allocated for the direct path and / or the indirect path (from which it can be indicated with a flag or with a different name of the parameter that it is a direct path / indirect path), or until the expiry of a (pre-configured) timeout, the remote UE 10 will receive and store in addition to the C-RNTI previously allocated for the direct path by the gNB-DU serving the direct path (i.e. gNB-DU1 32) the C-RNTI allocated for the indirect path by the gNB-DU serving the indirect path (i.e. gNB-DU2 34). The remote UE 10 can then use the correct C-RNTI to decode the PDCCH / DCI or if the decoding fails, try another stored C-RNTI to decode the PDCCH / DCI. Additionally or alternatively, the remote UE 10 can receive an instruction (e.g. RRC (re)configuration message) with a parameter indicating the time (e.g. start time or offset or time interval) to use the first C-RNTI and the second C-RNTI or indicating the time to switch between the first C-RNTI and the second C-RNTI (e.g. C-RNTI received / assigned for the direct path and C-RNTI received / assigned for the indirect path).

[0087] In another embodiment variant of the previous embodiments, in order to distinguish this multipath procedure from the legacy R17 procedure for sidelink relaying, the gNB-CU 30 or the gNB-DU (e.g. gNB-DU1 32) can include in a message (e.g. RRC (re)configuration message) to the remote UE 10 a parameter for indicating that the C-RNTI used 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 for indicating that the previously allocated C-RNTI will not be used for the direct path anymore, or a parameter for indicating a new C-RNTI value that covers the C-RNTI allocated for the direct path and / or the indirect path (and that can currently be stored in the remote UE 10), whereby the direct / indirect path can be indicated with a flag or with a different name of the parameter (e.g. different names for different paths), or a parameter for indicating a time (e.g. start time or offset or time interval) at which the first C-RNTI and the second C-RNTI (e.g. C-RNTI received / assigned for the direct path and C-RNTI received / allocated for the indirect path) are to be used to receive and / or decode information from the first base station device or a parameter for indicating a time (e.g. start time or offset or time interval) at which a switch between the first C-RNTI and the second C-RNTI is to be made to receive and / or decode information from the first base station device.

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

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

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

[0091] In another embodiment variant of the previous embodiment, in SL-MultiPathConfig The configuration parameters defined in the IE (or similar IE) can be included directly in the RRCReconfiguration message and / or included in ReconfigurationWithSync IE, whereby in the ReconfigurationWithSync RRCReconfiguration message for multi-path relay function configuration on the remote UE and / or relay UE, the SL- MultiPathConfig IE (or similar IE).

[0092] Inter-DU direct path addition / change over indirect path In a variant of the previous embodiment, for the multi-path relay signaling and processing procedure for adding a direct path over the indirect path or changing from one direct path to another direct path over the indirect path, the multi-path L2 U2N remote UE 10 can first establish an indirect path to the indirect path serving gNB-DU2 34 via the L2 U2N relay UE 12, where the C-RNTI assigned by the gNB-DU2 34 (i.e., C-RNTI2) 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 over the indirect path or change from the old direct path to a new direct path over the indirect path. The direct path serving gNB-DU1 32 can assign a new C-RNTI (i.e., C-RNTI1) for the remote UE 10 on the direct path. The same ReconfigurationWithSync IE (or similar IE) defined in the SL-MultiPathConfig IE (or similar IE) can be used to assign two assigned C-RNTIs for the indirect path and the direct path by the indirect path serving gNB-DU2 34 and the direct path serving gNB-DU1 32, respectively, ReconfigurationWithSync IE is further contained in the RRCReconfiguration message. Upon receiving the RRCReconfiguration message by the L2 U2N remote UE 10, the remote UE 10 can configure and store two C-RNTIs for the direct path and the indirect path, respectively. In the subsequent communication on the direct path, the remote UE 10 will have the correct C-RNTI for checking and decoding the PDCCH / DCI scheduling information sent by the direct path serving gNB-DU1 32.

[0093] ​In a variant of the previous embodiment, the multi-path remote UE 10 can be assigned / configured with a new C-RNTI for the direct path only. The remote UE 10 can configure and store this C-RNTI and override the previously configured C-RNTI value on the indirect path. In subsequent communications on the direct path, the remote UE 10 will have the correct C-RNTI to check and decode the PDCCH / DCI scheduling information transmitted by the direct path serving gNB / gNB-DU.

[0094] Thus, in other words, a method for operating a UE operating in multi-path communications in a direct path and an indirect path in a communication network is proposed, the method comprising: The UE receives from a base station an RRC message for configuring a new C-RNTI value; The UE overrides the C-RNTI value configured on the indirect path; The UE decodes control information such as scheduling information transmitted by the serving base station on the direct path using the new C-RNTI value.

[0095] As mentioned above, the new C-RNTI value can be configured for direct path communications.

[0096] Intra-DU indirect path addition / change over direct path In a variant of the previous embodiment, for multi-path relaying signaling and processing in the addition of an indirect path within a DU over the direct path or change from one indirect path to another over the direct path, the multi-path L2U2N remote UE 10 can first establish a direct path to the serving gNB-DU / gNB-CU. Then, the gNB-CU 30 decides to add an indirect path over the direct path or change from the old indirect path to the new indirect path over the direct path. The indirect path is connected to the same gNB-DU via the L2 U2N relay UE 12. The same C-RNTI can be used or a new C-RNTI can be generated by the gNB-DU. The gNB-CU 30 can use the traditional R17 sidelink relay procedure or the new multi-path procedure defined above to configure the remote UE 10 with the new C-RNTI or the old C-RNTI. SL- MultiPathConfig The IE (or similar IE) to configure the remote UE 10 with the old C-RNTI or the new C-RNTI. In case of using SL- MultiPathConfig In case of using the IE (or similar IE) to carry the C-RNTI values for the direct path and the indirect path, directPathC-RNTI and indirectPathC-RNTI The field will have the same C-RNTI value. Upon reception of the RRC message by the L2 U2N remote UE 10 RRCReconfigurationOn reception of the message, the remote UE 10 can configure and store two C-RNTIs for the direct path and indirect path respectively, or only configure and store one C-RNTI for the remote UE 10 as they are the same. In subsequent communication on the direct path, the remote UE 10 will have the correct C-RNTI for checking and decoding PDCCH / DCI scheduling information transmitted by the gNB-DU.

[0097] In a variation of the previous embodiment, the multi-path remote UE 10 can be assigned / configured only a new C-RNTI for the direct path. The remote UE 10 can configure and store this C-RNTI and override the C-RNTI value previously configured on the indirect path. In subsequent communication on the direct path, the remote UE 10 will have the correct C-RNTI for checking and decoding PDCCH / DCI scheduling information transmitted by the serving gNB / gNB-DU on the direct path.

[0098] Intra-DU direct path addition / change over indirect path In a variation of the previous embodiment, for the multi-path relaying signaling and processing procedure in adding a direct path over the indirect path or changing from one direct path to another direct path over the indirect path, the multi-path L2 U2N remote UE 10 can first establish an indirect path to the serving gNB-DU / gNB-CU via the L2 U2N relay UE 12. Then, the gNB-CU 30 decides to add a direct path over the indirect path or change from the old direct path to a new direct path over the indirect path. The direct path is directly connected to the same gNB-DU through a Uu interface. The same C-RNTI can be used, or a new C-RNTI can be generated by the gNB-DU. The gNB-CU 30 can use the legacy R17 sidelink relaying procedure or the new multi-path relaying procedure defined above to configure the remote UE 10 with the old C-RNTI or the new C-RNTI using the SL-MultiPathConfig IE (or similar IE). In case the C-RNTI values for the indirect path and direct path are carried using the SL-MultiPathConfig IE (or similar IE), the field will have the same C-RNTI value. On reception of the indirectPathC-RNTI and directPathC-RNTI message by the L2 U2N remote UE 10, the remote UE 10 can configure and store two C-RNTIs for the indirect path and direct path respectively, or only configure and store one C-RNTI for the remote UE 10 as they are the same. In subsequent communication on the direct path, the remote UE 10 will have the correct C-RNTI for checking and decoding PDCCH / DCI scheduling information transmitted by the gNB / gNB-DU. RRCReconfiguration

[0099] ​ Inter-DU direct path release for L2 U2N remote UE operating in multi-path In embodiments that can be used in combination with or independently of any prior embodiment, the L2U2N remote UE 10 operating in multipath mode can measure the received signal quality on the serving cell of the direct path and can detect that the received signal quality is below a pre-configured / public / private threshold, or can detect a radio link failure (RLF) on the direct path. It can then trigger a direct path release procedure for the gNB. If the L2U2N remote UE 10 stores two C-RNTIs, the L2U2N remote UE can discard the C-RNTI configured on the direct path and can retain only the C-RNTI configured on the indirect path. If the remote UE 10 stores only one C-RNTI, the gNB / gNB-DU can send a signal to the remote UE 10 via the indirect path. RRCReconfiguration The message is to configure a new C-RNTI specifically for remote UE 10 on the indirect path, so that remote UE 10 can have a valid C-RNTI for traditional R17 L2 U2N relay operations.

[0100] In a variant of the previous embodiment, the indirect path service gNB-DU (i.e., gNB-DU2 34) can assign a new C-RNTI to the L2 U2N remote UE 10. The gNB / gNB-CU can configure the newly assigned indirect path C-RNTI on the remote UE 10. Upon receiving this configuration, the remote UE 10 can configure and store the new C-RNTI for the indirect path, enabling the remote UE 10 to have a valid C-RNTI for conventional R17 L2 U2N relay operations.

[0101] Inter-DU indirect path release for L2 U2N remote UE operating in multi-path In a variation of the previous embodiment, the L2 U2N Remote UE 10 operating in multi-path mode can measure the received signal quality on the PC5 link with the Relay UE 12, and / or the Relay UE 12 can measure the received signal quality on the Uu link on the indirect path’s serving cell, and can detect that the received signal quality on the PC5 link or Uu link is below a pre-configured / common / dedicated threshold, or can detect a Radio Link Failure (RLF) on the PC5 or Uu link of the Relay UE 12, then it can trigger the indirect path release procedure of the gNB. If there are two C-RNTIs stored in the Remote UE 10, the Remote UE 10 can discard the C-RNTI configured on the indirect path and can keep only the C-RNTI configured on the direct path for Uu communication 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 can continue to use the current C-RNTI on the direct path as a legacy UE for communication on the direct path.

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

[0103] Direct path release procedure for L2 U2N remote UE operating in multi-path In section 1.7 of R2-2308950, the direct path release procedure for L2 U2N Remote UEs operating in multi-path was discussed. It has been decided to leave the content details for direct path release in the RRCReconfiguration message to stage 3.

[0104] In the stage 3 specification TS 38.331 V18.0.0, in the RRCReconfiguration message definition in clause 6.2.2, for indirect path release, it is further investigated whether to include an explicit “directPathRelease” flag in the reconfiguration procedure to enable the UE to apply a simpler behavior.

[0105] It has been proposed to add a new field “directPathRelease” in the RRCReconfigurationA "direct path release" flag was introduced in the message to release the direct path. However, it was not approved and instead it was proposed that an explicit network indication (e.g., retainRelayPath) should be introduced for direct addition / change / release to indicate that the remote UE maintains the PC5 unicast link with the source relay UE during the Rel-17 I2D / D2I path switch procedure, thus maintaining the PC5 unicast link for the indirect path during the direct path addition / change / release procedure. The final approval in RAN2 #125 meeting was to introduce an explicit network indication for direct addition / change / release to indicate that the remote UE maintains the PC5 unicast link with the source relay UE during the Rel-17 I2D / D2I path switch procedure.

[0106] However, in the stage 3 specification, there is still no content detail for RRCReconfiguration the message to release the direct path. The purpose of the following set of embodiments is to solve the problem of informing the remote UE to release the direct path.

[0107] In an embodiment, which can be combined with any other embodiment or used independently, in the direct path release procedure, the base station can send to the remote UE operating in multi-path RRCReconfiguration message, where the direct path and the indirect path work simultaneously to release the direct path. RRCReconfiguration The message can contain an explicit or implicit network indication to indicate to the remote UE to maintain the PC5 unicast link (e.g., explicit: retainRelayPath set to true; implicit: new C-RNTI for the PC5 link), and RRCReconfiguration The message can not contain any target serving cell information within reconfigurationWithSync spCellConfigCommon , or RRCReconfiguration The message can not contain the reconfigurationWithSync IE at all, in which case the remote UE shall interpret the message as releasing the direct path in addition to maintaining the PC5 unicast link of the existing indirect path.

[0108] In another embodiment, in the direct path release procedure, the base station can send to the remote UE operating in multi-path RRCReconfiguration message, where the direct path and the indirect path work simultaneously to release both the direct path and the indirect path. RRCReconfiguration The message can contain an explicit or implicit network indication to indicate to the remote UE to release the PC5 unicast link (e.g., retainRelayPath set to false), and RRCReconfiguration The message can not contain any target serving cell information within reconfigurationWithSync spCellConfigCommon , or RRCReconfiguration The message can not contain the​​reconfigurationWithSync IE, in this case, the remote UE shall interpret the message by releasing the direct path in addition to releasing the existing indirect path's PC5 unicast link and releasing its indirect path.

[0109] According to the general definition of this embodiment, a method for operating a UE operating in a communication network in a multipath communication using a direct path and an indirect path is proposed, the method comprising: receiving from a base station a first RRC message for maintaining an indirect path, upon determining that no target service is present in the message, maintaining the indirect path and releasing the direct path.

[0110] Alternatively, a method for operating a UE operating in a communication network in a multipath communication using a direct path and an indirect path is proposed, the method comprising: receiving from a base station a first RRC message for releasing an indirect path, upon determining that no target service is present in the message, releasing the indirect path and releasing the direct path.

[0111] Alternatively, a method for operating a UE operating in a communication network in a multipath communication using a direct path and an indirect path is proposed, the method comprising: receiving from a base station a first RRC message for releasing a direct path, upon determining that no target service is present in the message, maintaining the indirect path.

[0112] Alternatively, a method for operating a UE operating in a communication network in a multipath communication using a direct path and an indirect path is proposed, the method comprising: receiving from a base station a first RRC message for releasing a direct path, upon determining that no target service is present in the message, releasing the indirect path.

[0113] When releasing the direct path for an L2 U2N Remote UE operating in multi-path, configure the C-RNTI for the L2 U2N Remote UE on the indirect path C-RNTI In TS 38.331 V18.0.0, in clause 6.3.5, the condition exists FirstRRCReconfig is redefined as “ This field is mandatory present in the first RRCReconfiguration for L2 U2N Remote UE when the PCell is on indirect path, i.e. MP configuration is not present. Otherwise, this field is not present This field is mandatory present in the first RRCReconfiguration. Otherwise, this field is not present. ”, which comes from: the content defined in TS 38.331 V17.7.0, SL-L2RemoteUE-Config-r17 ”.

[0114] The main reason for this change in Rel-18 is to ensure that in indirect path addition on top of direct path (i.e., MP configuration exists), sl-UEIdentityRemote-r17 SL-L2RemoteUE-Config-r17 the field becomes non-existent so that there will be no new C-RNTI configured for L2 U2N remote UE on indirect path and C-RNTI on direct path will not be overridden. In another case, for Rel-17 L2 U2N remote UE not operating in multi-path, i.e., PCell is on indirect path and MP configuration does not exist, UEIdentityRemote-r17 sl- Introduce explicit network indication for direct addition / change / release to indicate Remote UE the field becomes mandatory, thereby ensuring C-RNTI is configured for L2 U2N remote UE on indirect path.

[0115] However, the RAN2 approved “ Maintain the PC5 unicast link with the source Relay UE during Rel-17 I2D / D2I path switch procedure RRCReconfiguration ” (approved at RAN2 #125 meeting) can imply that the SL-L2RemoteUE-Config-r17 message configured on remote UE operating in multi-path for releasing direct path can not include UEIdentityRemote-r17 sl- SL-L2RemoteUE-Config-r17 (which is used to configure remote UE according to the condition of UEIdentityRemote-r17 sl- FirstRRCReconfiguration This field is mandatory present in the first RRCReconfiguration for L2 U2N Remote UE when the PCell is on indirect path, i.e. MP configuration is not present. Otherwise, this field is not present “ RRCReconfiguration RRCReconfiguration sl-UEIdentityRemote-r18 ”), since when SL-L2RemoteUE-Config-r17 message is configured on remote UE and PCell is still on direct path, direct path has not been released yet. As a result, after direct path is released and L2 U2N remote UE operates in Rel-17 L2 U2N remote UE case, L2 U2N remote UE can not have any valid C-RNTI configured on indirect path which is mutually agreed between remote UE and network. The purpose of the following embodiments is to solve the problem of configuring C-RNTI for L2 U2N remote UE on indirect path after direct path is released and L2 U2N remote UE operates in Rel-17 L2 U2N remote UE case.

[0116] In an embodiment, which can be used in combination with any other embodiment or independently, sl-UEIdentityRemote-r17 message can include a new FirstRRCReconfig ​​​​​The field configures the remote UE's C-RNTI on the indirect path when the direct path is released and the remote UE is operating in a Rel-17 L2 U2N remote UE configuration, or once the direct path is released and the remote UE is operating in a Rel-17 L2 U2N remote UE configuration. This means that the remote UE can apply only the C-RNTI after the direct path is released.

[0117] In a variant of the embodiment, RRCReconfiguration In RRCReconfiguration The conditional existence RRCReconfiguration This can be restated as: when the PCell is on the direct path, the direct path release for a multipath (MP) remote UE is enforced, and when the PCell is on the indirect path (i.e., the MP configuration does not exist), the first... SL-L2RemoteUE-Config- It must exist.

[0118] In a variant of the implementation, the network may send another [transmission] to the L2 U2N remote UE after the direct path has been released. sl-UEIdentityRemote-r17 The message, and the Support more than one indirect path The message includes SL- r17 In MultiPathConfig To configure C-RNTI for L2 U2N remote UEs on indirect paths.

[0119] In another embodiment variant, the L2 U2N remote UE includes a strategy that applies a given C-RNTI when the direct path is released, for example, it may apply an existing C-RNTI in the indirect path, or it may apply another previously received C-RNTI when the direct path is released.

[0120] Access device selection of a single RNTI In embodiments that can be used in combination with or independently of any other embodiment, the multipath L2 U2N remote UE 10 can connect to the gNB via more than one L2 U2N relay UE 12 (which may be served by different gNB-DUs). Therefore, more than one indirect path can exist between the L2 U2N remote UE 10 and the gNB / gNB-CU. It can then be defined as follows: Figure 5 Figure 3 IE (or similar):

[0121] RelayParameters remoteUE-MultiPathOperation-L2A schematic diagram is shown according to an embodiment which can be combined with any other embodiment or can be used independently. The schematic diagram shows the proposed signaling and processing procedure for inter-DU indirect path addition over the direct path for a multi-path L2 U2N remote UE 10 involving the gNB-CU 30 and the gNB-DUs 32, 34 to synchronize the allocated C-RNTI value in the NG-RAN nodes.

[0122] The initial steps S501 to S527 are similar to the above described steps S301 to S323 of RRCReconfiguration , which are not repeated here.

[0123] After the gNB-CU 30 receives the allocated C-RNTI (i.e., C-RNTI2) from the gNB-DU2 34 serving the indirect path in step S528, the gNB-CU 30 knows that the remote UE 10 is a multi-path capable UE according to the radio capability indication in the initial access / attach (e.g., using the field Figure 5 in the IE ​ as described before) and that it adds an indirect path over the direct path, so it can synchronize the indirect path with the direct path by instructing the gNB-DU2 34 serving the indirect path to use the C-RNTI value allocated by the gNB-DU1 32 serving the direct path in step S529. Thus, this C-RNTI value is synchronized to C-RNTI1 by the gNB-DU2 34. Then, the gNB-CU 30 can send the ​ message including C-RNTI1 in step S530 using the legacy R17 sidelink relay procedure to configure the C-RNTI (i.e., C-RNTI1) on the indirect path. Even though the remote UE 10 can thus only configure and store one C-RNTI, because this C-RNTI value (i.e., C-RNTI1) has been synchronized between the direct path serving gNB-DU1 32 and the indirect path serving gNB-DU2 34, the remote UE 10 can still have the correct C-RNTI to check and decode the PDCCH / DCI scheduling information transmitted by the direct path serving gNB-DU1 32. By using this procedure, the same C-RNTI value can be used (i.e., shared) for both the direct path and the indirect path. The benefit is that the remote UE 10 can only need to store and use a single C-RNTI and it does not impact the legacy R17 sidelink procedure.

[0124] In an embodiment variant, ​The gNB-DUs 32, 34 can agree on a C-RNTI to be used for communication with the remote UE 10 over the direct path and the indirect path. This agreement can be done directly or indirectly, it can be coordinated by the gNB-CU 30 or done in a distributed manner by both gNB-DUs 32, 34. The gNB can also inform the remote UE 10 about the fact that this C-RNTI is used for communication over both the direct path and the indirect path and the remote UE 10 can store said configuration.

[0125] 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 can allocate a new C-RNTI to the remote UE 10 for the indirect path, the gNB-DU2 34 can indicate the allocated C-RNTI to the gNB-DU1 32. This indication can be done through the gNB-CU 30, for example, through the Fl interface which is a point-to-point interface between endpoints (which means a point-to-point logical interface) and supports control plane (CP) and user plane (UP separation between radio network layer and transport network layer) to enable exchange of UE-associated and non-UE-associated information. In this case, the gNB-DU2 34 can provide an indication of the determined C-RNTI, update the gNB-CU 30 and the gNB-CU 30 can inform the gNB-DU1 32. Then, the gNB-CU 30 can request the remote UE 10 to start using this new C-RNTI or, if the gNB-DU2 34 is the entity that allocates said C-RNTI to the remote UE 10, the gNB-CU 30 can directly start using said C-RNTI for the remote UE 10. The gNB-DU1 32 can 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 can be defined and used instead of communicating via the gNB-CU 30. In this case, this interface can then be used to exchange said information directly between the two gNB-DUs 32, 34.

[0126] In another example, the gNB-DU1 32 can inform the gNB-DU2 34 about the C-RNTI that is used by the remote UE 10. Then, the gNB-DU2 34 can allocate said C-RNTI to the remote UE 10. If said C-RNTI is used by the gNB-DU2 34 to address any other UE, the gNB-DU2 34 can reallocate a new C-RNTI’ to the other UE.

[0127] In another example, when gNB-DU1 32 or gNB-DU2 34 inform each other, they can also include an implicit or explicit time or context for determining when to start using the allocated or used or determined C-RNTI. This has the benefit of synchronizing the change / switch of C-RNTI.

[0128] In another example, gNB-DU1 32 and gNB-DU2 34 can have a fixed allocation range of C-RNTI for multi-path communication over the direct path and indirect path.

[0129] In another example, a multi-path L2 U2N remote UE 10 can be connected to gNB1 over the direct path and can be connected to gNB2 over the indirect path. gNB1 and gNB2 can be two different base stations 20. gNB1 can configure a C-RNTI (i.e. C-RNTI1) over the direct path, while gNB2 can configure a C-RNTI (i.e. C-RNTI2) over the indirect path using the traditional procedure. gNB1 and gNB2 can be interconnected to exchange messages in both directions, e.g. using the XnAP protocol.

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

[0131] In an embodiment, a radio network identifier can be selected, e.g. by a second access device, for communicating with a UE over a direct path managed by a first access device and an indirect path managed by the second access device, wherein: the second access device determines a radio network identifier for communicating 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 communicating with the UE over the indirect path.

[0132] In embodiments, the radio network identifier can be communicated, e.g. by the first access device, for communicating with the UE over the direct path managed by the first access device and the indirect path managed by the second access device, wherein: The first access device determines a radio network identifier for communicating with the UE; The first access device informs the second access device about the radio network identifier.

[0133] Reporting of cell information by access devices for multipath As mentioned above, the multi-path L2 U2N remote UE 10 can have one (primary) serving cell in the direct path under gNB-DU1 32 and can have another (primary or secondary) serving cell in the indirect path through the L2 U2N relay UE 12 under gNB-DU2 34. Each serving cell can have a different cell ID. This can cause problems during a network registration procedure, or a network service access procedure, or a positioning based procedure, wherein the procedure is based on the cell ID used to serve the UE (e.g. during a UE location reporting procedure as specified in clause 4.10 of 3GPP TS 23.502).

[0134] The following embodiments, which can be used in combination with any other embodiments or independently, can solve this problem.

[0135] In embodiments, the network base station (e.g. gNB-CU 30) or other access device can be configured (e.g. by means of a policy) or requested (e.g. using a location reporting control message from the LMF or from the AMF) to report in the UE location information reporting (e.g. in the location report) one or more cell IDs for the multi-path communication of the U2N remote UE, the gNB-CU 30 can report in the UE location information reporting to the core network (e.g. to the AMF, GLMC, LMF) the serving cell IDs and / or one or more cell IDs of one or more network base stations (e.g. gNB-DU 32, 34) involved in the multi-path communication for a specific UE. This allows the core network to determine the location of the UE, for example. The policy or request configured to or sent to the network base station can also include a request / instruction / condition for whether to include information about whether the reported cell IDs correspond to one of the direct path or the indirect path, and / or whether to include all cell IDs of all network base stations or only a subset thereof in the report. Based on the policy or request, the network base station can include the requested information in its report to the core network.

[0136] In related embodiments, the network base station can be configured or requested to report the cell ID of the primary cell to the core network. Which serving cell can be configured as the primary cell and / or which serving cell needs to be reported can be decided by 3GPP specifications, such as the specification can specify that the primary serving cell using the direct path as the primary cell for the multi-path L2 U2N remote UE 10; it can also be decided by the configuration or request received from OAM and / or AMF.

[0137] In related embodiments, the network base station can be configured or requested to report the cell ID of the cell having the smallest coverage area among the cell IDs of the multiple paths in the multi-path communication (e.g., if one of these cells comes from a network base station in a non-terrestrial network having a large coverage area, while another cell can come from a terrestrial network having a smaller coverage area).

[0138] In related embodiments, the network base station can be configured or requested to report the cell ID of the cell serving the relay UE to which the remote UE is connected via the multi-path communication and having the best signal to the remote UE (e.g., the measurement report received from the relay UE or the remote UE has the highest SL-RSRP or SD-RSRP for the PC5 communication for this cell), and / or having the smallest distance to the remote UE (e.g., based on the transmit power information or SL-RSRP or SD-RSRP or timing / timing advance report (e.g., UE RX-TX), distance measurement from or between the remote UE or the relay UE). This is because in the case of multiple relay UEs connected to the remote UE, the relay UE with the strongest signal can be the closest relay UE. In addition to the reported cell ID, the network base station can also report its measurement or its summary or its report (e.g., as metadata).

[0139] In related embodiments, the network base station can be configured or requested to report the cell ID of the cell serving the relay UE to which the remote UE is connected via the multi-path communication having the least number of hops between the remote UE and the base station. To this end, the relay UE or the remote UE can need to report the number of hops between themselves and the network, and / or determine the number of hops by adding an attribute (e.g., a hop counter) to one or more messages exchanged between the respective UE and the network, whereby the value of the attribute can increase each time the message is forwarded. In addition to the reported cell ID, the network base station can also report the number of hops between itself and the remote UE (e.g., as metadata).

[0140] In related embodiments, the network base station can report to the core network the two cell IDs of the direct path and the indirect path or the two indirect paths. In addition, the network base station can also include additional information (metadata) related to the cells in its report to the core network, such as one or more of the following: cell size, coverage area, transmit receive point (TRP) transmit power, whether the cell is used for the direct path or for the indirect path, location and / or transmit power and / or coverage area of the relay UE in the indirect path, reference signal received power / strength of the Uu interface of the multi-hop L2 U2N remote UE 10 on the direct path, reference signal received power / strength of the sidelink discovery reference signal (SD-RSRP) and / or the sidelink reference signal (SL-RSRP) of the PC5 unicast link between the remote UE 10 and the relay UE 12, reference signal received power / strength of the Uu interface of the serving cell to which the Uu L2 U2N relay UE 12 is connected, etc. Which information to include can be based on information in a policy or request (e.g., a location reporting control message) on which additional information should be included.

[0141] In related embodiments, the additional information (metadata) can 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 the network base station. Examples of such identifiers include, e.g., NG-5G-S-TMSI (temporary mobile subscriber identity), 5G-GUTI (global unique temporary UE identity), or 5G-SUCI (subscription concealed identifier), or user information / user information ID.

[0142] In related embodiments, the core network can use the additional information received from the network base station to determine the use of the reported cell IDs. This has the advantage of improving the positioning accuracy of the cell-based positioning procedure, e.g., which can be used to determine that the UE is located, e.g., in: - the intersection of the coverage areas and / or a radius distance to the center (or other reference point) of the cell derived from the coverage areas and received signal strengths of the two cells; or - the intersection of the coverage areas and / or the radius distance to the center (or other reference point) of the cell derived from the coverage area and the received signal strength of the direct path cell, and the intersection of the coverage areas and / or the radius distance to the center (or other reference point) of the cell derived from the coverage area and the received signal strength of the relay connected to the indirect path cell; or in case of two indirect paths, the intersection of the coverage areas and / or the radius distance to the center (or other reference point) of the cell derived from the coverage area and the received signal strength of the first indirect path cell, and the intersection of the coverage areas and / or the radius distance to the center (or other reference point) of the cell derived from the coverage area and the received signal strength of the relay connected to the second indirect path cell.

[0143] Additionally or alternatively, the network base station can determine which cell 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.

[0144] In embodiments, the reported cell ID(s) can be used (e.g., by a core network function such as an AMF, LMF, GMLC) as an indication of the location information of the UE / user, which can further be used for the positioning of the UE / user.

[0145] In another embodiment, the UE can request and be requested (e.g., by a network function in the core network) to perform a positioning procedure based on its multi-path communication, whereby the user equipment can be requested to send a measurement report related to the multi-path connection, whereby the report can comprise connection information including one or more of the following related to the direct path and indirect path: cell ID of the access device (e.g., network base station), coverage of the access device, received power of the access device, is the access device for the direct path or for the indirect path, location and / or transmit power and / or coverage area of the relay UE in the indirect path, etc.

[0146] In another embodiment, the reported cell IDs can be used by a core network function, such as an AMF, to determine that one or more of the reported cell IDs (e.g., for indirect paths) are located in another country or in an area with communication restrictions or are too far away from other reported cell IDs (e.g., reported cell IDs for direct paths). In this case, the core network function can instruct (e.g., by providing a message via a Next Generation Application Protocol (NG-AP) interface, which is provided to the UE and AMF via NAS signaling) the wireless access network (e.g., one or more network base stations) to disconnect the UE from one or more reported cell IDs, e.g., that are located in another country or in an area with communication restrictions or are too far away from other reported cell IDs, etc. Additionally or alternatively, the core network function can instruct (e.g., by providing a message via the 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 can also include conditions (e.g., which cells should not be used for indirect paths of multi-path communication or for which area multi-path communication should be disabled or a maximum distance between cells for multi-path communication). Additionally or alternatively, the core network function (e.g., AMF) or the radio access network (e.g., one of the network base stations) can request the UE to disconnect one or more paths for its multi-path communication (e.g., by transmitting a NAS message including one or more cell IDs, a relay UE ID, a path ID to be disconnected to the UE) and / or can request the UE to disconnect completely and register again to the network. Additionally or alternatively, the core network function (e.g., AMF) or the radio access network (e.g., one of the network base stations) can request the UE (e.g., a remote UE or a relay UE) to disconnect one or more paths for its multi-path communication (e.g., by sending a NAS message including one or more cell IDs, a relay UE ID, a path ID to be disconnected to the UE) and / or can request the UE to disconnect completely and register again to the network in case the number of hops between the UE and the radio access network exceeds a preconfigured number of hops.

[0147] In embodiments that can be used in combination with any other embodiment or independently, a network access device (e.g., gNB-CU 30) can be configured (e.g., by means of a policy) or requested to disable multipath communication in certain areas (e.g., areas around national borders), and / or disable a path if a path in multipath communication is in a different country than other paths in multipath communication, and / or disable a path if the cell used for a path in multipath communication exceeds the maximum distance or hop count between that cell and other cells used for multipath communication (e.g., cells used for direct communication with the UE). This configuration or policy can be deployed by OAM or AMF; for example, the AMF can retrieve the location of a first access device and notify the first access device of the identity of a second access device that is allowed or not allowed to interact for a given communication service (e.g., multipath communication enabled).

[0148] In embodiments that can be used in combination with any other embodiment or independently, NG-RAN can perform location reporting / UserLocationInformation The message reports to the AMF / CN cell information, including direct path, indirect path, or both, and related cell metadata. UserLocationInformationNR It can be expanded to include the following information.

[0149] In another embodiment, which can be used in combination with any other embodiment or independently, the network base station can be configured or requested to report (e.g., in location reporting, such as as described above). UserLocationInformationNRa (coarse) location of the UE using the multi-path communication connection via two or more direct and / or indirect paths, whereby a network base station, possibly in cooperation with other network base stations, can use information of one or more cell IDs of network base stations involved in the multi-path communication of the UE and 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 one example, the network base station can receive measurement information for one of the indirect paths from the remote UE and / or the relay UE to determine a (coarse) 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 / to the remote UE or the relay UE). Additionally or alternatively, the network base station can obtain measurement information related to the direct communication path of the remote UE or the relay UE to one or more network base stations involved in the multi-path communication (e.g. from the remote UE or the one or more network base stations involved in the multi-path communication) and can use it together with additional information (meta data) related to the cells, such as: cell size, coverage area, transmit receive point (TRP) transmit power, TRP location, whether it is a cell for a direct or indirect path, to determine a (coarse) distance between the remote UE and the one or more network base stations involved in the multi-path communication and / or to determine whether the remote UE is located: - the intersection of the coverage areas and / or a radius distance to the center (or other reference point) of the cell derived from the coverage areas and received signal strengths of the two cells; or - the intersection of the coverage areas and / or a radius distance to the center (or other reference point) of the cell derived from the coverage area and received signal strength of the direct path cell, and the intersection of the coverage areas and / or a radius distance to the center (or other reference point) of the cell derived from 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 areas and / or a radius distance to the center (or other reference point) of the cell derived from the coverage area and received signal strength of the first indirect path cell, and the intersection of the coverage areas and / or a radius distance to the center (or other reference point) of the cell derived from the coverage area and received signal strength of the relay connected to the second indirect path cell.

[0150] The network base station can report the acquired information on the (rough) distance between the remote UE and one or more relay UEs or network base stations and / or whether the remote UE is located in the intersection or in a certain radius from the cell center or other reference point to the core network (e.g. in a location report) and / or can determine the (rough) location of the remote UE based on the acquired information (e.g. using trilateration or triangulation based on e.g. (rough) distances or radii) and report the (rough) location of the remote UE to the core network (e.g. in a location report).

[0151] Thus, more generally, the determination of the location of a user equipment connected by 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 devices, or by two or more direct paths managed by two or more first access devices, or by two or more indirect paths managed by two or more second access devices can be achieved by: - requesting connection information related to the user equipment, wherein the connection information can comprise one or more of the following related to the direct and indirect paths: cell ID of the access device, coverage of the access device, transmit power of the access device, (rough) location of the user equipment or (rough) distance / angle to one or more access devices, whether the reported cell ID is from an access device for a direct or indirect path, location and / or transmit power and / or coverage of a relay device in an indirect path, or related measurement information (e.g. RSRP, timing / timing advance information), or (rough) distance / angle to one or more relay devices, etc., - receiving a connection information report related to the direct and indirect paths, and - determining the location of the user equipment.

[0152] Generally, this can be implemented in the user equipment for determining the location of a user equipment connected by a direct path to a first access device or an indirect path and by an indirect path to a second access device by configuring the user equipment to: - send a positioning request to the core network or receive a positioning request from the core network indicating a positioning method based on multi-path direct and indirect connections to the first and second access devices, - send a connection information report to the core network, the connection information report comprising one or more of the following related to the direct and indirect paths: cell ID of the access device, coverage of the access device, receive power of the access device, whether it is an access device for a direct or indirect path, location and / or transmit power and / or coverage of a relay device in an indirect path, etc.

[0153] Reporting of cell information by access devices for non-multipath Several of the above extensions to the location reporting in the case of multi-path relaying can also be used to improve the location reporting of remote UEs and / or relay UEs involved in non-multi-path communications, 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 can add one additional hop in the multi-hop relay connection). Thus, in embodiments which can be used in combination with any other embodiments or independently, a network base station can be configured or requested to report (e.g. in a location report, such as the one described above UserLocationInformationNR , which is extended for this purpose) the cell ID of the cell serving a relay UE via which the remote UE is connected to the relay UE via indirect communication via one or more hops, whereby the network base station can report, in addition to the reported cell ID, the number of hops between itself and the remote UE (e.g. as metadata). Additionally or alternatively, the network base station can be configured or requested to report the identifiers of one or more relay UEs involved in the indirect connection between the remote UE and the respective base station.

[0154] To this end, the relay UEs or remote UEs can need to report the number of hops between themselves and the network, and / or the number of hops can be determined by adding an attribute (e.g. a hop counter) to one or more messages exchanged between the respective UE and the network, whereby the value of the attribute can be increased each time the message is forwarded. Furthermore, the relay UEs or remote UEs can need to report the identifiers of the relay UEs to which they are connected in the indirect path, and / or the identifiers of the relay UEs on the indirect path can be determined by adding an attribute (e.g. a list of relay UE identifiers) to one or more messages exchanged between the respective UE and the network. Each relay UE forwarding the message can add its own identifier to the attribute. The relay UE identifier can 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. NG-5G-S-TMSI (Serving Temporary Mobile Subscriber Identity), 5G-GUTI (Global Unique Temporary UE Identity), or 5G-SUCI (Subscription Concealed Identifier), or user information / user information ID.

[0155] Additionally or alternatively, a core network function (e.g. an AMF) or a radio access network (e.g. one of the network base stations) can request a UE (e.g. a remote UE or a relay UE) to disconnect its indirect communication path (e.g. by sending a NAS message to the UE including one or more cell IDs, relay UE IDs, path IDs to be disconnected), and / or can request the UE to disconnect completely and register to the network again in case the number of hops between the UE and the radio access network exceeds a preconfigured number of hops.

[0156] Maintaining security of PC5 unicast link over direct path addition / change over unchanged indirect path Implication In certain scenarios, the U2N direct / indirect path can be added or changed.

[0157] Figure 6 Signaling and processing diagrams for indirect path change under a single procedure are schematically shown, involving a remote UE (REM-UE), a source relay UE (S-REL-UE), a target relay UE (T-REL-UE), and a gNB or other network access device.

[0158] 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.

[0159] Then, in step S601, information for measurement, configuration, and reporting (MCR) 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 can decide in step S602 to change the indirect path (DEC CHG IDP), e.g., triggered by insufficient transmission quality, etc. As a result, in steps S603a and S603b, the gNB sends respective RRC reconfiguration messages (RRC RECON) to the source relay UE and the target relay UE (possibly already selected based on the exchanged information or other available information about potentially available relay UEs). Additionally, in step S604, the gNB sends an additional RRC reconfiguration message to the remote UE.

[0160] In step S605, an RRC connection setup (PC5-RRC CON EST) is performed between the remote UE and the target relay UE over the PC5 interface. In response, in steps S606a and S606b, respective RRC reconfiguration complete messages (RRC RECON COMPL) are sent 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 between the UE and the gNB in step S607 using the direct path (UL / DL DP-D) and the new indirect path (UL / DL IDP-D) via the target relay UE.

[0161] Figure 7A further signaling and processing diagram is schematically shown for direct path change under a single procedure, involving a remote UE (REM-UE), a relay UE (REL-UE), and gNBs or other access devices of a control source primary cell (PCell) (S-PC), a relay UE serving cell (REL-UE-SC) UE, and a target PCell (T-PC).

[0162] In a handover scenario as Figure 7 shown, a cell change can be triggered by layer 3 (L3) measurements and can be completed by RRC signaling for changing the PCell (i.e., reconfiguration with sync information element).

[0163] In step S700, a direct path (UL / DL DP) between the remote UE and the source PCell of the gNB is provided. Further, the relay UE is used for providing an indirect path (UL / DL IDP) for UL / DL data between the remote UE and the serving cell of the gNB of the relay UE.

[0164] Then, in step S701, information for measurement, configuration, and reporting (MCR) is exchanged between the remote UE, the relay UE, at least some of the source PCell and the serving cell of the relay UE. Based on the exchanged information, the gNB can 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 insufficient transmission quality, etc. As a result, in step S703, an RRC reconfiguration operation (RRC RECON) is performed between the relay UE and the serving cell of the relay UE of the gNB. In response, the source PCell of the gNB sends an RRC reconfiguration message (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 sends in step S706a a corresponding RRC reconfiguration completion message (RRC RECON COMPL MSG) to the target PCell and in step S706b a corresponding RRC reconfiguration completion message (RRC RECON COMPL MSG) to the serving cell of the relay UE.

[0165] Then, as a result, UL / DL data can be exchanged between the UE and the gNB in step S707 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 serving cell of the relay UE.

[0166] As, for example, forFigure 7 Exemplary challenges of the direct path addition / change procedure can use a PCell handover (HO) procedure with RRCReconfiguration WithSync Residing to the target PCell. RRCReconfigurationWithSync Can allow performing masterKeyUpdate (primary key update) so that the L2 U2N remote UE can be configured to use the new set of cryptographic keys for data / signaling radio bearers (SRB / DRB) after the PCell HO (i.e. direct path addition / change) and start sending data with the new keys in PDCP. However, it can be that some data protected by the old set of keys on the indirect path can have been sent on the indirect path and left in the PDCP buffer at the access device, or data is still left in the PDCP RLC buffer of the relay UE and will be sent to the gNB later. In this case, the access device can no longer be able to securely process those packets because it now has the new set of keys.

[0167] Figure 6 And 7 Another specific challenge in the above procedures for path addition and / or change involves how to update the security key material (e.g. AS keys) and how to be able to handle protected information that can have been exchanged. The change of keys can lead to a situation where one of the endpoints receives some information protected with a cryptographic key that is not valid / usable anymore due to the key being updated.

[0168] Figure 8 Signaling and processing diagrams for key update are schematically shown. In examples, the key update procedure can be related to a dual connectivity procedure as defined in clause 6.10 in TS 33.501, for example.

[0169] The dual connectivity procedure involves security functions for UEs that support simultaneous connectivity to more than one NG-RAN node (e.g. multi-radio dual connectivity (MR-DC) with 5GC as described in TS 37.340), where the UE can be connected to one node (e.g. ng-eNB) acting as a master node (MN) and one node (e.g. gNB) acting as a secondary node (SN). In examples, the SN can be connected to the 5GC and the MN can be connected to the SN via an Xn interface.

[0170] When the MN is performing an SN addition procedure (i.e., initial offload of one or more radio bearers to an SN) or an SN modification procedure that requires updating the key KSN of the SN (e.g., as in clauses 10.2.2 and 10.3.2 in TS 37.340), the MN can derive KSN (e.g., as defined in clause 6.10.3.2). The MN can maintain an SN counter (e.g., as defined in clause 6.10.3.1).

[0171] When performing a procedure for adding a subsequent radio bearer to the same SN, the MN can assign a radio bearer identity that has not been used previously since the last KSN change for each new radio bearer. 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 can increment the SN counter and compute a refreshed KSN, and then can perform an SN modification procedure to update the KSN.

[0172] Dual connectivity procedures with encryption / decryption and integrity protection activation follow the steps outlined in Figure 8 clause 6.10.3.2.

[0173] 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 available resources, configurations, and algorithms at the SN. If a new key is needed, the MN computes KSN and delivers KSN to the SN. UE security capabilities (e.g., as in subclause 6.10.4) and UP security policies received from a session management function (SMF) can also be sent to the SN. In case of packet data unit (PDU) split, UP integrity protection and encryption activation decisions from the MN (e.g., as described in subclause 6.10.4) can also be included.

[0174] In step S803 (CAP NEG, UP PROT, AL SEL), the SN performs capability negotiation to allocate necessary resources and selects encryption and integrity algorithms with the highest priority from its configured list and also present in the UE security capabilities. If a new KSN is delivered to the SN, the SN computes the required RRC. When deriving the RRC key, the user plane (UP) keys can be derived simultaneously. The SN can also activate UP security policies (e.g., as described in subclause 6.10.4).

[0175] In step S804, the SN sends an SN addition / modification confirmation (SN SDD / MOD REQ ACK) to the MN indicating the availability of the requested resources and identifiers of the selected algorithms for the requested data radio bearers (DRBs) and / or signaling radio bearers (SRBs) for the UE. In addition, the UP integrity protection and ciphering indication can be sent to the MN.

[0176] Step S805: The MN sends an RRC connection reconfiguration request (RRC CON RECON) to the UE indicating that the UE is configured with new DRBs and / or SRBs for the SN. The MN can include the SN counter parameter to indicate that a new KSN is needed and the UE can compute the KSN for the SN. The MN forwards the UE configuration parameters (containing the algorithm identifiers received from the SN in step S804) and the UP integrity protection and ciphering indication (received from the SN in step S804) to the UE (further details are referred to subclause 6.10.3.3).

[0177] In step 806, the UE accepts the RRC connection reconfiguration request after verifying its integrity. If the SN counter parameter is included, the UE can compute the KSN for the SN. The UE can also compute the required RRC and UP keys and activate RRC and UP protection according to the indications received for the associated SRBs and / or DRBs, respectively. The UE then sends an RRC reconfiguration complete (RRC CON RECON COMPL) to the MN. At this point, the UE can activate the selected ciphering / deciphering and integrity protection keys with the SN.

[0178] 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 about the configuration result. Upon reception of this message, the SN can activate the selected ciphering / deciphering and integrity protection (ACT CIPH+IN-PRO) with the UE in steps S806a and S807a. If the SN does not activate ciphering / deciphering and integrity protection with the UE at this stage, the SN can activate ciphering / deciphering and integrity protection upon reception of a random access request from the UE in step S808 (RAN ACC PROC).

[0179] In embodiments, which can be combined with any other embodiment or used independently, for regular user data (e.g., data sent in UP, e.g., using IP), the access device (e.g., gNB) can be configured with a policy to determine that UP data that cannot be securely processed will be discarded, while the endpoints (remote UE and / or access device) can send a request that triggers retransmission.

[0180] In another embodiment, the endpoints (remote UE and / or access device) can be configured (e.g. by means of a policy) with a small time or counter window which is used to determine the time that needs to elapse before the old key is discarded and / or the new key is enabled. This can allow having both sets of keys active at the same time and can allow processing data that can have been protected with the old key when the new set of keys is already active. The configuration can also determine which keys should be used first, e.g. the old key.

[0181] In another embodiment, the old U2N relay (e.g. relay UE) can be instructed to release the connection (so that all buffered RLC messages are released) before the key update command is executed.

[0182] In another embodiment, the access device (e.g. gNB) can be required to empty the PDCP buffer before the key update command is executed and then only indicate the new path / key set to the remote UE.

[0183] In another embodiment, the remote UE can be configured to send the RRC reconfiguration complete message over the direct path and not over the indirect path when the key update command is executed. This has the advantage of ensuring that the message is not saved in the buffer of the U2N relay and cannot be processed correctly.

[0184] In another embodiment, once the remote UE sends the RRC reconfiguration complete message, the remote UE can be configured to only send data over the direct path until the timer expires and / or data is received over the indirect path. This has the advantage of ensuring that the message is not saved in the buffer of the U2N relay and cannot be processed correctly.

[0185] While the application 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 application can be applied to various types of UE or terminal devices in various wireless networks, such as mobile phones, vital signs monitoring / telemetry devices, smart watches, detectors, vehicles (for vehicle-to-vehicle (V2V) or more generally vehicle-to-anything (V2X) communication), V2X devices, Internet of Things (IoT) hubs, IoT devices (including low-power medical sensors for health monitoring for hospital use or first responder use, medical (emergency) diagnostic and treatment devices), virtual reality (VR) headsets, etc.

[0186] 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 articles "a" or "an" do not exclude a plurality. A single processor or other unit can 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 application. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the application can be practiced in many ways, and therefore should not be construed as limited to the examples disclosed. It should also be appreciated that the use of particular terminology when describing certain features or aspects of the application should not be taken to indicate that such terminology is being redefined herein to be limited to include any particular characteristics of the features or aspects of the application with which that terminology is associated. Further, the phraseology "at least one of A, B, and C," as used herein does not exclude A, B, and C individually, but rather means that A alone, B alone, C alone, or any combination of A, B, and C can be employed.

[0187] A single unit or device can 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.

[0188] The described operations of the above-described embodiments can be implemented as program code means of a computer program and / or as dedicated hardware of the relevant network device or function, respectively. The computer program can be stored / distributed on a suitable medium, such as an optical storage medium or a solid-state storage medium supplied with the other (base) hardware, but also distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

1. A communication device in a wireless network, wherein, The device supports multipath communication, and the communication device is adapted to: - If the communication device is within the coverage area of ​​the first access device, it is connected to the first access device via a direct path; as well as - Connected to a second access device via an indirect path through another device, particularly a relay device; as well as - Receive first configuration information from the first access device or the second access device via the direct path or via the indirect path or both, wherein the first configuration information includes at least parameters regarding a first radio network temporary identifier (RNTI), the first RNTI being assigned to the direct path for the first access device to send scheduling information to the communication device on the direct path, and wherein the scheduling information can be a downlink, uplink, and / or sidelink; and - Receive second configuration information from the first access device or the second access device via the direct path and / or via the indirect path, wherein the second configuration information includes parameters regarding the second RNTI assigned to the indirect path; and Based on the received first configuration information and second configuration information, while performing multipath communication, the first RNTI is used to decode the scheduling information sent from the first access device, or the second RNTI is used to decode the scheduling information sent from the first access device.

2. The communication device according to claim 1, wherein, The second configuration information also includes one or more of the following parameters: - An optional parameter indicating the ability to use the second RNTI 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 should be used instead of the second RNTI to receive and / or decode information from the first access device, or - An optional parameter indicating the time for using the first RNTI and the second RNTI to receive and / or decode information from the first access device, or indicating the time for switching between the first RNTI and the second RNTI to receive and / or decode information from the first access device.

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

4. The communication device according to claim 1, 2 or 3, wherein, The communication device stores both the first RNTI and the second RNTI.

5. The communication device according to 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 the second RNTI, based on received optional parameters.

6. The communication device according to any one of the preceding claims, wherein, The first configuration information and / or the second configuration information indicate the number of RNTIs to be used and stored and / or the communication purpose of the RNTIs.

7. The communication device according to any one of the preceding claims, wherein, The first access device and the second access device connected to the communication device are the same access device.

8. The communication device according to any one of the preceding claims, wherein, The communication device is connected to the first access device and the second access device, which are different distributed units belonging to the same centralized unit of a single access device.

9. The communication device according to any one of the preceding claims, wherein, Both the first RNTI and the second RNTI are cell RNTIs.

10. The communication device according to any one of the preceding claims, further adapted to: - A location request is sent to the core network or received from the core network an indication of a location method via the direct path to the first access device and the indirect path to the second access device, respectively. - Send a connection information report to the core network, the connection information report including one or more of the following related to the direct path and the indirect path: access device cell identifier, access device coverage area, access device receive power, information about whether the access device is used for the direct path or the indirect path, the location and / or transmit power and / or coverage area of ​​one or more relay devices in the indirect path.

11. The communication device according to any one of the preceding claims, wherein the device is configured with a time or counter window for determining the time required to elapse before discarding an old encryption key and / or enabling a new encryption key.

12. The communication device according to any one of the preceding claims, configured to instruct a relay to release the connection of the indirect path before executing a key update command.

13. The communication device according to claim 12, configured to: when executing the key update command, send a reconfiguration completion message via the direct path but not via the indirect path.

14. The communication device of claim 13, further configured to: transmit data via the direct path until a timer expires and / or data is received via the indirect path.

15. An access device in a wireless network, wherein, The access device supports multipath communication with the communication device, and the access device is adapted to: - If the communication device is within the coverage area of ​​the access device, then it is connected to the communication device via a direct path; and - Connected to the communication device via an indirect path via another device, particularly a relay device; as well as - Determine that the communication devices via each of the direct path and the indirect path are the same device; and - Generate and transmit configuration information to the communication device via the direct path and / or via the indirect path, wherein the configuration information includes at least parameters regarding a Radio Network Temporary Identifier (RNTI), the RNTI being used by the access device to transmit scheduling information to the communication device on the direct path, and wherein the scheduling information can be a downlink, uplink, and / or sidelink; and wherein the base station schedules the RNTI to be shared across the two paths.

16. The access device according to claim 15, adapted to: A single RNTI is generated and shared across the direct path and the indirect path.

17. The access device according to claim 15 or 16, further adapted to: - Request a connection information report related to the communication device, wherein... The connectivity information report includes one or more of the following: access device cell identifier, access device coverage area, access device transmit power, approximate location of the communication device or approximate distance and / or angle to one or more of the first and second access devices, information about whether the reported cell identifier is from the first access device for the direct path or from the second access device for the indirect path, location and / or transmit power and / or coverage area of ​​relay devices in the indirect path, or related measurement information, particularly timing and / or timing advance information, or approximate distance and / or angle to one or more relay devices; - Receive the connection information report related to the direct path and the indirect path, and - Determine the location of the communication device.

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

19. The access device according to any one of claims 15 to 18, further configured to: report the cell identifier of a cell serving a relay device to which the communication device is connected via multipath communication and having optimal signal quality and / or minimum distance to the communication device.

20. A wireless network, comprising: The access device according to any one of claims 15 to 19, and At least one communication device according to any one of claims 1 to 14.

21. A method for operating a communication device supporting multipath communication, wherein the method comprises: - If the communication device is within the coverage area of ​​the first access device, then the communication device is connected to the first access device via a direct path; as well as - The communication device is connected to a second access device via an indirect path through another device, which is in particular a relay device; as well as The communication device receives first configuration information from the first access device or the second access device via the direct path and / or via the indirect path, wherein the first configuration information includes at least parameters regarding a first radio network temporary identifier (RNTI), the first RNTI being assigned to the direct path for the first access device to send scheduling information to the communication device on the direct path, and wherein the scheduling information can be a downlink, uplink, and / or sidelink; and The communication device receives second configuration information from the first access device or the second access device via the direct path and / or via the indirect path, wherein the second configuration information includes parameters regarding a second radio network temporary identifier (RNTI) assigned to the indirect path; and The communication device, based on the received first configuration information and second configuration information, performs multipath communication while using the first RNTI to decode the scheduling information sent from the first access device, or using the second RNTI to decode the scheduling information sent from the first access device.

22. The method according to claim 21, wherein, The second configuration information also includes one or more of the following parameters: - An optional parameter indicating the ability to use the second RNTI 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 should be used instead of the second RNTI to receive and / or decode information from the first access device, or - An optional parameter indicating the time for using the first RNTI and the second RNTI to receive and / or decode information from the first access device, or indicating the time for switching between the first RNTI and the second RNTI to receive and / or decode information from the first access device.

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

24. The method according to claim 21, 22 or 23, wherein, The communication device stores both the first RNTI and the second RNTI.

25. The method according to 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 the received optional parameters.

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

27. The method according to any one of claims 21 to 26, wherein, The communication device is connected to the first base station device and the second base station device, which are different distributed units belonging to the same centralized unit of a single base station device.

28. The method according to claims 21 to 27, wherein, Both the first RNTI and the second RNTI are cell RNTIs.

29. The method according to any one of claims 21 to 28, further comprising: - An access device requests a connection information report related to a communication device, wherein the connection information report includes one or more of the following related to the direct path and the indirect path: access device cell identifier, access device coverage area, access device transmit power, approximate location of the communication device or approximate distance and / or angle to one or more of the first access device and the second access device, information about whether the reported cell identifier is from the first access device for the direct path or from the second access device for the indirect path, location and / or transmit power and / or coverage area of ​​relay devices in the indirect path, or related measurement information, particularly timing and / or timing advance information, or approximate distance and / or angle to one or more relay devices; - Receive from the communication device the connection information report related to the direct path and the indirect path; and - Determine 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 performing the method according to any one of claims 21 to 29.

Images