[go: up one dir, main page]

WO2025036813A1 - Dispositif de relais à trajets multiples de relais de liaison latérale et son procédé de fonctionnement - Google Patents

Dispositif de relais à trajets multiples de relais de liaison latérale et son procédé de fonctionnement Download PDF

Info

Publication number
WO2025036813A1
WO2025036813A1 PCT/EP2024/072463 EP2024072463W WO2025036813A1 WO 2025036813 A1 WO2025036813 A1 WO 2025036813A1 EP 2024072463 W EP2024072463 W EP 2024072463W WO 2025036813 A1 WO2025036813 A1 WO 2025036813A1
Authority
WO
WIPO (PCT)
Prior art keywords
path
rnti
access device
communication device
indirect
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/EP2024/072463
Other languages
English (en)
Inventor
Dan Jiang
Walter Dees
Robert James Davies
Oscar Garcia Morchon
Jantje JANSSEN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips NV filed Critical Koninklijke Philips NV
Publication of WO2025036813A1 publication Critical patent/WO2025036813A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/15—Setup of multiple wireless link connections

Definitions

  • This invention relates to sidelink relay multi-path relaying in 5G New Radio (NR) wireless communication systems.
  • NR New Radio
  • a layer 2 (L2) UE-to-Network (U2N) sidelink relay is enhanced to support multi-path relaying as defined in the work item description (WID) RP-223501 .
  • a multi-path relaying capable L2 U2N Remote User Equipment (UE) in the network coverage of the base station can establish two communication paths with the same base station, namely direct path directly over the L2 U2N Remote UE’s NR radio air interface (Uu interface) and indirect path indirectly via an L2 U2N Relay UE.
  • UE User Equipment
  • R18 L2 U2N sidelink relay multi-path relaying is scoped to support the case that the multi-path L2 U2N Remote UEs are connected to the same base station (e.g., gNB and/or gNB-CU) on both the direct path and the indirect path, but the two paths may belong to different serving cells and gNB-DUs in a 5G NR CU-DU split architecture.
  • the base station e.g., gNB and/or gNB-CU
  • the two paths may belong to different serving cells and gNB-DUs in a 5G NR CU-DU split architecture.
  • a gNB-CU can connect to multiple gNB-DUs and a gNB-DU can have multiple Transmission Reception Points (TRPs). All gNB-DUs connected to the same gNB-CU may belong to the same base station.
  • TRPs Transmission Reception Points
  • the L2 U2N Remote UE may connect to gNB/gNB-CU on either the direct path or the indirect path, but not on both paths simultaneously.
  • a path switch procedure for service continuity between the direct path and the indirect path is defined in 3GPP specification TS 38.300 V17.5.0, clause 16.12.6 and the corresponding procedure for the 5G NR gNB CU-DU split architecture is defined in 3GPP specification TS 38.401 V17.5.0, clause 8.19.4.
  • the L2 U2N Remote UE i.e. , a legacy UE in the coverage of the serving cell
  • the L2 U2N Remote UE is connected on the direct path to the Source gNB-DU and gNB-CU.
  • Source gNB-DU will follow the UE Initial Access procedure defined in clause 8.1 of TS 38.401 V17.5.0 to allocate a Cell Radio Network Temporary Identifier (C-RNTI) for the Remote UE and inform gNB-CU the allocated C-RNTI, then gNB-CU will assign this C-RNTI to Remote UE in the RRCSetup message encapsulated in the DL RRC MESSAGE TRANSFER message via Source gNB-DU.
  • C-RNTI Cell Radio Network Temporary Identifier
  • the masterCellGroup IE in the RRCSetup message contains a newUE-ldentity filed to configure the C-RNTI value of the Remote UE with synchronous RRC reconfiguration.
  • Source gNB-DU can follow a similar procedure to allocate a new C-RNTI for the Remote UE and inform gNB-CU about the allocated new C-RNTI, then gNB-CU will assign the new C-RNTI to the Remote UE in RRCReestablishment and/or RRCResume message encapsulated in the DL RRC MESSAGE TRANSFER message via Source gNB-DU as defined in clauses 8.7 and 8.6.2 of TS 38.401 V17.5.0 respectively.
  • Source gNB-DU will use its allocated C-RNTI to scramble/mask the downlink control information (DCI) transmitted on the Physical Downlink Control Channel (PDCCH) for transmitting the scheduling information of the Physical Downlink Shared Channel (PDSCH) / Physical Uplink Shared Channel (PUSCH) / Physical Uplink Control Channel (PUCCH) for the Remote UE; and Remote UE will use the assigned C-RNTI to check scram bled/masked DCI scheduling information on the PDCCH and detect if there are any scheduling assignments/grants from Source gNB-DU destinated to it.
  • DCI downlink control information
  • PDCCH Physical Downlink Control Channel
  • Remote UE will use the assigned C-RNTI to check scram bled/masked DCI scheduling information on the PDCCH and detect if there are any scheduling assignments/grants from Source gNB-DU destinated to it.
  • the same C-RNTI allocated by the gNB-DU is used for PDCCH/DCI scrambling/masking and detec- tion/check.
  • gNB-CU may decide to switch the Remote UE from the direct path to the indirect path after evaluating the measurements reports from the Remote UE.
  • step 4 gNB-CU requests the Target gNB-DU, which serves the Target Relay UE, to setup a UE context for the Remote UE via the UE CONTEXT SETUP REQUEST message.
  • Target gNB-DU will return the allocated new C-RNTI for Remote UE in the UE CONTEXT SETUP RESPONSE message.
  • gNB-CU will assign the new C-RNTI to the Remote UE in the RRCReconfiguration message encapsulated in the UE CONTEXT MODIFICATION REQUEST message sent to the Source gNB-DU, which will extract the encapsulated RRCReconfiguration message and forward the message to the Remote UE over the direct path.
  • the new C-RNTI value is carried in the sl-UEIdenti- tyRemote field of the sl-L2RemoteUE-Config information element (IE) included in RRCReconfiguration.
  • Remote UE i.e. , L2 U2N Remote UE
  • Remote UE will use the newly assigned C-RNTI value by the Target gNB-DU on the indirect path when C-RNTI is needed.
  • the multi-path L2 U2N Remote UE i.e., multi-path Remote UE
  • the multi-path L2 U2N Remote UE has connections with the gNB/gNB- CU on the direct path and the indirect path simultaneously via the respective serving gNB-DUs.
  • gNB-DU1 will continue to use the old C- RNTI to scramble/mask PDCCH/DCI for transmitting the scheduling information of PDSCH/PUSCH/PUCCH destinated to Remote UE on the direct path.
  • the multi-path Remote UE will not be able to check and decode the scram- bled/masked PDCCH/DCI scheduling information successfully on the direct path with the new C-RNTI value. Then the direct path fails completely.
  • a communication device e.g., a mobile, or stationary, or intermittently mobile and stationary UE in a wireless network
  • the communication device supports multi-path relaying.
  • the communication device may be adapted to:
  • - connect to a second access device through an indirect path via another device e.g., a relay device
  • the first configuration information includes at least a parameter about a first radio network temporary identifier (RNTI) assigned to the direct path for use by the first access device to transmit a scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, uplink and sidelink; and
  • RNTI radio network temporary identifier
  • the second configuration information includes a parameter about a second radio network temporary identifier (RNTI) assigned to the indirect path, and - use the first RNTI to decode the scheduling information transmitted from the first access device or use the second RNTI to decode the scheduling information transmitted from the first access device whilst performing multi-path communication, depending on the received first and second configuration information.
  • RNTI radio network temporary identifier
  • an access device e.g., a base station such as a gNB
  • the access device supports multi-path communication with the communication device of the first aspect, the access device being adapted to:
  • - connect to the communication device through an indirect path via another device e.g., a relay device
  • the configuration information includes at least a parameter about a radio network temporary identifier (RNTI) which may be used by the access device to transmit a scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, uplink and sidelink; and wherein the access device arranges for the RNTI to be shared across both paths.
  • RNTI radio network temporary identifier
  • a wireless network which comprises an access device of the second aspect and at least one communication device of the first aspect.
  • a method for operating a communication device which supports multi-path communication comprises:
  • the communication device connecting to a first access device through a direct path if the communication device is in coverage of the first access device;
  • the communication device connecting to a second access device through an indirect path via another device (e.g., a relay device);
  • the communication device receiving a first configuration information from the first or second access device either through the direct path or through the indirect path or both, wherein the first configuration information includes at least a parameter about a first radio network temporary identifier (RNTI) assigned to the direct path for use by the first access device to transmit a scheduling information to the communication device on the direct path, and wherein the scheduling information can be downlink, uplink and sidelink; and
  • RNTI radio network temporary identifier
  • the second configuration information includes a parameter about a second radio network temporary identifier (RNTI) assigned to the indirect path, and
  • RNTI radio network temporary identifier
  • the communication device using the first RNTI to decode the scheduling information transmitted from the first access device or use the second RNTI to decode the scheduling information transmitted from the first access device whilst performing multi-path communication, depending on the received first and second configuration information.
  • a computer program product which may comprise code means for producing the steps of the method according to the fourth aspect when run on a computer device.
  • the second configuration information may further include one or more of the following parameters:
  • the first and second configuration information may be combined in a single message.
  • the communication device may store both the first and second RNTIs.
  • the communication device may be configured to select which of the first RNTI and the second RNTI to use, or to switch between the first RNTI and second RNTI based on the received optional parameters.
  • the first and/or second configuration information may indicate the number of RNTIs to be used and stored and/or a communication purpose of an RNTI.
  • the first access device and the second access device, to which the communication device is connected may be the same access device.
  • the communication device may be connected to the first access device and the second access device, the first and second access devices being different distributed units belonging to the same centralized unit of a single access device.
  • the communication device may be connected to the first access device and the second access device, the first and second access devices being different and interconnected by an interface to exchange messages in two directions.
  • the first RNTI and the second RNTI may both be cell-RNTIs (C-RNTIs).
  • the access device may be adapted to generate and share a single RNTI across the direct path and the indirect path.
  • the communication device may further be adapted to: send a localization request to a core network or receive a localization request from the core network indicating a localization method through the direct and indirect paths to the first and second access devices, respectively, send a connection information report to the core network including one or more of an access device cell identity, an access device coverage, an access device reception power, information about whether an access device is used for the direct or the indirect path, a location and/or transmission power and/or coverage area of one or more relay devices in the indirect path, related to the direct and indirect paths.
  • the communication device may be configured with a time or counter window that determines a time that needs to pass before discarding old encryption keys and/or enabling new encryption keys.
  • the communication device may be configured to instruct a relay to release a connection of the indirect path prior to the execution of a key update command.
  • the communication device may be configured to send a reconfiguration complete message over the direct path, but not over the indirect path, when the key update command is executed.
  • the communication device may be configured to send data over the direct path until a timer expires and/or data is received through the indirect path.
  • the access device may be adapted to: request a connection information report related to the communication device, where the connection information report includes one or more of an access device cell identity, an access device coverage, an access device transmission power, a rough location of the communication device or a rough distance and/or angle to one or more of the first and second access devices, information about whether a reported cell identity is from the first access device for the direct path or the second access device for the indirect path, a location and/or transmission power and/or coverage area of relay devices in the indirect path, or related measurement information, timing and/or timing advance information in particular, or a rough distance and/or angle to one or more relay devices, related to the direct and indirect paths; receive the connection information report related to the direct and indirect paths, and determine the location of the communication device.
  • the connection information report includes one or more of an access device cell identity, an access device coverage, an access device transmission power, a rough location of the communication device or a rough distance and/or angle to one or more of the first and second access devices, information about whether a reported cell identity is from
  • the access device may be configured to discard user plane data that cannot be securely processed.
  • the access device may be configured to report a cell identity of a cell that serves a relay device to which the communication device is connected via multi-path communication and that has the best signal quality and/or the smallest distance to the communication device.
  • the method may further comprise: requesting by an access device a connection information report related to a communication device, where the connection information report includes one or more of an access device cell identity, an access device coverage, an access device transmission power, a rough location of the communication device or a rough distance and/or angle to one or more of the first and second access devices, information about whether a reported cell identity is from the first access device for the direct path or the second access device for the indirect path, a location and/or transmission power and/or coverage area of relay devices in the indirect path, or related measurement information, timing and/or timing advance information in particular, or a rough distance and/or angle to one or more relay devices, related to the direct and indirect paths, receiving from the communication device the connection information report related to the direct and indirect paths, and determining the location of the communication device.
  • the connection information report includes one or more of an access device cell identity, an access device coverage, an access device transmission power, a rough location of the communication device or a rough distance and/or angle to one or more of the first and second access devices, information about
  • the above device of the first aspect may be implemented based on discrete hardware circuitries with discrete hardware components, integrated chips, or arrangements of chip modules, or based on signal processing devices or chips controlled by software routines or programs stored in memories, written on a computer readable media, or downloaded from a network, such as the Internet.
  • the communication device of claim 1 may have similar and/or identical preferred embodiments, in particular, as defined in the dependent claims.
  • Fig. 1 schematically shows a diagram of a sidelink relay multi-path relaying system
  • Fig. 2 schematically shows a diagram of a sidelink relay multi-path relaying in a gNB CU-DU split architecture
  • Fig. 3 schematically shows a signalling and processing procedure of an inter-DU indirect path addition on top of a direct path for a multi-path Remote LIE with a legacy sidelink relay path switch procedure;
  • Fig. 4 schematically shows a signalling and processing procedure of an inter-DU indirect path addition on top of a direct path for a multi-path Remote UE, according to an embodiment
  • Fig. 5 schematically shows another signalling and processing procedure of an inter-DU indirect path addition on top of a direct path for a multi-path Remote UE, according to an embodiment
  • Fig. 6 schematically shows a signaling and processing diagram for indirect path change under a single procedure
  • Fig. 7 schematically shows a signaling and processing diagram for direct path change under a single procedure
  • Fig. 8 schematically shows a signaling and processing diagram for key update.
  • gNB 5G terminology
  • the gNB is intended to mean access device such as a cellular base station or a Wi-Fi access point.
  • the gNB is part of the radio access network (RAN), which provides an interface to functions in the core network (CN).
  • the RAN is part of a wireless communication network. It implements a radio access technology (RAT).
  • RAT radio access technology
  • it resides between a communication device such as a mobile phone, a computer, or any remotely controlled machine and provides connection with its CN.
  • the CN is the communication network’s core part, which offers numerous services to customers who are interconnected via the RAN. More specifically, it directs communication streams over the communication network and possibly other networks.
  • an access and mobility management function terminates the control plane of different access networks onto the 5G CN (5GC) and controls which UEs can access the 5GC to exchange traffic. It also manages the mobility of UEs when they roam from one gNB to another for session/service continuity, whenever possible.
  • an Information Element designates (a group of) information which may be included within a signalling message or data flow which is sent across an interface (examples may include QoS (Quality of Service) definitions, setup parameters, user identifiers etc.).
  • a location management function is a network entity defined in 5G Core Network to provide positioning functionality by means to determine the geographic position of a mobile device based on downlink, uplink and sidelink location measuring radio signals.
  • a gateway mobile location center is used for active mobile positioning, meaning that it triggers specific activities on the network to retrieve a subscriber's location in real-time.
  • a GMLC can connect with additional precise location components in the network.
  • the GMLC may contain functionality required to support LCS (Location Services).
  • LCS Local Mobile Network
  • PLMN Public Land Mobile Network
  • the GMLC is the first node an external LCS client accesses in the network.
  • OAM operations, administration, and management or maintenance
  • OAM operations, administration, and management or maintenance
  • ProSe proximity service
  • Relay UE is a communication device that helps another UE to communicate to the gNB (i.e. , access device) by relaying application and network data traffic in two directions between the other UE and the gNB.
  • the local communication between the Relay UE and the other UE is called D2D communication or Sidelink communication or PC5 communication.
  • the abbreviation “PC5” designates an interface for sidelink communication as defined by ProSe. Furthermore, the abbreviation “UL” is used for the uplink direction from the communication device (e.g., UE) to the access device (e.g., gNB), the abbreviation “DL” for the downlink direction from the access device (e.g., gNB) to the communication device (e.g., UE), and the abbreviation “SL” for sidelink communication between two or more communication devices (e.g., UEs).
  • a UE can be connected via the Relay UE and acts in a role of “Remote UE”. This situation means that the Remote UE has an indirect network connection to the CN as opposed to a direct network connection that is the normal case (cf. 3GPP specification TS 22.261 V16.10.0).
  • 3GPP Technical Reports TR 23.733 v15.1.0 and TR 36.746 v15.1 .1 provide studies on architectural enhancements e.g. to enable an loT device (in a role of Remote UE) to operate on very low power by using a Relay UE to connect to the wider network. Because the Relay UE is physically very close, it can be reached using very low power transmissions. This work also includes security, speed and stability improvements to ProSe. These extensions of ProSe are called enhanced ProSe (“eProSe”).
  • eProSe enhanced relaying architecture that operates in the second protocol layer (i.e.
  • L2 L2
  • IP Internet Protocol
  • PDCP Packet Data Convergence Protocol
  • an element for implementing scheduling mechanisms may be the Radio Resource Control (RRC) protocol which can operate end-to-end to UEs, potentially over one or more hops taking into consideration the above relay architecture on the second protocol layer (i.e. L2).
  • RRC Radio Resource Control
  • a further element may be the use of a downlink control information (DCI), which is a short message sent in a low-bitrate control channel (e.g. Physical Downlink Control Channel (PDCCH)) with a special blindly detectable modulation or coding.
  • DCI downlink control information
  • PDCH Physical Downlink Control Channel
  • various DCI formats can be defined with different information content.
  • a multi-path L2 U2N Remote UE (REM-UE) 10 is connected to a base station (BS) 20 on a direct path (DP) and an indirect path (IP) simultaneously, where the direct path consists of a Uu interface between the L2 LI2N Remote UE 10 and the base station 20, the indirect path consists of a PC5 interface between the L2 U2N Remote UE 10 and a L2 U2N Relay UE (REL-UE) 12 and a Uu interface between the L2 U2N Relay UE 12 and the base station 20.
  • Both Remote UE 10 and Relay UE 12 are located within a coverage area (COV) of the base station 20.
  • Fig. 2 schematically shows a diagram of a sidelink relay multi-path relaying in a next generation radio access network (NG-RAN) CU-DU split architecture, where on a direct path (DP) a multi-path L2 U2N Remote UE 12 is connected to a first distributed unit gNB-DU1 32 of the split architecture over a Uu interface, on an indirect path (IP) the L2 U2N Remote UE 10 is connected to a L2 U2N Relay UE 12 over a PC5 interface and the L2 U2N Relay UE 12 is further connected to a second distributed unit gNB-DU2 34 of the split architecture over a Uu interface, and both gNB-DU1 32 and gNB-DU2 34 are connected to a same central unit gNB-CU 30 of the split architecture.
  • DP direct path
  • IP indirect path
  • a legacy L2 U2N Relay UE 12 may indicate the support of R17 L2 U2N relaying function to NG-RAN and AMF by using an indication field relayUE-Operation-L2-r17 ASN.1 IE which is included in the UE-NR-Ca- pability ASN.1 IE defined in clause 6.3.3 of TS 38.331 V17.5.0.
  • Fig. 2 assume the multi-path L2 U2N Remote UE 10 is firstly connected via the gNB-DU1 32 to the gNB-CU 30 on the direct path; during the direct path establishment, the L2 U2N Remote UE 10 indicates to the gNB-CU 30 and a 5G core access and mobility management function (AMF, not shown) its support of R18 sidelink relay multi-path relaying in a Non Access Stratum (NAS) UERadio- Capability IE in an initial access/attach; then at a later time, according to measurements reports received from the L2 U2N Remote UE 10 on the direct path, the gNB- CU 30 decides to add the indirect path for the L2 U2N Remote UE 10 to use the multi-path relaying function.
  • AMF 5G core access and mobility management function
  • the selected indirect path is routed via the L2 U2N Relay UE 12 served by the gNB-DU2 34, which is an inter-DU indirect path addition on top of direct path procedure for the multi-path L2 U2N Remote UE 10.
  • the NAS is a functional layer running between the UE and the CN, which supports traffic and signalling messages between the CN and UE.
  • the multi-path L2 U2N Remote UE 10 may firstly be connected via the gNB-DU2 34 to the gNB-CU 30 on the indirect path; the L2 U2N Remote UE 10 may use the legacy R17 sidelink relay indirect path RRC establishment procedure to establish the indirect path; during the indirect path establishment, the L2 U2N Remote UE 10 may then indicate to the gNB-CU 30 and the AMF its support of R18 sidelink relay multi-path relaying in an NAS UERadioCapability IE in an initial access/attach; then at a later time, according to measurements reports received from the L2 U2N Remote UE 10 on the indirect path, the gNB-CU 30 may decide to add the direct path for the L2 U2N Remote UE 10 to use the multi-path relaying function.
  • the direct path is served by the gNB-DU1 32, which is an inter-DU direct path addition on top of indirect path procedure for the multi-path L2 U2N Remote UE 10.
  • the multi-path L2 U2N Remote UE 10 and/or the multi-path L2 U2N Relay UE 12 may indicate the support of multipath relaying function to NG-RAN and AMF by using e.g. an indication field re- moteUE-MultiPathOperation-L2 respectively relayUE-MultiPathOperation-L2 contained e.g. in the below defined RelayParameters-r18 ASN.1 IE which may be included in the UE-NR-Capability ASN.1 IE defined in clause 6.3.3 of TS 38.331 V17.5.0.
  • UE-NR-Capability-v1610 SEQUENCE ⁇ inDeviceCoexlnd-r16 ENUMERATED ⁇ supported ⁇ OPTIONAL, dl-DedicatedMessageSegmentation-r16 ENUMERATED ⁇ supported ⁇ OP ⁇
  • bap-Parameters-r16 BAP-Parameters-r16 OPTIONAL reference Time Provision-r16 ENUMERATED ⁇ supported ⁇ OPTIONAL
  • supportedBandListSidelink-r16 SEQUENCE (SIZE (1 maxBands)) OF BandSidelink-r16
  • RelayParameters-r17 SEQUENCE ⁇ relayUE-Operation-L2-r17 ENUMERATED ⁇ supported ⁇ OPTIONAL, remoteUE-Operation-L2-r17 ENUMERATED ⁇ supported ⁇ OPTIONAL, remoteUE-PathSwitchToldlelnactiveRelay-r17 ENUMERATED ⁇ supported ⁇ OP-
  • RelayParameters-r18 SEQUENCE ⁇ relayUE-MultiPathOperation-L2-r18 ENUMERATED ⁇ supported ⁇ OP-
  • the UE sends a relayed traffic support indication, which indicates that relay UE multipath communication is supported.
  • the base station 20 may broadcast the NG-RAN support of multi-path relaying information in a system information block (SIB) broadcasting and/or on-demand system information request and/or dedicated SIB request.
  • SIB system information block
  • Fig. 3 is a diagram showing a multi-path relaying signalling and processing procedure of inter-DU indirect path addition on top of direct path with legacy R17 sidelink relay direct-to-indirect path switch procedure.
  • a detailed description can be found from Figure 8.19.4.1 -1 in clause 8.19.4.1 of TS 38.401 V17.5.0 and Figure 8. xx.2 of 3GPP TDoc R3-230947.
  • step S301 the Remote UE 10 sends an RRC Setup Request to the gNB-DU1 32 which allocates in step S302 a first C-RNTI (C-RNTI1 ) to the Remote UE 10.
  • C-RNTI1 C-RNTI 1
  • step S303 the gNB-DU1 performs an initial UL RRC message transfer with the allocated C-RNTI1 to the gNB-CU 30 which stores the C-RNTI1 in step S304 and responds with a DL RRC message transfer in step S305.
  • the gNB-DU1 32 sends an RRC Setup Response with the allocated C- RNTI1 to the Remote UE 10 in step S306.
  • the Remote UE 10 configures the C-RNT11 in step S307 and responds to the gNB-DU1 32 with an RRC Setup Complete message in step S308.
  • the gNB-DU1 32 initiates a UL RRC message transfer to the gNB-CU 30 which sends an Initial UE message to the AMF in step S310.
  • the AMF responds with an Initial Context Setup Request in step S311 , which is forwarded by the gNB-CU 30 in step S312 to the gNB-DU1 32.
  • the gNB- DU1 32 sends in step S313 a Security Mode Command to the Remote UE 10 and responds to the gNB-CU 30 with a UE Context Setup Response in step S314.
  • the Remote UE 10 sends a Security Mode Complete message to the gNB-DU1 32 in step S315.
  • the gNB-DU1 32 initiates an UL RRC message transfer to the gNB-CU 30 in step S316, which responds with a DL RRC message transfer in step S317.
  • the gNB-DU1 32 sends an RRC Reconfiguration message to the Remote UE in step S318 and the Remote UE 10 responds in step S319 with an RRC Reconfiguration Complete message.
  • the gNB-DU1 32 initiates in step S320 an UL RRC Message Transfer to the gNB-CU 30 which sends an Initial Context Setup Response to the AMF in step S321 .
  • DL/UL data can be transferred from the Remote UE 10 over the direct path via the gNB-DU1 32 to the gNB-CU 30 in step S322.
  • the direct data transfer is then followed by a measurement configuration and reporting in step S323.
  • step S324 the gNB-CU 30 decides to add an indirect path via the Relay UE 12 and the gNB-DU2 34.
  • an RRC Reconfiguration of the Relay UE 12 is performed in step S325.
  • step S326 the gNB-CU 30 sends a UE Context Setup Request to the gNB-DU2 34 which, in response thereto, allocates in step S327 a new C-RNTI (C-RNTI2) to the Remote UE 10 and responds to the gNB-CU 30 with a UE Context Setup Response in step S328.
  • C-RNTI2 C-RNTI2
  • step S330 the gNB- CU 30 initiates a DL RRC Message Transfer for RRC Reconfiguration (including the new C-RNTI2) to the gNB-DU1 32.
  • step S331 the gNB-DU1 32 sends an RRC Reconfiguration message with the new C-RNTI2 to the Remote UE 10.
  • the Remote UE 10 Based on the received RRC Reconfiguration message with Sidelink Path Switch Configuration information and C-RNTI information, the Remote UE 10 performs in step S332 a PC5 Connection Establishment with the Relay UE 12 and configures and stores the received C-RNTI2 in step S333.
  • the Remote UE 10 responds in step S334 with an RRC Reconfiguration Complete message to the gNB-DU1 32.
  • the gNB-DU1 32 initiates in step S335 a corresponding UL RRC Message Transfer to the gNB-CU 30.
  • the direct path transmission fails because a different C-RNTI (i.e., C-RNTI2) has been configured at the Remote UE 10 compared to the gNB-DU1 32 (i.e., C-RNTI1 ).
  • C-RNTI1 a different C-RNTI
  • DL/UL data are only transmitted through the indirect path via the Relay UE 12 in step S337.
  • the L2 U2N Remote UE 10 when using the legacy R17 sidelink relay direct-to-indirect path switch procedure of Fig. 3, the L2 U2N Remote UE 10 will end in a state that the firstly assigned C-RNTI (i.e., C-RNT11 ) on the direct path allocated by the direct path serving gNB-DU1 32 will be overridden by the secondly assigned C-RNTI (i.e., C-RNTI2) on the indirect path allocated by the indirect path serving gNB-DU2 34 using R17 sidelink relay procedure.
  • C-RNTI i.e., C-RNT11
  • C-RNTI2 the secondly assigned C-RNTI
  • the multi-path L2 U2N Remote UE 10 stores a different C- RNTI (i.e., C-RNTI2) to detect and check the PDCCH/DCI scheduling information on the direct path scrambled/masked by the gNB-DU1 32 with C-RNTI1 . Then, the L2 U2N Remote UE 10 will fail to decode the PDCCH/DCI scheduling information from the gNB-DU1 32, and the direct path fails completely.
  • C-RNTI2 C-RNTI
  • Fig. 4 is a diagram according to an embodiment of the invention.
  • the diagram shows a multi-path relaying signalling and processing procedure of inter-DU indirect path addition on top of direct path.
  • the initial steps S401 to S423 are similar to the above steps S301 to S323 and are not described again here.
  • step S424 the gNB-CU 30 decides to add an indirect path via the Relay UE 12 and the gNB-DU2 34.
  • an RRC Reconfiguration of the Relay UE 12 is performed in step S425.
  • step S426 the gNB-CU 30 sends a UE Context Setup Request to the gNB-DU2 34 which, in response thereto, allocates in step S427 a new C-RNTI (C-RNTI2) to the Remote UE 10 and responds to the gNB-CU 30 with a UE Context Setup Response in step S428.
  • C-RNTI2 C-RNTI2
  • step S430 the gNB- CU 30 initiates a DL RRC Message Transfer for RRC Reconfiguration, which may include a newly defined IE SL-MultiPathConfig(directPathC-RNTI C-RNTI1, indi- rectPathC-RNTI C-RNTI2, or similar IE to the gNB-DU1 32.
  • step S431 the gNB- DU1 32 sends an RRC Reconfiguration message with the SL-MultiPathConfig IE (or similar IE) to the Remote UE 10.
  • the Remote UE 10 Based on the received RRC Reconfiguration with SL-Multi Path Config IE (or similar IE) with C-RNTI information, the Remote UE 10 performs in step S432 a PC5 Connection Establishment with the Relay UE 12 and configures and stores the received C-RNTI information in step S433. Then, the Remote UE 10 responds in step S434 with an RRC Reconfiguration Complete message to the gNB-DU1 32. The gNB-DU1 32 initiates in step S435 a corresponding UL RRC Message Transfer to the gNB-CU 30.
  • SL-Multi Path Config IE or similar IE
  • DL/UL data can be exchange through the direct path via the gNB-DU1 32 in step S436 using C-RNTI1 and through the indirect path via the Relay UE 12 and the gNB-DU2 34 in step S437 using C-RNTI2.
  • SL-MultiPathConfig IE (or similar IE) may be defined as below in the ReconfigurationWithSync IE which is further contained in RRCReconfig- uration.
  • RRCReconfiguration can be found in TS 38.331 V17.5.0, clause 6.2.2.
  • the SL-MultiPathConfig IE (or similar IE) contains the C-RNTI for the direct path allocated by the direct path serving gNB-DU1 32, and the C-RNTI for the indirect path allocated by the indirect path serving gNB-DU2 34.
  • the Remote UE 10 may configure and store the two C-RNTIs for direct path and indirect path respectively.
  • the Remote UE 10 will now have the right C-RNTI (i.e. , C-RNTI1) for checking and decoding the PDCCH/DCI scheduling information transmitted by the direct path serving gNB-DU1 32.
  • the gNB/gNB-CU 30 may configure the serving cell information (such as physical cell ID, carrier information etc.) of either the direct path, indirect path or both in the new SL-MultiPathConfig IE (or similar IE) via the RRCReconfiguration message.
  • the Remote UE 10 may configure and store the configured serving cell information for direct path, indirect path, or both in a local storage.
  • the gNB/gNB-CU 30 may only assign one C-RNTI value to the Remote UE 10 by using either the di- rectPathC-RNTI field or the indirectPathC-RNTI field in the new SL-MultiPathConfig IE (or similar IE) and skipping the other field.
  • the gNB/gNB-CU 30 may only assign one C-RNTI value to the Remote UE 10 with only the indirectPathC-RNTI field configured in the new SL-MultiPathConfig IE (or similar IE).
  • the Remote UE 10 may keep the currently configured di rectPath C-RNTI value for the direct path, and update only the C-RNTI value for the indirect path.
  • the gNB/gNB-CU 30 may only assign the C-RNTI allocated by the direct path serving gNB-DU (i.e. , gNB-DU1 32) to the multipath L2 U2N Remote UE 10 because only the direct path C-RNTI is useful for the multi-path Remote UE operation to receive scheduling information from the gNB (i.e., gNB-CU 30) and/or direct path serving gNB-DU (i.e., gNB-DU1 32).
  • the SL-Multi PathConfig IE (or similar IE) may only contain the directPathC- RNTI field as defined below.
  • the gNB/gNB-CU 30 may not assign any new C-RNTI to the Remote UE 10 at all, in a procedure of adding an indirect path on top of the direct path or changing from one indirect path to the other indirect path on top of the direct path, so that the Remote UE 10 may continue to use the current C-RNTI (i.e., C-RNTI1 ) on the direct path.
  • the SL- Multi Path Config IE (or similar IE) may be defined as above to have the C-RNTI related fields as optional, so that the SL-Multi PathConfig IE (or similar IE) configured on the Remote UE 10 may not contain the C-RNTI related field.
  • the gNB/gNB-CU 30 may not assign any new C-RNTI to the Remote UE 10 at all, in a procedure of adding an indirect path on top of the direct path or changing from one indirect path to the other indirect path on top of the direct path, so that the Remote UE 10 may continue to use the current C-RNTI (i.e., C.RNTI1 ) on the direct path.
  • the SL- Multi Path Config IE (or similar IE) may not contain any C-RNTI related field as illustrated below.
  • the gNB/gNB-CU 30 may configure the direct path of a multi-path Remote UE as the primary path in the multi-path configuration, and in the procedure of adding an indirect path on top of the direct path or changing from one indirect path to the other indirect path on top of direct path, the Remote UE may ignore any assigned new C-RNTI value to it and may continue to use the current C-RNTI on the direct path.
  • the Remote UE 10 may ignore any assigned new C-RNTI value to it and may continue to use the current C-RNTI on the direct path for the communications on the direct path.
  • the Remote UE 10 will receive the C-RNTI allocated for the indirect path by the gNB-DU (i.e. , gNB-DU2 34) serving the indirect path and store it in addition to the C-RNTI previously allocated for the direct path by the gNB-DU (i.e., gNB-DU1 32) serving the direct path, at least during the time the multi-path session is active, or until it has received an instruction (e.g., RRC (Re-)configuration message) with a parameter indicating that the C-RNTI for the direct path has been updated by the gNB-DU serving the direct path (i.e., gNB-DU1 32) to be the same as the C-RNTI allocated for the indirect path, or a parameter indicating that the C-RNTI previously allocated will not be used anymore for the direct path, or a parameter indicating a new C-RNTI value that overrides the C-RNTI allocated for the direct path and/or the indirect path (whereby the direct
  • the Remote UE 10 can then use the right C-RNTI for the decoding of the PDCCH/DCI or try another stored C- RNTI for decoding of the PDCCH/DCI if decoding fails. Additionally or alternatively, the Remote UE 10 may receive an instruction (e.g. RRC (Re-)configuration message) with a parameter indicating a time (e.g. start time or offset or time interval) to use or to switch between a first and second C-RNTI (e.g. the C-RNTI received/as- signed for direct path and the C-RNTI received/assigned for the indirect path)).
  • an instruction e.g. RRC (Re-)configuration message
  • a parameter indicating a time e.g. start time or offset or time interval
  • the gNB-CU 30 or gNB-DU may include in a message to the Remote UE 10 (e.g.
  • RRC (Re-)configuration message) a parameter indicating that the C-RNTI for the direct path has been updated by the gNB-DU serving the direct path to be the same as the C-RNTI allocated for the indirect path, or a parameter indicating that the C-RNTI previously allocated will not be used anymore for the direct path, or a parameter indicating a new C-RNTI value that overrides the C-RNTI allocated for the direct path and/or the indirect path (and that may be currently stored in the Remote LIE 10), whereby the direct path/indirect path may be indicated with a flag or with a different name of the parameter (e.g. different name for the different paths), or a parameter indicating a time (e.g.
  • first and second C-RNTI e.g. the C-RNTI re- ceived/assigned for direct path and the C-RNTI received/assigned for the indirect path
  • the SL- MultiPathConfig IE (or similar IE) may be defined as below in the ASN.1 format including a field of Boolean flag IsDirectPath indicating whether the included C-RNTI is for direct path or indirect path or both.
  • the C- RNTI value when the flag isDirectPath is set to value “true”, the C- RNTI value may be configured for the direct path. In a second case, when the flag isDirectPath is set to value “false”, the C-RNTI value may be configured for the indirect path. In a third case, when the flag isDirectPath is absent from the SL-MultiPath- Config IE (or similar IE), the C-RNTI value may be configured for both direct path and indirect path.
  • the SL- PathSwitchConfig-r17 IE may be expanded to include the configuration parameters defined in the SL-MultiPathConfig IE (or similar IE), then SL-PathSwitchConfig-r18 IE may have the same parameters as SL-MultiPathConfig IE (or similar IE).
  • the configuration parameters defined in SL-MultiPathConfig IE may be included in RRCReconfiguration message directly and/or in ReconfigurationWithSync IE, then SL-MultiPathConfig IE (or similar IE) may not need to include in RRCRecon- figuration message with ReconfigurationWithSync for multi-path relaying function configuration on Remote UE and/or Relay UE.
  • the multi-path L2 LI2N Remote UE 10 may establish the indirect path first via the L2 U2N Relay UE 12 to the indirect path serving gNB-DU2 34, where a C-RNTI (i.e. C- RNTI2) allocated by the gNB-DU2 34 will be assigned to the Remote UE 10 by the gNB-CU 30 via the legacy R17 sidelink relay procedure.
  • C-RNTI i.e. C- RNTI2
  • the direct path serving gNB-DU1 32 may allocate a new C-RNTI (i.e., C-RNTI1 ) for the Remote UE 10 on the direct path.
  • C-RNTI1 C-RNTI1
  • the same SL-MultiPathConfig IE (or similar IE) defined above in the ReconfigurationWithSync IE which is further contained in the RRCReconfiguration message can be used to assign the two allocated C-RNTIs for indirect path and direct path by the indirect path serving gNB-DU2 34 and the direct path serving gNB-DU1 32 respectively.
  • the Remote UE 10 may configure and store the two C-RNTIs for direct path and indirect path respectively. In the following communication on the direct path, the Remote UE 10 will have the right C-RNTI for checking and decoding the PDCCH/DCI scheduling information transmitted by the direct path serving gNB-DU1 32.
  • the multi-path Remote UE 10 may be assigned/configured a new C-RNTI for the direct path only.
  • the Remote UE 10 may configure and store the C-RNTI, and override the C-RNTI value configured on the indirect path previously.
  • the Remote UE 10 will have the right C-RNTI for checking and decoding the PDCCH/DCI scheduling information transmitted by the direct path serving gNB/gNB- DU.
  • a method for operating a UE said UE operating in multi-path communication with a direct path and an indirect path in a communication network, the method comprising receiving, by the UE, from a base station an RRC message for configuring a new C-RNTI value, overriding, by the UE, a C-RNTI value configured on the indirect path, using, by the UE, the new C-RNTI value for decoding Control Information such as scheduling information transmitted on the direct path by a serving base station.
  • the new C-RNTI value may be configured for the direct path communication.
  • the multi-path L2 U2N Remote UE 10 may establish the direct path first to the serving gNB-DU/gNB-CU. Then, the gNB-CU 30 decides to add an indirect path on top of the direct path, or change to a new indirect path from an old indirect path on top of the direct path.
  • the indirect path is connected to the same gNB-DU via the L2 U2N Relay UE 12.
  • the same C-RNTI may be used or a new C-RNTI may be generated by gNB-DU.
  • the gNB-CU 30 may use either the legacy R17 sidelink relay procedure, or the new SL-MultiPathConfig IE (or similar IE) defined above to configure the old C-RNTI or the new C-RNTI to the Remote UE 10.
  • the SL-MultiPathConfig IE or similar IE
  • directPathC-RNTI and indirectPathC-RNTI fields will have the same C-RNTI value.
  • the Remote UE 10 may configure and store the two C-RNTIs for direct path and indirect path respectively, or just configure and store one C-RNTI for the Remote UE 10 because they are the same. In the following communication on the direct path, the Remote UE 10 will have the right C-RNTI for checking and decoding the PDCCH/DCI scheduling information transmitted by the gNB-DU.
  • the multi-path Remote UE 10 may be assigned/configured a new C-RNTI for the direct path only.
  • the Remote UE 10 may configure and store the C-RNTI, and override the C-RNTI value configured on the indirect path previously.
  • the Remote UE 10 will have the right C-RNTI for checking and decoding the PDCCH/DCI scheduling information transmitted on the direct path by the serving gNB/gNB-DU.
  • the multi-path L2 U2N Remote UE 10 may establish the indirect path first via the L2 U2N Relay UE 12 to the serving gNB-DU/gNB-CU. Then, the gNB-CU 30 decides to add a direct path on top of the indirect path, or change to a new direct path from an old direct path on top of the indirect path.
  • the direct path is connected to the same gNB-DU over the Uu interface directly.
  • the same C-RNTI may be used or a new C- RNTI may be generated by the gNB-DU.
  • the gNB-CU 30 may use either the legacy R17 sidelink relay procedure, or the new SL-MultiPathConfig IE (or similar IE) defined above to configure the old C-RNTI or the new C-RNTI to the Remote UE 10.
  • the SL-MultiPathConfig IE or similar IE
  • indirectPathC-RNTI and directPathC- RNTI fields will have the same C-RNTI value.
  • the Remote UE 10 may configure and store the two C-RNTIs for indirect path and direct path respectively, or just configure and store one C-RNTI for the Remote UE 10 because they are the same. In the following communication on the direct path, the Remote UE 10 will have the right C- RNTI for checking and decoding the PDCCH/DCI scheduling information transmitted by the gNB/gNB-DU.
  • the L2 U2N Remote UE 10 operating in multipath mode may measure the receiving signal quality on the serving cell of the direct path and may detect the receiving signal quality to be below a pre- configured/common/dedicated threshold, or a Radio Link Failure (RLF) may be detected on the direct path. Then, it may trigger a direct path release procedure by the gNB. If there are two C-RNTIs stored in the L2 U2N Remote UE 10, the L2 U2N Remote UE may discard the C-RNTI configured on the direct path and may only keep the C-RNTI configured on the indirect path.
  • RLF Radio Link Failure
  • the gNB/gNB-DU may send a RRCReconfiguration message to the Remote UE 10 via the indirect path to configure a new C-RNTI specially for the Remote UE 10 on the indirect path, so that the Remote UE 10 may have a valid C- RNTI for the legacy R17 L2 U2N relay operation.
  • the indirect path serving gNB- DU may allocate a new C-RNTI for the L2 U2N Remote UE 10.
  • the gNB/gNB-CU may configure the newly allocated indirect path C-RNTI on the Remote UE 10.
  • the Remote UE 10 may configure and store the new C-RNTI for the indirect path, so that the Remote UE 10 may have a valid C-RNTI for the legacy R17 L2 U2N relay operation.
  • the L2 U2N Remote UE 10 operating in multi-path mode may measure the receiving signal quality on the PC5 link with the Relay UE 12, and/or the Relay UE 12 may measure the receiving signal quality on the Uu link on the serving cell of the indirect path and may detect the receiving signal quality either on PC5 link or Uu link to be below a pre-configured/com- mon/dedicated threshold, or a Radio Link Failure (RLF) may be detected on either the PC5 or Uu link of the Relay UE 12, then it may trigger the indirect path release procedure by the gNB.
  • RLF Radio Link Failure
  • the Remote UE 10 may discard the C-RNTI configured on the indirect path and may only keep the C-RNTI configured on the direct path for the Uu communications on the direct path. If there is one valid C-RNTI stored in the Remote UE 10, the Remote UE 10 and the gNB/gNB-DU may continue to use the current C-RNTI on the direct path for the communications on the direct path as a legacy UE.
  • the direct path serving gNB- DU may allocate a new C-RNTI for the L2 U2N Remote UE 10.
  • the gNB/gNB-CU may configure the newly allocated direct path C-RNTI on the Remote UE 10.
  • the Remote UE 10 may configure and store the new C-RNTI for the direct path, so that the Remote UE 10 may have a valid C-RNTI for the legacy UE operation on the direct path.
  • the base station may send an RRCReconfiguration message to Remote UE operating in multi-path with direct path and indirect path working concurrently to release the direct path.
  • the RRCReconfiguration message may contain an explicit or implicit network indication to indicate to the Remote UE to maintain the PC5 unicast link (e.g.
  • RRCReconfiguration message may not contain any target serving cell information within spCellConfigCommon of reconfigurationWithSync or RRCReconfiguration message may not contain reconfigurationWithSync IE at all, in which case the Remote UE shall interpret this message by releasing the direct path in addition to maintaining the PC5 unicast link of the existing indirect path.
  • the base station may send a RRCReconfiguration message to Remote UE operating in multipath with direct path and indirect path working concurrently to release both the direct path and indirect path.
  • the RRCReconfiguration message may contain an explicit or implicit network indication to indicate to the Remote UE to release the PC5 unicast link (e g. retainRelayPath is set to false), and the RRCReconfiguration message may not contain any target serving cell information within spCellConfigCommon of reconfigurationWithSync or RRCReconfiguration message may not contain reconfigurationWithSync IE at all, in which case the Remote UE shall interpret this message by releasing the direct path in addition to releasing the PC5 unicast link of the existing indirect path and releasing the indirect path thereof.
  • this embodiment proposes a method for operating a UE, said UE operating in multi-path communication with a direct path and an indirect path in a communication network, the method comprising receiving from a base station a first RRC message for maintaining the indirect path, maintaining the indirect path and releasing the direct path upon determination of the absence of a target service in the message.
  • a method for operating a UE said UE operating in multi-path communication with a direct path and an indirect path in a communication network, the method comprising receiving from a base station a first RRC message for releasing the indirect path, releasing the indirect path and releasing the direct path upon determination of the absence of a target service in the message.
  • a method for operating a UE said UE operating in multi-path communication with a direct path and an indirect path in a communication network, the method comprising receiving from a base station a first RRC message for releasing the direct path, maintaining the indirect path upon determination of the absence of target service in the message.
  • a method for operating a UE said UE operating in multi-path communication with a direct path and an indirect path in a communication network, the method comprising receiving from a base station a first RRC message for releasing the direct path, releasing the indirect path upon determination of the absence of target service in the message.
  • the Conditional Presence FirstRRCReconfig is redefined as “This field is mandatory present in the first RRCReconfiguration for L2 U2N Remote UE when PCell is on indirect path, i.e. MP configuration is not present. Otherwise, the field is absent” from what is defined in TS 38.331 , V17.7.0, “This field is mandatory present in the first RRCReconfiguration. Otherwise the field is absent.”.
  • the main reason to have this change in Rel-18 is to make sure that in indirect path addition on top of direct path (i.e. MP configuration is present), the sl- UEIdentityRemote-r17 field in SL-L2RemoteUE-Config-r17 becomes absent, so that there will be no new C-RNTI configured for the L2 U2N Remote UE on the indirect path, and the C-RNTI on the direct path will not be overridden.
  • agreed at RAN2 #125 meeting may imply the RRCReconfiguration message configured on a Remote UE operating in multi-path to release the direct path may not include sl-UEIdentityRemote-r17 in SL-L2RemoteUE-Config-r17 to configure the Remote UE at all according to the Conditional Presence FirstRRCReconfig for sl- UEIdentityRemote-r17 in SL-L2RemoteUE-Config-r17 “This field is mandatory present in the first RRCReconfiguration for L2 U2N Remote UE when PCell is on indirect path, i.e.
  • MP configuration is not present. Otherwise the field is absent.”, because direct path is not released yet when RRCReconfiguration message is configured on the Remote UE, and PCell is still on direct path. As a result, the L2 U2N Remote UE may not have any valid C-RNTI configured on the indirect path commonly agreed between the Remote UE and the network after direct path is released and the L2 U2N Remote UE operates in the Rel-17 L2 U2N Remote UE case.
  • An object of the following embodiment is to resolve the issue of configuring a C-RNTI for an L2 U2N Remote UE on the indirect path after direct path is released and the L2 U2N Remote UE operates in Rel-17 L2 U2N Remote UE case.
  • the RRCReconfiguration message may include a new sl-UEIdentityRemote-r18 field to configure Remote UE’s C-RNTI on the indirect path when or once the direct path is released and Remote UE operates in Rel-17 L2 U2N Remote UE case. This means that the Remote UE may only apply said C-RNTI after direct path release.
  • Conditional Presence FirstRRCReconfig for sl-UEIdentityRemote-r17 in SL-L2RemoteUE-Config-r17 may be rephrased to be mandatory present for the case of direct path release for Multi-path (MP) Remote UE when PCell is on direct path and to be mandatory present for the first RRCReconfiguration for L2 U2N Remote UE when PCell is on indirect path, i.e. MP configuration is not present.
  • MP Multi-path
  • the network may send another RRCReconfiguration message to L2 U2N Remote UE after direct path is released, and the RRCReconfiguration message includes sl-UEIdentityRemote-r17 in SL-L2Re- moteUE-Config-r17 to configure C-RNTI for L2 U2N Remote UE on the indirect path.
  • the L2 U2N Remote UE includes a policy to apply a given C-RNTI when the direct path is released, e.g., it may apply the existing C-RNTI in the indirect path, or it may apply another previously received C- RNTI when the direct path is released.
  • the multi-path L2 U2N Remote UE 10 may connect to the gNB over more than one L2 U2N Relay UE 12 which may be served by different gNB-DUs.
  • L2 U2N Remote UE 10 may connect to the gNB over more than one L2 U2N Relay UE 12 which may be served by different gNB-DUs.
  • the SL-Multi PathConfig IE (or similar IE) may then be defined as below:
  • Fig. 5 shows a diagram according to an embodiment that may be combined with any of the other embodiments or may be used independently.
  • the diagram shows a proposed signalling and processing procedure of the inter-DU indirect path addition on top of direct path for the multi-path L2 U2N Remote UE 10, which involves the gNB-CU 30 and the gNB-DUs 32, 34 to synchronize the allocated C- RNTI values in NG-RAN nodes.
  • the initial steps S501 to S527 are similar to the above steps S301 to
  • the gNB-CU 30 receives in step S528 the allocated C-RNTI (i.e. , C-RNTI2) from the gNB-DU2 34 serving the indirect path
  • the gNB-CU 30 knows that the Remote UE 10 is a multi-path capable UE from radio capability indication in the initial access/attach (e.g. using a field remoteUE-MultiPathOperation-L2 contained e.g.
  • the gNB-CU 30 may use the legacy R17 sidelink relay procedure to send in step S530 an RRCReconfigura- tion message including C-RNTI1 to configure C-RNTI (i.e., C-RNTI1 ) on the indirect path.
  • the Remote UE 10 may thus only configure and store one C- RNTI, because the C-RNTI value (i.e., C-RNTI1 ) has already been synchronized between the direct path serving gNB-DU1 32 and the indirect path serving gNB-DU2 34, the Remote UE 10 may still have the right C-RNTI to check and decode PDCCH/DCI scheduling information transmitted by the direct path serving gNB-DU1 32. By using this procedure, the same C-RNTI value may be used (i.e., shared) for both the direct path and indirect path. The benefit is that the Remote UE 10 may only need to store and use a single C-RNTI, and that it does not impact the legacy R17 sidelink procedure.
  • the C-RNTI value i.e., C-RNTI1
  • the gNB-DU1 32 and the gNB-DU2 34 in Fig. 5 may agree on the C-RNTI to be used for the communication with the Remote UE 10 over the direct and indirect paths.
  • This agreement may be done directly or indirectly, this agreement may be coordinated by the gNB-CU 30 or done in a distributed manner by both gNB-DUs 32, 34.
  • the gNBs may also inform the Remote UE 10 about the fact that the C-RNTI is used for communication over both the direct and indirect paths and the Remote UE 10 may store said configuration.
  • the gNB-DU2 34 may allocate a new C-RNTI to the Remote UE 10 for the indirect path
  • the gNB-DU2 34 may indicate the allocated C-RNTI to the gNB-DU1 32.
  • This indication may be done through the gNB-CU 30, e.g., through the F1 interface which is a point-to-point interface between endpoints (which means a point-to-point logical interface) and which supports Control Plane (CP) and User Plane (UP separation between the radio network layer and the transport network layer to enable exchange of UE-associated information and non-U E-associated information.
  • CP Control Plane
  • UP User Plane
  • the gNB-DU2 34 may provide the indication of the determined C-RNTI, update the gNB-CU 30, and the gNB-CU 30 may inform the gNB-DU1 32.
  • the gNB-CU 30 may then request the Remote UE 10 to start using the new C-RNTI or may start using said C-RNTI for the Remote UE 10 directly if the gNB-DU2 34 is the one assigning said C-RNTI to the Remote UE 10.
  • gNB-DU1 32 may use the assigned C-RNTI for subsequent procedures with the Remote UE.
  • a direct interface between the gNB-DU1 32 and the gNB-DU2 34 may be defined and used, instead of communicating via the gNB-CU 30. In this case, this interface may then be used to directly exchange said information between both gNB-DUs 32, 34.
  • the gNB-DU1 32 may inform the gNB-DU2 34 about the C-RNTI in use by the Remote UE 10. The gNB-DU2 34 may then allocate said C-RNTI to the Remote UE 10. If said C-RNTI was used by the gNB-DU2 34 for addressing any other UE, the gNB-DU2 34 may reallocate a new C-RNTI' to the other UE.
  • the gNB-DU1 32 or the gNB-DU2 34 may also include an implicit or explicit time or context that determines when to start using the allocated or used or determined C-RNTI. This has the benefit of synchronizing the change/switch of C-RNTIs.
  • the gNB-DU1 32 and the gNB-DU2 34 may have a fixed allocated range of C-RNTIs for multi-path communication over a direct and indirect path.
  • the multi-path L2 U2N Remote UE 10 may connect to the gNB1 on the direct path and may connect to the gNB2 on the indirect path.
  • gNB1 and gNB2 may be two different base stations 20.
  • gNB1 may configure a C-RNTI (i.e. , C-RNTI1 ) on the direct path
  • gNB2 may configure a C-RNTI (i.e. , C-RNTI2) on the indirect path using legacy procedure.
  • gNB1 and gNB2 may be interconnected to exchange messages in the two directions, e.g., using the XnAP protocol.
  • a C-RNTI is selected/allocated/proposed to be used by a gNB-DU
  • the gNB-CU or another gNB-DU that may receive the C-RNTI may detect that the C-RNTI is already in use. If it determines that the C-RNTI is not used or not to be used for multi-path relay communication, then it may send a message to the gNB-CU/gNB-DU that selected/allocated/proposed the C-RNTI to reject the C-RNTI and/or ask for a different C-RNTI. Additionally or alternatively, the gNB- CU or gNB-DU that receives the C-RNTI (i.e. , C-RNTI1 ) and detects that C-RNTI1 is already in use for a UE may resolve the conflict by allocating a different C-RNTI2 to the UE that is currently served by the respective C-RNTI.
  • a radio network identifier may be selected - e.g.,by a second access device -- for communication with a UE over a direct path managed by a first access device and an indirect path managed by a second access device wherein: the second access device determines a radio network identifier for communication with the UE, the second access device informs the first access device about the radio network identifier, the second access device starts using the radio network identifier for the communication with the UE over the indirect path.
  • a radio network identifier may be communicated - e.g., by a first access device - for communication with a UE over a direct path managed by the first access device and an indirect path managed by a second access device wherein: the first access device determines a radio network identifier to be used for communication with the UE, the first access device informs the second access device about the radio network identifier.
  • the multi-path L2 U2N Remote UE 10 may have one (primary) serving cell in the direct path under the gNB-DU1 32 and may have another (primary or secondary) serving cell in the indirect path through the L2 U2N Relay UE 12 under the gNB-DU2 34.
  • Each serving cell may have a different cell ID. This may lead to a problem during a network registration procedure, or network service access procedure, or localization-based procedure where the procedure is based on the cell ID used to serve the UE (e.g., during the UE location reporting procedure as specified in clause 4.10 of 3GPP TS 23.502).
  • a network base station e.g., the gNB-CU 30 or other access device may be configured (e.g., by means of a policy) or requested (e.g., using a Location Reporting Control message from an LMF or from the AMF) to report (e.g.
  • the gNB- CU 30 may report the serving cell ID and/or the one or more cell IDs of one or more network base stations (e.g., gNB-DUs 32, 34) involved in multi-path communication for a particular UE to the core network, e.g., to an AMF, GLMC, LMF. This allows the core network to, e.g., determine the location of the UE.
  • network base stations e.g., gNB-DUs 32, 34
  • the policy or request configured or transmitted to the network base station may also include a request/instruc- tion/condition on whether to include information about whether the reported cell ID corresponds to one of the direct or indirect paths, and/or whether to include all cel I- IDs for all network base stations in the report or only a subset thereof. Based on the policy or request, the network base station may include the requested information in its report to the core network.
  • a network base station may be configured or requested to report the primary cell’s cell ID to the core network.
  • serving cell may be configured as the primary cell and/or which serving cell needs to be reported, it may be decided by the 3GPP specification, such as the specification may specify to use the direct path’s primary serving cell as the primary cell of the multi-path L2 U2N Remote UE 10; it can also be decided by a configuration or request received from the 0AM and/or AMF.
  • a network base station may be configured or requested to report the cell ID of the cell that has the smallest coverage area from amongst the cell IDs of the multiple paths in multi-path communication (e.g., if one of the cells is from a network base station in a non-terrestrial network with a large coverage area, whereas another cell may be from a terrestrial network with a smaller coverage area).
  • a network base station may be configured or requested to report the cell ID of the cell that serves a Relay UE to which the Remote UE is connected via multi-path communication and that has the best signal to the Remote UE (e.g., for which the measurement reports received from the relay UE or remote UE have the highest SL-RSRP or SD-RSRP for the PC5 communication) and/or that has the smallest distance to the Remote UE (e.g. based on transmit power information or SL-RSRP or SD-RSRP or timing/timing advance reports (e.g., UE RX-TX), distance measurements from/between the Remote UE or Relay UE).
  • the measurements or summary or report thereof may be reported by the network base station (e.g., as metadata) in addition to the reported cell ID(s).
  • the network base station may be configured or requested to report the cell ID of the cell that serves a Relay UE to which the Remote UE is connected via multi-path communication that has the least amount of hops between the Remote UE and the base station.
  • the Relay UEs or Remote UEs may need to report the number of hops between themselves and the network, and/or the number of hops is determined by adding an attribute (e.g. hop counter) to one or more messages exchanged between the respective UE and the network whereby that attribute may be increased in value every time the message is forwarded.
  • the number of hops between itself and the Remote UE may be reported by the network base station (e.g., as metadata) in addition to the reported cell ID(s).
  • a network base station may report both cell IDs of the direct path and indirect path or of two indirect paths to the core network. Furthermore, the network base station may also include additional information (metadata) related to the cell(s), such as one or more of cell size, coverage area, transmission power of transmission reception point (TRP), whether it is the cell for a direct or indirect path, the location and/or transmission power and/or coverage area of relay UEs in an indirect path, reference signal received power/strength of Uu interface of multi-path L2 U2N Remote UE 10 on the direct path, reference signal received power/strength of sidelink reference signal (SL-RSRP) and/or sidelink discovery reference signal (SD-RSRP) of the PC5 unicast link between the Remote UE 10 and the Relay UE 12, reference signal received power/strength of Uu interface of the L2 U2N Relay UE 12 with its connected serving cell, etc. in the report to the core network. Which information to include may be based on information in the policy or
  • the additional information may also include relay UE identification information, e.g., an identifier provided or maintained by the relay UE or an identifier of the relay UE stored in the radio access network (e.g. in a network base station).
  • relay UE identification information e.g., an identifier provided or maintained by the relay UE or an identifier of the relay UE stored in the radio access network (e.g. in a network base station).
  • identifiers include e.g., the NG-5G-S-TMSI (Temporary Mobile Subscriber Identity), 5G-GUTI (Globally Unique Temporary UE Identity) or 5G-SUCI (Subscription Concealed Identifier) or User Info/User Info ID.
  • the core network may use the additional information received from the network base station to determine the use of the reported cell ID(s).
  • This has the advantage of improving the localization accuracy of a cellbased positioning procedure, e.g., it can be used to determine that the UE is located in, e.g., the intersection of the coverage area and/or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of both cells; or the intersection of the coverage area and/or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of the direct-path cell and the coverage area and/or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of the relay connected to the indirect- path cell.
  • the intersection of the coverage area and/or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of a first indirect-path cell and the coverage area and/or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of the relay connected to a second indirect-path cell is possible.
  • the network base station may determine which cel l-ID(s) to include in the report based on one or more of the above mentioned additional information and/or based on criteria defined in the policy or request.
  • the reported cell ID(s) may be used (e.g., by a core network function such as AMF, LMF, GMLC) as an indication of UE/user’s location information, which may be further used for positioning of UE/user.
  • the UE may request and be requested, e.g., by a network function in the core network, to perform a localization procedure based on its multi-path communication whereby the user equipment may be requested to transmit a measurement report related to the multi-path connection whereby the report may include the connection information including one or more of cell-ID of the access device (e g. network base station), access device coverage, reception power of the access devices, whether it is the access device for a direct or indirect path, the location and/or transmission power and/or coverage area of relay UEs in an indirect path, etc. related to the direct and indirect paths.
  • the access device e g. network base station
  • the reported cell ID(s) may be used by a core network function such as AMF to determine that one or more of the reported cell ID(s) (e.g., for the indirect paths) are located in another country or are located in an area with communication restrictions or are too far apart from other reported cell ID(s) (e.g., the cell ID reported for the direct path).
  • a core network function such as AMF
  • the core network function may instruct (e.g., by providing a message via Next Generation Application Protocol (NG-AP) interface that provides a UE and an AMF via NAS signaling transport) the radio access network (e.g., one or more network base stations) to disconnect the UE from the one or more reported cell ID(s), e.g., that are located in another country or are located in an area with communication restrictions or are too far apart from other reported cell I D(s), etc.
  • NG-AP Next Generation Application Protocol
  • the core network function may instruct (e.g., by providing a message via NG-AP interface) the radio access network (e.g., one or more network base stations) to disable or not use multi-path communication for the respective UE, and may also include a condition (e.g., which cells should not be used for indirect path of a multi-path communication, or which area multi-path communication should be disabled or maximum distance between cells used for multi-path communication).
  • the radio access network e.g., one or more network base stations
  • the core network function e.g., AMF
  • radio access network e.g., one of the network base stations
  • may request the UE to disconnect one or more of the paths used for its multi-path communication e.g., by transmitting a NAS message to the UE that includes one or more cell-IDs, relay UE IDs, path IDs to disconnect from
  • the core network function e.g., AMF
  • radio access network e.g., one of the network base stations
  • a NAS message by transmitting a NAS message to the UE that includes one or more cell-IDs, relay UE IDs, path IDs to disconnect from) and/or may request the UE to disconnect completely and register again to the network, if the number of hops between that UE and the radio access network exceeds a pre-configured number of hops.
  • a network access device e.g., the gNB-CU 30
  • a network access device e.g., the gNB-CU 30
  • This configuration or policy may be deployed by the 0AM or the AMF, e.g., the AMF may retrieve the location of a first access device and inform the first access device of the identity of a second access device with which it is allowed or disallowed to interact for a given communication service, e.g., enable a multi-path communication.
  • NG-RAN may report either the cell information of direct path, or indirect path or both together with metadata information of the related cell information to the AMF/CN in the Location Report / UserLocationlnformation message of the NGAP protocol, and the UserLocationlnformationNR may be expanded to include the above information as below.
  • UserLocationlnformationNR SEQUENCE ⁇ nR-CGI NR-CGI, tAI TAI, timestamp TimeStamp OPTIONAL, iE-Extensions ProtocolExtensionContainer ⁇ ⁇ UserLocationlnformationNR-ExtlEs ⁇ ⁇ OPTIONAL,
  • a network base station may be configured or requested to report (e.g., in a Location Report such as UserLocationlnformationNR as described above, extended for this purpose) a (rough) location of a UE that is connected using multi-path communication via two or more direct and/or indirect paths, whereby the network base station possibly in cooperation with other network base stations may use the information of the one or more cell-IDs of the network base stations involved in the multi-path communication of the UE together with measurement reports related to the UE (e.g., received from the UE itself, from one or more relay UEs, or from one or more network base stations).
  • a Location Report such as UserLocationlnformationNR as described above, extended for this purpose
  • the network base station possibly in cooperation with other network base stations may use the information of the one or more cell-IDs of the network base stations involved in the multi-path communication of the UE together with measurement reports related to the UE (e.g., received from the UE itself, from one or more relay UEs
  • the network base station may receive measurement information from a Remote UE and/or Relay UE used for one of the indirect paths to determine (rough) distance between the Relay UE and the Remote UE (e.g., based on transmit power information or SL-RSRP or SD-RSRP or timing/timing advance reports (e.g. UE RX-TX), distance measurements from/between the Remote UE or Relay UE).
  • a Remote UE and/or Relay UE used for one of the indirect paths to determine (rough) distance between the Relay UE and the Remote UE (e.g., based on transmit power information or SL-RSRP or SD-RSRP or timing/timing advance reports (e.g. UE RX-TX), distance measurements from/between the Remote UE or Relay UE).
  • the network base station may obtain measurement information (e.g., from the Remote UE or one or more of the network base stations involved in the multi-path communication) related to the Remote UE’s or Relay UE’s direct communication path to one or more of the network base station involved in the multi-path communication, and may use this together with e.g.
  • the intersection of the coverage area and/or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of a first indirect-path cell and the coverage area and/or a derived radius distance from the center of the cell (or other reference point) by the coverage area and received signal strength of the relay connected to a second indirect-path cell is possible.
  • the network base station may report the acquired information about the (rough) distance between the Remote LIE and one or more Relay UEs or network base stations and/or whether the Remote UE is located in an intersection or certain radius from the center of the cell or other reference point to the core network (e.g., in a location report), and/or may determine a (rough) location of the Remote UE based on the acquired information (e.g., using trilateration or triangulation based on e.g. the (rough) distances or radiuses) and report the (rough) location of the Remote UE to the core network (e.g. in a location report)
  • the acquired information e.g., using trilateration or triangulation based on e.g. the (rough) distances or radiuses
  • determination of the location of a user equipment connected over one or more direct paths managed by one or more first access devices and one or more indirect paths managed by one or more second access device, or two or more direct paths managed by two or more first access devices, or two or more indirect paths managed by two or more second access devices may be achieved by:
  • connection information may include one or more of cell-ID of the access device, access device coverage, transmission power of the access device, (rough) location of the user equipment or (rough) dis- tance/angle to one or more access devices, whether the reported cell- ID is from the access device for the direct or an indirect path, the location and/or transmission power and/or coverage area of relay devices in the indirect path, or related measurement information (e.g., RSRP, timing/timing advance information) or (rough) distance/angle to one or more relay devices, etc. related to the direct and indirect paths,
  • measurement information e.g., RSRP, timing/timing advance information
  • this may be implemented in a user equipment for determining the location of the user equipment connected over a direct path or indirect path to a first access device and over an indirect path to a second access device , by configuring the user equipment to:
  • connection information report to the core network including one or more of cell-ID of the access device, access device coverage, reception power of the access devices, whether it is the access device for a direct or indirect path, the location and/or transmission power and/or coverage area of relay devices in an indirect path, etc. related to the direct and indirect paths.
  • the network base station may be configured or requested to report (e.g., in a Location Report such as UserLocationln- formationNR as described above, extended for this purpose) the cell ID of the cell that serves a Relay UE to which the Remote UE is connected via an indirect communication via one or more hops, whereby the number of hops between itself and the Remote UE may be reported by the network base station (e.g., as metadata) in addition to the reported cell ID(s). Additionally or alternatively, the network base station may be configured or requested to report an identifier of one or more of the Relay UEs involved in the indirect connection between the Remote UE and the respective base station.
  • a Location Report such as UserLocationln- formationNR as described above, extended for this purpose
  • the network base station may be configured or requested to report an identifier of one or more of the Relay UEs involved in the indirect connection between the Remote UE and the respective base station.
  • the Relay UEs or Remote UEs may need to report the number of hops between themselves and the network, and/or the number of hops may be determined by adding an attribute (e.g. hop counter) to one or more messages exchanged between the respective UE and the network whereby that attribute may be increased in value every time the message is forwarded.
  • the Relay UEs or Remote UEs may need to report an identifier of the Relay UE to which it is connected in the indirect path, and/or the identifiers for the Relay UEs on the indirect path may be determined by adding an atttribute (e.g. list of Relay UE identifiers) to one or more messages exchanged between the respective UE and the network.
  • an attribute e.g. hop counter
  • Every relay UE that forwards the message may add its own identifier to that attribute.
  • a relay UE identifier could be an identifier provided or maintained by the relay UE or an identifier of the relay UE stored in the radio access network (e.g. in a network base station). Examples of such identifiers include e.g., the NG-5G-S-TMSI (Temporary Mobile Subscriber Identity), 5G-GUTI (Globally Unique Temporary UE Identity) or 5G-SUCI (Subscription Concealed Identifier) or User Info/User Info ID.
  • NG-5G-S-TMSI Temporary Mobile Subscriber Identity
  • 5G-GUTI Globally Unique Temporary UE Identity
  • 5G-SUCI Subscribescription Concealed Identifier
  • the core network function e.g., AMF
  • radio access network e.g., one of the network base stations
  • may request a UE e.g. Remote UE or Relay UE
  • UE e.g. Remote UE or Relay UE
  • the indirect communication path e.g., by transmitting a NAS message to the UE that includes one or more cell-IDs, relay UE IDs, path IDs to disconnect from
  • the UE may request the UE to disconnect completely and register again to the network, if the number of hops between that UE and the radio access network exceeds a pre-configured number of hops.
  • the U2N direct/indirect paths may be added or changed.
  • Fig. 6 schematically shows a signaling and processing diagram for indirect path change under a single procedure, involving a Remote UE (REM-UE), a source Relay UE (S-REL-UE), a target Relay UE (T-REL-UE) and gNB or other network access advice.
  • REM-UE Remote UE
  • S-REL-UE source Relay UE
  • T-REL-UE target Relay UE
  • gNB network access advice
  • 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.
  • UL/DL IDP indirect path
  • UL/DL DP direct path
  • step S601 information (MCR) for measurement, configuration and reporting is exchanged between at least some of the Remote UE, the source Relay UE, the target Relay UE and the gNB.
  • the gNB may decide in step S602 to change the indirect path (DEC CHG IDP), e.g., triggered by non-sufficient transmission quality or the like.
  • the gNB transmits respective RRC reconfiguration messages (RRC RECON) to the source Relay UE and the target Relay UE (that may have selected based on the exchanged information or other available information about potentially available Relay UEs) in steps S603a and S603b.
  • RRC RECON respective RRC reconfiguration messages
  • the gNB transmits an additional RRC reconfiguration message to the Remote UE in step S604.
  • step S605 an RRC connection establishment (PC5-RRC CON EST) is performed between the Remote UE and the target Relay UE via the PC5 interface.
  • respective RRC reconfiguration complete messages (RRC RECON COMPL) are sent in steps S606a and S606b from the Remote UE to the gNB via the direct path and the indirect path (via the target Relay UE) to the gNB.
  • UL/DL data can be exchanged in step S607 between the UE and the gNB using the direct path (UL/DL DP-D) and a new indirect path (UL/DL IDP-D) via the target Relay UE.
  • Fig. 7 schematically shows a still further signaling and processing diagram for direct path change under a single procedure, involving a Remote UE (REM- UE), a Relay UE (REL-UE), and a gNB or other access device that controls a source primary Cell (PCell) (S-PC), the Relay UEs serving cell (REL-UE-SC) UE and a target PCell (T-PC).
  • REM- UE Remote UE
  • REL-UE Relay UE
  • S-PC source primary Cell
  • REL-UE-SC Relay UEs serving cell
  • T-PC target PCell
  • step S700 a direct path (UL/DL DP) between the Remote UE and the source PCell of the gNB is provided.
  • the Relay UE is used to provide an indirect path (UL/DL IDP) for UL/DL data between the Remote UE and the gNB’s serving cell of the Relay UE.
  • step S701 information (MCR) for measurement, configuration and reporting is exchanged between at least some of the Remote UE, the Relay UE, the source PCell and the Relay UE’s serving cell.
  • the gNB may decide in step S702 to change the PCell of the indirect path (DEC CHG PC) from the source PCell to the target PCell, e.g., triggered by non-suf- ficient transmission quality or the like.
  • RRC RECON RRC reconfiguration operation
  • the source PCell of the gNB transmits an RRC reconfiguration messages (RRC RECON MSG) with information about the target PCell to the Remote UE.
  • RRC RECON MSG RRC reconfiguration messages
  • the Remote UE initiates in step S705 a random access operation (RAN ACC TC) towards the target PCell.
  • RAN ACC TC random access operation
  • the Remote UE transmits respective RRC reconfiguration complete messages (RRC RECON COMPL MSG) to the target PCell in step S706a and to the Relay UE’s serving cell in step S706b.
  • UL/DL data can be exchanged in step S707 between the UE and the gNB using the new direct path (UL/DL DP-D) to the target PCell and the indirect path (UL/DL IDP-D) via the Relay UE to the Relay UE’s serving cell.
  • UL/DL DP-D new direct path
  • UL/DL IDP-D indirect path
  • a PCell handover (HO) procedure with RRCReconfiguration- WithSync may be used to camp to the target PCell.
  • RRCReconfiguration With Sync may allow performing masterKey Update so that the L2 U2N Remote UE may be configured to use a new set of cryptographic keys for data/signaling radio bearers (SRBs/DRBs) after PCell HO, i.e., direct path addition/change, and start to transmit data with new keys in the PDCP.
  • SRBs/DRBs data/signaling radio bearers
  • the access device may not be able to security process those packets anymore because it now has the new set of keys.
  • Another particular challenge in the above procedures of Figs. 6 and 7 for path addition and/or change relates to how security keying materials, e.g., AS keys, can be updated and how protected information that may have been already exchanged can be processed.
  • a change of keys may lead to a situation in which one of the end points receives some information that is protected with cryptographic keys that are not valid/available anymore because keys were updated.
  • Fig. 8 schematically shows a signaling and processing diagram for key update.
  • this key update procedure may be related to a dual connectivity procedure as defined e.g. in Clause 6.10 in TS 33.501.
  • the dual connectivity procedure involves security functions for supporting a UE that is simultaneously connected to more than one NG-RAN node (e.g., multi-radio dual connectivity (MR-DC) with 5GC as described in TS 37.340), wherein the UE may be connected to one node (e.g., a ng-eNB) that acts as a master node (MN) and one node (e.g., a gNB) that acts as a secondary node (SN).
  • a ng-eNB e.g., a ng-eNB
  • MN master node
  • SN secondary node
  • the SN may be connected to the 5GC and the MN may be connected to the SN via an Xn interface.
  • the MN When the MN is executing an SN addition procedure (i.e. , initial offload of one or more radio bearers to the SN), or an SN modification procedure (e.g., as in clauses 10.2.2 and 10.3.2 in TS 37.340) which requires an update of a key KSN for the SN, the MN may derive the KSN (e.g., as defined in clause 6.10.3.2). The MN may maintain a SN counter (e.g., as defined in clause 6.10.3.1 ).
  • the MN may, for each new radio bearer, assign a radio bearer identity that has not previously been used since the last KSN change. If the MN cannot allocate an unused radio bearer identity for a new radio bearer in the SN, e.g., due to radio bearer identity space exhaustion, the MN may increment the SN counter and compute a fresh KSN and may then perform a SN modification procedure to update the KSN.
  • step S801 the UE and the MN establish an RRC connection (RRC CON EST). Then, in step S802, the MN sends an SN addition/modification request (SN ADD/MOD REQ) to the SN (e.g., over the Xn-C interface) to negotiate the available resources, configuration and algorithms at the SN. The MN computes and delivers the KSN to the SN if a new key is needed.
  • the UE security capabilities e.g., as in subclause 6.10.4
  • the UP security policy received from the session management function (SMF) may also be sent to the SN.
  • PDU packet data unit
  • UP integrity protection and ciphering activation decision from MN may be also included (e.g., as described in subclause 6.10.4).
  • step S804 the SN sends an SN addition/modification acknowledge (SN SDD/MOD REQ ACK) to the MN indicating availability of requested resources and identifiers for the selected algorithm(s) for the requested data radio bearers (DRBs) and/or signaling radio bearer (SRB) for the UE.
  • SN SDD/MOD REQ ACK SN addition/modification acknowledge
  • DRBs data radio bearers
  • SRB signaling radio bearer
  • the UP integrity protection and encryption indications may be sent to the MN.
  • step S805 the MN sends an RRC connection reconfiguration request (RRC CON RECON) to the UE instructing it to configure the new DRBs and/or SRB for the SN.
  • the MN may include the SN counter parameter to indicate that a new KSN is needed and the UE may compute the KSN for the SN.
  • the MN forwards the UE configuration parameters (which contain the algorithm identifier(s) received from the SN in step S804), and UP integrity protection and encryption indications (received from the SN in step S804) to the UE (cf. subclause 6.10.3.3 for further details).
  • the UE accepts the RRC connection reconfiguration request after validating its integrity.
  • the UE may compute the KSN for the SN if an SN counter parameter was included.
  • the UE may also compute the needed RRC and UP keys and activate the RRC and UP protection as per indications received for the associated SRB and/or DRBs respectively.
  • the UE then sends an RRC reconfiguration complete (RRC CON RECON COMPL) to the MN.
  • the UE may activate the chosen encryption/decryption and integrity protection keys with the SN at this point.
  • step S807 the MN sends an SN reconfiguration complete (SN RECON COMPL) to the SN (e.g., over the Xn-C interface) to inform the SN of the configuration result.
  • the SN may activate the chosen encryption/decryption and integrity protection with UE in steps S806a and S807a (ACT CIPH + IN-PRO). If SN does not activate encryption/decryption and integrity protection with the UE at this stage, the SN may activate encryption/decryption and integrity protection upon receiving a random access request from the UE in step S808 (RAN ACC PROC).
  • the access device e.g., gNB
  • the access device may be configured with a policy determining that UP data that cannot be securely processed is to be discarded, while the end points (Remote UE and/or access device) may send a request triggering the retransmission.
  • the end points may be configured (e.g., by means of a policy) with a small time or counter window that determines the time that needs to pass before discarding old keys and/or enabling new keys. This may allow having two sets of keys active at the same time and may allow processing data that may have been protected with the old keys when the new set of keys is already active.
  • the configuration may also determine which keys should be used first, e.g., the old keys.
  • an old U2N relay e.g., Relay UE
  • Relay UE may be instructed to release the connection (so that all buffered RLC messages are released).
  • the access device e.g., gNB
  • the access device may be required to empty the PDCP buffer and only then indicate to the Remote UE the new path/set of keys.
  • the Remote UE may be configured to send the RRC reconfiguration complete message over the direct path, and not over the indirect path. This has the advantage of making sure that the message is not kept in the buffer of the U2N relay and cannot be processed correctly.
  • the Remote UE may be configured to only send data over the direct path until a timer expires and/or data is received through the indirect path. This has the advantage of making sure that the message is not kept in the buffer of the U2N relay and cannot be processed correctly.
  • V2V vehicle-to-vehicle
  • V2X vehicle-to-eve- rything
  • LoT Internet of Things
  • loT devices including low-power medical sensors for health monitoring, medical (emergency) diagnosis and treatment devices, for hospital use or first-responder use, virtual reality (VR) headsets, etc.
  • the described operations like those indicated in the above embodiments may be implemented as program code means of a computer program and/or as dedicated hardware of the related network device or function, respectively.
  • the computer program may be stored and/or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un dispositif de communication dans un réseau sans fil, le dispositif prenant en charge une communication à trajets multiples, le dispositif de communication étant conçu pour : - se connecter à un premier dispositif d'accès par l'intermédiaire d'un trajet direct si le dispositif de communication est dans la couverture du premier dispositif d'accès; et - se connecter à un second dispositif d'accès par l'intermédiaire d'un trajet indirect via un autre dispositif, en particulier un dispositif de relais; les premières informations de configuration comprenant au moins un paramètre concernant un premier identifiant temporaire de réseau radio, RNTI, attribué au trajet direct destiné à être utilisé par le premier dispositif d'accès pour transmettre des informations de planification au dispositif de communication sur le trajet direct, et les informations de planification pouvant être une liaison descendante, une liaison montante et/ou une liaison latérale; et - recevoir des secondes informations de configuration en provenance du premier ou du second dispositif d'accès par l'intermédiaire du trajet direct et/ou par l'intermédiaire du trajet indirect, les secondes informations de configuration comprenant un paramètre concernant un second RNTI attribué au trajet indirect, et -utiliser le premier RNTI pour décoder les informations de planification transmises par le premier dispositif d'accès ou utiliser le second RNTI pour décoder les informations de planification transmises par le premier dispositif d'accès tout en effectuant une communication à trajets multiples, en fonction des premières et secondes informations de configuration reçues.
PCT/EP2024/072463 2023-08-11 2024-08-08 Dispositif de relais à trajets multiples de relais de liaison latérale et son procédé de fonctionnement Pending WO2025036813A1 (fr)

Applications Claiming Priority (16)

Application Number Priority Date Filing Date Title
US202363532082P 2023-08-11 2023-08-11
US63/532,082 2023-08-11
US202363534443P 2023-08-24 2023-08-24
US63/534,443 2023-08-24
US202363540956P 2023-09-28 2023-09-28
US63/540,956 2023-09-28
US202363543350P 2023-10-10 2023-10-10
US63/543,350 2023-10-10
US202363547021P 2023-11-02 2023-11-02
US63/547,021 2023-11-02
EP23207723.0 2023-11-03
EP23207723 2023-11-03
EP24156453.3 2024-02-08
EP24156453 2024-02-08
US202463562776P 2024-03-08 2024-03-08
US63/562,776 2024-03-08

Publications (1)

Publication Number Publication Date
WO2025036813A1 true WO2025036813A1 (fr) 2025-02-20

Family

ID=92301204

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/072463 Pending WO2025036813A1 (fr) 2023-08-11 2024-08-08 Dispositif de relais à trajets multiples de relais de liaison latérale et son procédé de fonctionnement

Country Status (1)

Country Link
WO (1) WO2025036813A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115734313A (zh) * 2022-10-17 2023-03-03 华为技术有限公司 多路径配置方法、装置及系统
WO2023140701A1 (fr) * 2022-01-21 2023-07-27 Samsung Electronics Co., Ltd. Procédé exécuté par un nœud de communication et nœud de communication dans un système de communication
WO2024096601A1 (fr) * 2022-11-02 2024-05-10 Samsung Electronics Co., Ltd. Dispositif et procédé mis en œuvre par le dispositif dans une communication sans fil
WO2024093081A1 (fr) * 2023-03-07 2024-05-10 Lenovo (Beijing) Limited Dispositifs terminaux, dispositif de réseau et procédés pour des communications multi-trajets
WO2024096679A1 (fr) * 2022-11-03 2024-05-10 Lg Electronics Inc. Procédé et appareil d'émission/réception d'un signal sans fil dans un système de communication sans fil

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023140701A1 (fr) * 2022-01-21 2023-07-27 Samsung Electronics Co., Ltd. Procédé exécuté par un nœud de communication et nœud de communication dans un système de communication
CN115734313A (zh) * 2022-10-17 2023-03-03 华为技术有限公司 多路径配置方法、装置及系统
WO2024096601A1 (fr) * 2022-11-02 2024-05-10 Samsung Electronics Co., Ltd. Dispositif et procédé mis en œuvre par le dispositif dans une communication sans fil
WO2024096679A1 (fr) * 2022-11-03 2024-05-10 Lg Electronics Inc. Procédé et appareil d'émission/réception d'un signal sans fil dans un système de communication sans fil
WO2024093081A1 (fr) * 2023-03-07 2024-05-10 Lenovo (Beijing) Limited Dispositifs terminaux, dispositif de réseau et procédés pour des communications multi-trajets

Similar Documents

Publication Publication Date Title
US12317133B2 (en) Relay apparatus in a mobile communication system
EP3583822B1 (fr) Procédé et appareil de gestion de session pour changer une fonction de plan d'utilisateur dans un système de communication sans fil
JP6441264B2 (ja) 通信制御方法、ユーザ端末、基地局、及びプロセッサ
JP6502582B2 (ja) 基地局及びユーザ端末
JP6586512B2 (ja) 通信方法及び通信装置
JP6169442B2 (ja) 移動通信システム及びユーザ端末
JP2019510432A (ja) 通信方法、ネットワーク側デバイス、およびユーザ端末
US20230276468A1 (en) Managing unicast, multicast and broadcast communication
JPWO2015045860A1 (ja) ユーザ端末及びネットワーク装置
JP6615729B2 (ja) 通信方法、ユーザ端末及びプロセッサ
CN111436049B (zh) 一种初始接入的方法、装置及设备
JP6433433B2 (ja) 通信制御方法及び基地局
WO2025036813A1 (fr) Dispositif de relais à trajets multiples de relais de liaison latérale et son procédé de fonctionnement
JP6235188B2 (ja) 通信制御方法、及びネットワーク装置
JP2017200223A (ja) ユーザ端末、移動通信システム及び方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24754676

Country of ref document: EP

Kind code of ref document: A1