Methods and apparatus for SRB0 message transmission in wireless communication systems

Abstract

A method and apparatus for intermediate user equipment to network relay user equipment are disclosed. In one embodiment, the intermediate user equipment to network relay user equipment receives a radio resource control setting request message from a remote user equipment on an SRB0, wherein the radio resource control setting request message is contained in a first PC5 sidelink relay adaptation protocol data unit without a header. Furthermore, the intermediate user equipment to network relay user equipment transmits the radio resource control setting request message to a layer 2 user equipment to network relay user equipment on the SRB0, wherein the radio resource control setting request message is contained in a second PC5 sidelink relay adaptation protocol data unit with a first header, and the first header contains the user equipment identity of the remote user equipment.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 689,525, filed August 30, 2024, the entire disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure generally relates to wireless communication networks, and more specifically, to methods and apparatus for transmitting SRB0 messages via an intermediate U2N relay UE in a wireless communication system. Background Technology

[0004] With the rapid growth in demand for transmitting large amounts of data to and from mobile communication devices, traditional mobile voice communication networks have evolved into networks that communicate using Internet Protocol (IP) data packets. This IP data packet communication can provide users of mobile communication devices with IP-bearing voice, multimedia, multicast, and video-on-demand communication services.

[0005] An exemplary network architecture is the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). E-UTRAN systems can provide high data throughput to enable the aforementioned IP-based voice and multimedia services. Currently, the 3GPP standards organization is discussing new radio technologies for next-generation technologies (e.g., 5G). Therefore, changes to the current core of the 3GPP standards are currently being submitted and considered to facilitate their evolution and completion. Summary of the Invention

[0006] A method and apparatus for an intermediate UE to a network (U2N) relay user equipment (UE) are disclosed. In one embodiment, the intermediate U2N relay UE establishes a first PC5 connection with a remote UE and a second PC5 connection with a Layer 2 (L2) U2N relay UE. The intermediate U2N relay UE also receives a Radio Resource Control (RRC) setup request message from the remote UE on SRB0, wherein the RRC setup request message is contained in a first PC5 Side Link Relay Adaptation Protocol (SRAP) Protocol Data Unit (PDU) without a header. Furthermore, the intermediate U2N relay UE transmits the RRC setup request message to the L2 U2N relay UE on SRB0, wherein the RRC setup request message is contained in a second PC5 SRAP PDU with a first header, and the first header contains the UE identity (ID) of the remote UE, wherein the UE ID of the remote UE is contained in an RRC reconfiguration message received from a network node. Attached Figure Description

[0007] Figure 1 A diagram of a wireless communication system according to an exemplary embodiment is shown;

[0008] Figure 2 This is a block diagram of a transmitter system (also referred to as an access network) and a receiver system (also referred to as a user equipment or UE) according to an exemplary embodiment;

[0009] Figure 3 This is a functional block diagram of a communication system according to an exemplary embodiment;

[0010] Figure 4 This is based on an exemplary embodiment. Figure 3 Functional block diagram of the program code;

[0011] Figure 5 It is 3GPP TS 38.300V18.2.0. Figure 16 Reproduction of .12.2.1-1;

[0012] Figure 6 It is 3GPP TS 38.300V18.2.0. Figure 16 Reproduction of .12.2.1-2;

[0013] Figure 7 It is 3GPP TS 38.300V18.2.0. Figure 16 Reproduction of .12.5.1-1;

[0014] Figure 8 It is 3GPP TS 38.331V18.2.0. Figure 5 Reproduction of .8.3.1-1;

[0015] Figure 9 It is 3GPP TS 38.351V18.2.0. Figure 4 Reproduction of .2.2-1;

[0016] Figure 10 It is 3GPP TS 38.351V18.2.0. Figure 6 Reproduction of .2.2-1;

[0017] Figure 11 It is 3GPP TS 38.351V18.2.0. Figure 6 Reproduction of .2.2-2;

[0018] Figure 12 This is a reproduction of Table 6.3.6-1 of 3GPP TS 38.351V18.2.0;

[0019] Figure 13 It is 3GPP TS 38.321V18.2.0. Figure 6 Reproduction of .1.6-1;

[0020] Figure 14 It is 3GPP TS 38.321V18.2.0. Figure 6 Reproduction of .1.6-2;

[0021] Figure 15 This is a reproduction of Table 6.2.4-1 of 3GPP TS 38.321V18.2.0;

[0022] Figure 16 This is a diagram illustrating the control plane protocol stack for two-hop L2 UE to network relay according to an exemplary embodiment;

[0023] Figure 17 This is a message flow diagram illustrating an example of establishing an L2 U2N remote UE connection for a two-hop L2 UE to network relay, according to an exemplary embodiment.

[0024] Figure 18 This is a flowchart based on an exemplary embodiment. Detailed Implementation

[0025] The exemplary wireless communication systems and apparatus described below employ wireless communication systems that support broadcast services. Wireless communication systems are widely deployed to provide various types of communication, such as voice, data, etc. These systems may be based on Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Orthogonal Frequency Division Multiple Access (OFDMA), 3GPP Long Term Evolution (LTE) Radio Access, 3GPP Long Term Evolution Advanced (LTE-A), 3GPP2 Ultra Mobile Broadband (UMB), WiMax, 3GPP New Radio (NR), or some other modulation techniques.

[0026] Specifically, the exemplary wireless communication systems and apparatus described below can be designed to support one or more standards, such as those provided by the consortium referred to herein as 3GPP, which is named the “3rd Generation Partnership Project”, including: TS 38.300 V18.2.0, “NR; General Description of NR and NG-RAN; Phase 2 (Revision 18)”; TS 38.331 V18.2.0, “NR; Radio Resource Control (RRC) Protocol Specification (Revision 18)”; TS 38.351 V18.2.0, “NR; Sidelink Relay Adaptation Protocol (SRAP) Specification (Revision 18)”; TS 38.321 V18.2.0, “NR; Media Access Control (MAC) Protocol Specification (Revision 18)”; and TR 23.700-03V1.0.0, “Study on system enhancements based on proximity-based services (ProSe) in 5G systems (5GS); Phase 3 (Revision 19)”. The standards and documents listed above are hereby explicitly incorporated in full.

[0027] Figure 1 A multiple access wireless communication system according to an embodiment of the present invention is illustrated. Access network 100 (AN) includes multiple antenna groups, one including antennas 104 and 106, another including antennas 108 and 110, and yet another including antennas 112 and 114. Figure 1 In the diagram, only two antennas are shown for each antenna group; however, more or fewer antennas can be used for each antenna group. Access terminal 116 (AT) communicates with antennas 112 and 114, where antennas 112 and 114 transmit information to access terminal 116 via forward link 120 and receive information from access terminal 116 via reverse link 118. Access terminal (AT) 122 communicates with antennas 106 and 108, where antennas 106 and 108 transmit information to access terminal (AT) 122 via forward link 126 and receive information from access terminal (AT) 122 via reverse link 124. In an FDD system, communication links 118, 120, 124, and 126 can communicate using different frequencies. For example, forward link 120 can use a frequency different from that used by reverse link 118.

[0028] Each group of antennas and / or the area in which they are designed to communicate is often referred to as a sector of the access network. In an embodiment, each antenna group is designed to communicate with an access terminal in a sector of the area covered by access network 100.

[0029] In communications via forward links 120 and 126, the transmit antennas of access network 100 can utilize beamforming to improve the signal-to-noise ratio of the forward links for different access terminals 116 and 122. Furthermore, compared to an access network that transmits to all its access terminals via a single antenna, the access network using beamforming to transmit to access terminals randomly distributed throughout its coverage area causes less interference to access terminals in neighboring cells.

[0030] An access network (AN) can be a fixed station or base station used for communication with terminals, and may also be referred to as an access point, Node B, base station, enhanced base station, evolved Node B (eNB), network node, network, or other terminology. An access terminal (AT) may also be referred to as a user equipment (UE), wireless communication device, terminal, access terminal, or other terminology.

[0031] Figure 2 This is a simplified block diagram of an embodiment of the transmitter system 210 (also referred to as the access network) and receiver system 250 (also referred to as the access terminal (AT) or user equipment (UE)) in the MIMO system 200. At the transmitter system 210, service data for multiple data streams is provided from the data source 212 to the transport (TX) data processor 214.

[0032] In one embodiment, each data stream is transmitted via a corresponding transmit antenna. The TX data processor 214 formats, decodes, and interleaves the service data of the data streams based on a specific decoding scheme selected for each data stream to provide decoded data.

[0033] OFDM technology can be used to multiplex the decoded data and pilot data of each data stream. The pilot data is typically a known data pattern processed in a known manner and can be used at the receiver system to estimate the channel response. The multiplexed pilot and decoded data for said data streams are then modulated (i.e., symbol mapped) based on a specific modulation scheme (e.g., BPSK, QPSK, M-PSK, or M-QAM) selected for each data stream to provide modulated symbols. Instructions executed by processor 230 determine the data rate, decoding, and modulation for each data stream.

[0034] The modulation symbols of all data streams are then provided to the TX MIMO processor 220, which can further process the modulation symbols (e.g., for OFDM). The TX MIMO processor 220 then... T A modulation symbol stream is provided to N TTransmitters (TMTRs) 222a to 222t. In some embodiments, the TX MIMO processor 220 applies beamforming weights to symbols of the data stream and the antennas transmitting said symbols therefrom.

[0035] Each transmitter 222 receives and processes a corresponding symbol stream to provide one or more analog signals, and further modulates (e.g., amplifies, filters, and up-converts) the analog signals to provide modulated signals suitable for transmission via a MIMO channel. Then, from N... T Antennas 224a to 224t transmit N from transmitters 222a to 222t. T A modulated signal.

[0036] At receiver system 250, by N R Each antenna 252a to 252r receives the transmitted modulated signal and provides the signal received from each antenna 252 to a corresponding receiver (RCVR) 254a to 254r. Each receiver 254 modulates (e.g., filters, amplifies, and down-converts) the corresponding received signal, digitizes the modulated signal to provide a sample, and further processes the sample to provide a corresponding "received" symbol stream.

[0037] The RX data processor 260 then uses specific receiver processing technology from N R 254 receivers receive and process N R Each received symbol stream provides N T Each detected symbol stream is then demodulated, deinterleaved, and decoded by the RX data processor 260 to recover the service data used for the data stream. The processing performed by the RX data processor 260 is complementary to the processing performed by the TX MIMO processor 220 and TX data processor 214 at the transmitter system 210.

[0038] Processor 270 periodically determines which pre-decoding matrix to use (discussed below). Processor 270 formulates a reverse link message including the matrix index part and the rank part.

[0039] The reverse link message may include various types of information about the communication link and / or the received data stream. The reverse link message is then processed by the TX data processor 238 (which also receives service data from several data streams from the data source 236), modulated by the modulator 280, regulated by the transmitters 254a to 254r, and transmitted back to the transmitter system 210.

[0040] At transmitter system 210, the modulated signal from receiver system 250 is received by antenna 224, conditioned by receiver 222, demodulated by demodulator 240, and processed by RX data processor 242 to extract the reverse link message transmitted by receiver system 250. Next, processor 230 determines which pre-decoding matrix to use to determine beamforming weights and then processes the extracted message.

[0041] Turning Figure 3 This figure illustrates an alternative simplified functional block diagram of a communication device according to an embodiment of the present invention. Figure 3 As shown, the communication device 300 in the wireless communication system can be used to achieve... Figure 1 UE (or AT) 116 and 122 or Figure 1 The communication device 300 is a base station (or AN) 100, and the wireless communication system is preferably an NR system. The communication device 300 may include an input device 302, an output device 304, a control circuit 306, a central processing unit (CPU) 308, a memory 310, program code 312, and a transceiver 314. The control circuit 306 executes the program code 312 in the memory 310 via the CPU 308, thereby controlling the operation of the communication device 300. The communication device 300 can receive signals input by a user via the input device 302 (e.g., a keyboard or keypad) and can output images and sounds via the output device 304 (e.g., a monitor or speaker). The transceiver 314 is used to receive and transmit wireless signals, pass received signals to the control circuit 306, and wirelessly output signals generated by the control circuit 306. Alternatively, the communication device 300 in a wireless communication system can also be used. Figure 1 AN 100 in the middle.

[0042] Figure 4 According to an embodiment of the present invention Figure 3 The diagram shows a simplified block diagram of program code 312. In this embodiment, program code 312 includes an application layer 400, a layer 3 portion 402, and a layer 2 portion 404, and is coupled to a layer 1 portion 406. Layer 3 portion 402 typically performs radio resource control. Layer 2 portion 404 typically performs link control. Layer 1 portion 406 typically performs physical connections.

[0043] 3GPP TS 38.300 specifies the following procedures related to UE to network relay:

[0044] 16.12 Side Link Relay

[0045] 16.12.1 General Provisions

[0046] Sidelink relay supports 5G ProSe UE-to-network relay (U2N relay) functionality (specified in TS23.304

[48] ) to provide network connectivity for U2N remote UEs. Both L2 and L3 U2N relay architectures are supported. The L3 U2N relay architecture is transparent to the NG-RAN serving U2N relay UEs, the difference being the control of sidelink resources. Detailed architecture and procedures for L3 U2N relay can be found in TS23.304

[48] .

[0047] U2N relay UEs will be in RRC_CONNECTED state to perform relay of unicast data.

[0048] For L2 U2N trunk operations, the following RRC state combinations are supported:

[0049] Both the L2 U2N relay and the L2 U2N remote UE should be in RRC_CONNECTED state to perform the transmission / reception of unicast data via relay; and

[0050] - An L2 U2N relay UE can be in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED state, as long as all L2 U2N remote UEs connected to the L2 U2N relay UE are in RRC_INACTIVE or RRC_IDLE state.

[0051] A single unicast link is established between an L2 U2N relay UE and an L2 U2N remote UE. NG-RAN services from a given L2 U2N relay UE to an L2 U2N remote UE and services of the L2 U2N relay UE should be separated in different Uu RLC channels.

[0052] For L2 U2N relay, L2 U2N remote UEs can be configured to use resource allocation mode 2 (as specified in 5.7.2 and 16.9.3.1) only for relay data.

[0053] [...]

[0054] 16.12.2 Protocol Architecture

[0055] 16.12.2.1 L2 UE to Network Relay

[0056] The protocol stacks for the user plane and control plane of the L2 U2N relay architecture are in Figure 16 .12.2.1-1 and Figure 16As shown in .12.2.1-2, the SRAP sublayer is disposed above the RLC sublayer for CP and UP on the PC5 interface and Uu interface. UuSDAP, PDCP, and RRC terminate between the L2 U2N remote UE and gNB, while SRAP, RLC, MAC, and PHY terminate at each hop (i.e., the link between the L2 U2N remote UE and the L2 U2N relay UE and the link between the L2 U2N relay UE and the gNB).

[0057] For L2 U2N relay, the SRAP sublayer via the PC5 hop is used only for bearer mapping purposes. There is no SRAP sublayer on the PC5 hop for messages used to relay L2 U2N remote UEs on the BCCH and PCCH. For L2 U2N remote UE messages on SRB0, the SRAP header does not exist on the PC5 hop, but it does exist on the Uu hop for DL ​​and UL.

[0058] The 3GPP TS 38.300V18.2.0 standard is named "User Plane Protocol Stack for L2 UE to Network Relay". Figure 16 .12.2.1-1 was reproduced as Figure 5 ]

[0059] The 3GPP TS 38.300V18.2.0 is named "Control Plane Protocol Stack for L2 UE to Network Relay". Figure 16 .12.2.1-2 was reproduced as Figure 6 ]

[0060] For L2 U2N trunks, specifically for the uplink:

[0061] The Uu SRAP sublayer performs UL bearer mapping between end-to-end Uu radio bearers of L2 U2N remote UEs (identified by the local remote UE ID and associated bearer ID for the purpose of this mapping) and the egress Uu relay RLC channel through the Uu interface of the L2 U2N relay UE. For uplink relay services, different end-to-end Uu radio bearers (SRBs or DRBs) of the same L2 U2N remote UE and / or different L2U2N remote UEs can be multiplexed on the same egress Uu relay RLC channel;

[0062] The Uu SRAP sublayer supports L2 U2N remote UE identification for UL services. The identity information of the L2 U2N remote UE end-to-end Uu radio bearer and the local remote UE ID are included in the Uu SRAP header at the UL so that the gNB can associate the received packets for a specific PDCP entity with the correct end-to-end Uu radio bearer of the L2 U2N remote UE.

[0063] - The PC5 SRAP sublayer at the L2 U2N remote UE supports UL bearer mapping between the L2 U2N remote UE end-to-end Uu radio bearer and the egress PC5 relay RLC channel.

[0064] For L2 U2N relays, specifically for the downlink:

[0065] The Uu SRAP sublayer performs DL bearer mapping at the gNB to map end-to-end Uu radio bearers (SRBs, DRBs) of L2 U2N remote UEs (identified by the local remote UE ID and associated bearer ID for this mapping purpose) to a Uu trunk RLC channel. The Uu SRAP sublayer performs DL bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRBs or DRBs) of L2 U2N remote UEs and / or different L2 U2N remote UEs and a single Uu trunk RLC channel on the L2 U2N trunk UE Uu interface.

[0066] The -Uu SRAP sublayer supports L2 U2N remote UE identification for DL ​​services. The identity information of the L2 U2N remote UE end-to-end Uu radio bearer and the local remote UE ID is included by the gNB in ​​the Uu SRAP header at the DL for L2 U2N relay UEs to identify the corresponding end-to-end Uu radio bearer of the L2 U2N remote UE;

[0067] - Perform DL bearer mapping between the end-to-end Uu radio bearer and the egress PC5 relay RLC channel of the L2 U2N remote UE at the PC5 SRAP sublayer;

[0068] The PC5 SRAP sublayer at the L2 U2N remote UE associates received packets with the correct PDCP entity associated with a given end-to-end Uu radio bearer of the L2 U2N remote UE based on the identity information contained in the PC5 SRAP header.

[0069] The local remote UE ID is contained in the PC5 SRAP header and the Uu SRAP header. L2 U2N relay UEs are configured by the gNB with a local remote UE ID that will be used in the SRAP header. L2 U2N remote UEs obtain their local remote ID from the gNB via a Uu RRC message containing RRCSetup, RRCReconfiguration, RRCResume, and RRCReestablishment.

[0070] The end-to-end DRB or end-to-end SRB (except SRB0) of an L2 U2N remote UE can be multiplexed to the PC5 trunk RLC channel and the Uu trunk RLC channel in both PC5 hop and Uu hop. However, the end-to-end DRB and end-to-end SRB cannot be mapped to the same PC5 trunk RLC channel or the same Uu trunk RLC channel.

[0071] The gNB's responsibility is to avoid conflicts in the use of local and remote UE IDs. The gNB can update the local and remote UE IDs by sending an updated local and remote UE ID via an RRCReconfiguration message. The serving gNB can perform local and remote UE ID updates independently of the PC5 unicast link L2 ID update procedure.

[0072] [...]

[0073] 16.12.5 Control plane program for L2 U2N relays

[0074] 16.12.5.1 RRC Connection Management

[0075] Before transmitting user plane data, L2 U2N remote UEs need to establish their own PDU session / DRB with the network.

[0076] The NR sidelink PC5 unicast link establishment procedure can be used to set up a secure unicast link between an L2 U2N remote UE and an L2 U2N relay UE before establishing a Uu RRC connection between the L2 U2N remote UE and the network via an L2 U2N relay UE.

[0077] The establishment of Uu SRB1 / SRB2 and DRB for L2 U2N remote UEs undergoes the Uu configuration procedure for L2 UE to network relay.

[0078] Figure 16 The following advanced connection establishment procedure in .12.5.1-1 applies to L2 U2N trunks and L2 U2N remote UEs:

[0079] The 3GPP TS 38.300V18.2.0 standard is titled "Procedure for Establishing L2 U2N Remote UE Connections". Figure 16 .12.5.1-1 was reproduced as Figure 7 ]

[0080] 1. L2 U2N remote and L2 U2N relay UEs perform discovery procedures and establish PC5-RRC connections using the NR side link PC5 unicast link establishment procedure.

[0081] 2. The L2 U2N remote UE sends a first RRC message (i.e., RRCSetupRequest) using the designated PC5 trunk RLC channel configuration for its connection establishment with the gNB via the L2 U2N trunk UE. The L2 U2N trunk UE sends a SidelinkUEInformationNR message to request the special configuration required to support the trunk operation of the L2 U2N remote UE. If the L2 U2N trunk UE is not in RRC_CONNECTED, it needs to perform its own Uu RRC connection establishment immediately after receiving the message on the designated PC5 trunk RLC channel. After the L2 U2N trunk UE's RRC connection establishment procedure and sending the SidelinkUEInformationNR message, the gNB configures the SRB0 trunk Uu trunk RLC channel for the U2N trunk UE. The gNB responds to the L2 U2N remote UE with an RRCSetup message. The RRCSetup message is sent to the L2 U2N remote UE using the SRB0 trunk Uu trunk channel on Uu and the designated PC5 trunk RLC channel on PC5.

[0082] Note 1: Empty.

[0083] 3. The gNB and L2 U2N relay UE perform the relay channel setup procedure via Uu. Based on the configuration from the gNB, the L2U2N relay / remote UE establishes the PC5 relay RLC channel for SRB1 to relay to the L2 U2N remote / remote UE via PC5.

[0084] 4. Using the SRB1 trunk channel on PC5 and the SRB1 trunk channel on Uu configured for the L2 U2N trunk UE, the L2 U2N remote UE sends the RRCSetupComplete message to the gNB via the L2 U2N trunk UE. Subsequently, the L2 U2N remote UE is in RRC_CONNECTED state as if it were the gNB.

[0085] 5. L2 U2N remote UEs and gNBs establish security by following the Uu security mode procedure and forward security messages through L2 U2N relay UEs.

[0086] 6. The gNB sends an RRCReconfiguration message to the L2 U2N remote UE via the L2 U2N relay UE to configure the end-to-end SRB2 / DRB of the L2 U2N remote UE. The L2 U2N remote UE responds by sending an RRCReconfigurationComplete message to the gNB via the L2 U2N relay UE. Additionally, the gNB can configure an additional Uu relay RLC channel between the gNB and the L2 U2N relay UE, and a PC5 relay RLC channel between the L2 U2N relay UE and the L2 U2N remote UE for relay services.

[0087] 3GPP TS 38.331 specifies the sidelink UE information and the specified SCCH configuration for SRB0 associated with the UE to the network relay as follows:

[0088] 5.8.3 Sidelink UE Information Used for NR Sidelink Communication / Discovery / Location

[0089] 5.8.3.1 General Provisions

[0090] The 3GPP TS 38.331V18.2.0 specification is titled "Sidelink UE Information for NR Sidelink Communication / Discovery / Location". Figure 5 .8.3.1-1 was reproduced as Figure 8 ]

[0091] The purpose of this procedure is to notify the UE to the network:

[0092] - Whether you are interested in receiving or transmitting NR sidelink communication / discovery / location or are no longer interested.

[0093] - Requesting the assignment or release of transport resources for NR sidelink communication / discovery / location.

[0094] - Reporting QoS parameters and QoS profiles related to NR sidelink communication.

[0095] - Reporting the mapping frequency of each QoS flow associated with NR sidelink communication.

[0096] - Reporting associated Tx profiles for each QoS flow related to NR sidelink multicast and broadcast communications.

[0097] - Reporting a detected sidelink radio link failure, sidelink RRC reconfiguration failure, or sidelink carrier failure.

[0098] - Reporting sidelink UE capability information for associated peer UEs used for unicast communication.

[0099] - Reporting RLC mode information for sidelink data radio bearers received from associated peer UEs used for unicast communication.

[0100] - Reporting accepted sidelink DRX configuration received from the associated peer UE used for NR sidelink unicast reception.

[0101] - When the UE is configured with sl-ScheduledConfig, it is reporting sidelink DRX assistance information received from the associated peer UE used for NR sidelink unicast transmission.

[0102] - When the UE is configured with sl-ScheduledConfig, it is reporting a sidelink DRX on / off indication for the associated destination layer 2 ID for NR sidelink multicast transmission.

[0103] - For NR sidelink multicast or broadcast reception, it is reporting the destination layer 2 ID and QoS attribute set associated with the service of interest of the application sidelink DRX.

[0104] - When the UE is configured with sl-ScheduledConfig, it is reporting DRX configuration rejection information from its associated peer UE used for NR sidelink unicast transmission.

[0105] - Reporting parameters related to U2N relay operation

[0106] - Reporting parameters related to U2U relay operation.

[0107] [...]

[0108] 5.8.3.3 Actions related to the transmission of SidelinkUEInformationNR messages

[0109] The UE should configure the content of the SidelinkUEInformationNR message as follows:

[0110] [...]

[0111] 3> If SIB12 contains sl-L2U2N-Relay and is configured by the upper layer to transmit NR sidelink L2 U2N relay communication and the UE acts as an L2 U2N relay UE:

[0112] 4> In sl-TxResourceReqListCommRelay, which contains sl-TxResourceReqL2U2N-Relay, and for each destination that assigns NR-side link L2 U2N relay communication resources to the requesting network, set its fields as follows (if necessary):

[0113] 5> Set sl-DestinationIdentityL2U2N as the destination identity configured by the upper layer for use in NR side link L2 U2N relay communication transmission;

[0114] 5> Set sl-TxInterestedFreqListL2U2N to indicate the frequency of the associated destination used for L2 U2N relay communication transmission on the NR side link;

[0115] 5> Set sl-TypeTxSyncListL2U2N to the current synchronization reference type used on the associated sl-TxInterestedFreqListL2U2N for NR side link L2 U2N relay communication transmission;

[0116] 5> Set sl-LocalID-Request to request a local ID for L2 U2N remote UE transition to RRC_CONNECTED or in the RRC_CONNECTED state;

[0117] 5> Set sl-PagingIdentityRemoteUE to the paging UE ID received from the peer L2 U2N remote UE, provided that it has not been released as in 5.8.9.8.3;

[0118] 5> Configure sl-CapabilityInformationSidelink to include UECapabilityInformationSidelink messages received from peer UEs (if they exist);

[0119] 4> Include ue-Type and set it to relayUE;

[0120] [...]

[0121] 9.1 Specify Configuration

[0122] 9.1.1 Logical Channel Configuration

[0123] [...]

[0124] 9.1.1.4 SCCH Configuration

[0125] [...]

[0126] The parameters specified for NR sidelink L2 U2N relay operation define the PC5 relay RLC channel used for SRB0 message transmission / reception of remote UEs. The PC5 relay RLC channel using this configuration is named SL-RLC0.

[0127]

[0128] 3GPP TS 38.351 specifies the protocol data units, formats, and parameters for the SRAP layer as follows:

[0129] 4.2.2 SRAP Entities

[0130] Figure 4 .2.2-1 shows a possible structure for the SRAP sublayer. The figure is based on the radio interface protocol architecture defined in TS 38.300[2].

[0131] The title of 3GPP TS 38.351V18.2.0 is "SRAP Architecture Overview". Figure 4 .2.2-1 was reproduced as Figure 9 ]

[0132] On a U2N trunk UE, the SRAP sublayer contains one SRAP entity at the Uu interface and a separate, co-located SRAP entity at the PC5 interface. On a U2N remote UE, the SRAP sublayer contains only one SRAP entity at the PC5 interface. On both U2U trunk and U2U remote UEs, the SRAP sublayer contains only one SRAP entity at the PC5 interface.

[0133] Each SRAP entity has a transmitting portion and a receiving portion. In the U2N case, across the PC5 interface, the transmitting portion of the SRAP entity at the U2N remote UE has a corresponding receiving portion of the SRAP entity at the U2N relay UE, and vice versa. Across the Uu interface, the transmitting portion of the SRAP entity at the U2N relay UE has a corresponding receiving portion of the SRAP entity at the gNB, and vice versa.

[0134] [...]

[0135] exist Figure 4 2.2-2 and Figure 4 In the example of .2.2-3, at the relay UE:

[0136] - For packets that do not correspond to SRB0, the receive portion of the SRAP entity on the Uu interface delivers the SRAP data PDU to the transmit portion of the co-located SRAP entity on the PC5 interface, and the receive portion of the SRAP entity on the PC5 interface delivers the SRAP data PDU to the transmit portion of the co-located SRAP entity on the Uu interface. Alternatively, the receive portion can deliver the SRAP SDU to the transmit portion of the co-located SRAP entity. When transmitting the SRAP SDU, the receive portion removes the SRAP header, and the transmit portion of the relay UE adds an SRAP header with the same SRAP header content as that carried in the SRAP data PDU header before removal. In the implementation, transmitting the SRAP SDU in this manner is therefore functionally equivalent to transmitting the SRAP data PDU. The following specifications therefore relate to the transmission of SRAP packets.

[0137] - For UL packets corresponding to SRB0, the receive portion on the SRAP entity of the PC5 interface delivers the SRAP SDU to the transmit portion on the co-located SRAP entity of the Uu interface, and the transmit portion on the SRAP entity of the Uu interface adds the SRAP header in accordance with clause 5.3.3.

[0138] - For DL ​​packets corresponding to SRB0, the receive portion of the SRAP entity on the Uu interface delivers the SRAP data PDU to the transmit portion of the co-located SRAP entity on the PC5 interface, and the transmit portion of the SRAP entity on the PC5 interface removes the SRAP header according to clause 5.2.2. Figure 4 2.2-2 or Figure 4 An alternative to handling DL packets corresponding to SRB0, not shown in .2.2-3, is that the receive portion of the SRAP entity on the Uu interface removes the SRAP header and delivers the SRAP SDU to the transmit portion of the co-located SRAP entity on the PC5 interface.

[0139] [...]

[0140] 5.2 DL Data Transmission

[0141] 5.2.1 Reception Operation of U2N Relay UE

[0142] After receiving the SRAP data PDU from the lower layer, the receive portion of the SRAP entity on the Uu interface of the U2N relay UE should:

[0143] - The delivery portion that delivers SRAP packets to the co-located SRAP entity on the PC5 interface.

[0144] 5.2.2 Transmission Operations of U2N Relay UE

[0145] 5.2.2.0 General Provisions

[0146] The transmitting part of the SRAP entity on the PC5 interface of the U2N relay UE receives SRAP data packets from the receiving part of the SRAP entity on the Uu interface of the same U2N relay UE, and constructs SRAP data PDUs as needed (see Clause 4.2.2).

[0147] When the transmission part of the SRAP entity on the PC5 interface has an SRAP data PDU to transmit, the transmission part of the SRAP entity on the PC5 interface should:

[0148] - Determine the export link in accordance with Clause 5.2.2.1;

[0149] - Determine the egress RLC channel according to clause 5.2.2.2;

[0150] - If the SRAP data PDU is used for SRB0 (the bearer ID field is 0, and the bearer is identified as SRB based on the sl-RemoteUE-RB-Identity associated with the entry of sl-EgressRLC-ChannelUu containing the LCID of the Uu Relay RLC channel from which the SRAP data PDU was received):

[0151] -Remove the SRAP header from the SRAP data PDU;

[0152] - Submit this SRAP data PDU to the determined egress RLC channel of the determined egress link.

[0153] 5.2.2.1 Determining the export link

[0154] For the SRAP data PDU to be transmitted, the SRAP entity should:

[0155] - If an entry exists in sl-RemoteUE-ToAddModList, its sl-LocalIdentity contained in sl-SRAP-ConfigRelay matches the UE ID field in the SRAP data PDU:

[0156] - Determine the egress link on the PC5 interface corresponding to the sl-L2IdentityRemote configured for the sl-LocalIdentity of interest, as specified in TS 38.331[3].

[0157] 5.2.2.2 Determination of the Egress RLC Channel

[0158] For the SRAP data PDU to be transmitted, the SRAP entity should:

[0159] - If the SRAP data PDU is used for SRB0 (the bearer ID field is 0 and the bearer is identified as SRB based on the sl-RemoteUE-RB-Identity associated with the entry of sl-EgressRLC-ChannelUu containing the LCID of the Uu Relay RLC channel from which the SRAP data PDU was received):

[0160] - Determine the egress PC5 relay RLC channel in the determined egress link corresponding to the logical ChannelIdentity for SL-RLC0, as specified in TS 38.331[3].

[0161] - Otherwise, if an entry exists in sl-RemoteUE-ToAddModList, its sl-LocalIdentity in sl-SRAP-ConfigRelay matches the UE ID field in the SRAP data PDU, which contains an sl-RemoteUE-RB-Identity matching the SRB or DRB identity of the SRAP data PDU determined by the bearer ID field (for bearer IDs shared by SRB and DRB, SRB and DRB are distinguished based on the sl-RemoteUE-RB-Identity associated with an entry containing an sl-EgressRLC-ChannelUu that matches the LCID of the Uu relay RLC channel from which the SRAP data PDU is received, and for DRB, the DRB identity is the bearer ID plus 1):

[0162] - If the SRAP data PDU is used for SRB1, but the corresponding sl-EgressRLC-ChannelPC5 does not exist in sl-SRAP-ConfigRelay:

[0163] - Determine the egress PC5 relay RLC channel in the determined egress link corresponding to the logical ChannelIdentity for SL-RLC1, as specified in TS 38.331[3].

[0164] -otherwise:

[0165] - Determine the egress PC5 relay RLC channel in the determined egress link corresponding to the sl-EgressRLC-ChannelPC5 configured for the sl-LocalIdentity and the sl-RemoteUE-RB-Identity of interest, as specified in TS38.331[3].

[0166] 5.2.3 Receiving Operation of U2N Remote UE

[0167] After receiving the SRAP data PDU from the lower layer, the receiving part of the SRAP entity should:

[0168] -If the SRAP data PDU is not used for SRB0 (not received from SL-RLC0, as specified in TS 38.331[3]):

[0169] -If the SRAP data PDU is received from SL-RLC1, as specified in TS 38.331[3]:

[0170] - By ignoring the UE ID field and bearer ID field of this SRAP data PDU, the SRAP header of this SRAP data PDU is removed and the SRAP SDU is delivered to the PDCP entity of SRB1;

[0171] -otherwise:

[0172] - Remove the SRAP header of this SRAP data PDU and deliver the SRAP SDU to the upper-layer entity corresponding to the bearer ID field of this SRAP data PDU (for bearer IDs shared by SRB and DRB, SRB and DRB are distinguished based on the sl-RemoteUE-RB-Identity associated with the entry of sl-EgressRLC-ChannelPC5 containing the LCID of the PC5 relay RLC channel from which the SRAP data PDU is received, and for DRB, DRB identity is bearer ID plus 1);

[0173] -otherwise:

[0174] - Deliver the SRAP SDU (i.e., the same as the SRAP PDU used for SRB0) to the upper layer, i.e., the RRC layer entity (TS38.331[3]).

[0175] 5.3UL Data Transmission

[0176] 5.3.1 Transmission Operation of U2N Remote UE

[0177] The transmission part of the SRAP entity on the PC5 interface of the U2N remote UE can receive SRAP SDU from the upper layer and construct SRAP data PDU.

[0178] After receiving the SRAP SDU from the upper layer, the transmission portion of the SRAP entity on the PC5 interface should:

[0179] -If SRAP SDU is not for SRB0:

[0180] - Determine the UE ID field and bearer ID field according to clause 5.3.1.1;

[0181] - Construct an SRAP data PDU with an SRAP header in accordance with Clause 6.2.2, wherein the UE ID field and bearer ID field are set to the determined values;

[0182] -otherwise:

[0183] - Construct an SRAP data PDU without an SRAP header in accordance with Clause 6.2.2.

[0184] - Determine the egress RLC channel according to clause 5.3.1.2;

[0185] - Submit this SRAP data PDU to the determined egress RLC channel.

[0186] 5.3.1.1 Determination of UE ID field and bearer ID field

[0187] For SRAP SDUs received from the upper layer, the SRAP entity should:

[0188] - Determine the UE ID field corresponding to sl-LocalIdentity as specified in TS 38.331[3];

[0189] - Determine the bearer ID field corresponding to the SRB identity for the SRAP SDU received from it (i.e., set the bearer ID field to srb-Identity) or the bearer ID field corresponding to the DRB identity minus 1 for the DRB (i.e., set the bearer ID field to drb-Identity minus 1), as specified in TS 38.331[3] and configure it.

[0190] 5.3.1.2 Determination of the Egress RLC Channel

[0191] For the SRAP data PDU to be transmitted, the SRAP entity should:

[0192] -If the SRAP data PDU is for SRB0:

[0193] - Determine the egress PC5 relay RLC channel in the link with the U2N relay UE corresponding to the logical ChannelIdentity for SL-RLC0, as specified in TS 38.331[3].

[0194] - Otherwise, if the SRAP data PDU is for SRB1, and if there is no entry in sl-MappingToAddModList, its sl-RemoteUE-RB-Identity matches the SRB identity of the SRAP data PDU, or if there is an entry in sl-MappingToAddModList that does not have a corresponding sl-EgressRLC-ChannelPC5:

[0195] - Determine the egress PC5 relay RLC channel in the link with the U2N relay UE corresponding to the logical ChannelIdentity for SL-RLC1, as specified in TS 38.331[3].

[0196] - Otherwise, if an entry exists in sl-MappingToAddModList, its sl-RemoteUE-RB-Identity matches the SRB or DRB identity of the SRAP data PDU:

[0197] - Determine the egress PC5 relay RLC channel of the link to the U2N relay UE corresponding to the sl-EgressRLC-ChannelPC5 configured for the sl-RemoteUE-RB-Identity of interest, as specified in TS 38.331[3].

[0198] 5.3.2 Reception Operation of U2N Relay UE

[0199] After receiving the SRAP data PDU from the lower layer, the receiving part of the SRAP entity on the PC5 interface should:

[0200] - The delivery portion that delivers SRAP packets to the co-located SRAP entity on the Uu interface.

[0201] 5.3.3 Transmission Operations of U2N Relay UE

[0202] The transmitting part of the SRAP entity on the Uu interface of a U2N relay UE can receive SRAP data packets from the receiving part of the SRAP entity on the PC5 interface of the same U2N relay UE, and construct SRAP data PDUs as needed (see Clause 4.2.2).

[0203] When the transmission part of the SRAP entity on the Uu interface has SRAP data PDUs to transmit, the transmission part of the SRAP entity on the Uu interface should:

[0204] -If the SRAP data PDU is received from SL-RLC0, as specified in TS 38.331[3]:

[0205] - Determine the UE ID field and bearer ID field according to Clause 5.3.3.1;

[0206] - Construct an SRAP data PDU with an SRAP header in accordance with Clause 6.2.2, wherein the UE ID field and bearer ID field are set to the determined values;

[0207] - Determine the egress RLC channel according to clause 5.3.3.2;

[0208] - Submit this SRAP data PDU to the determined egress RLC channel.

[0209] 5.3.3.1 Determination of UE ID field and bearer ID field

[0210] For SRAP data PDUs received from SL-RLC0 as specified in TS 38.331[3], the SRAP entity shall:

[0211] - If an entry exists in sl-RemoteUE-ToAddModList, its sl-L2IdentityRemote matches the Layer 2 ID of the remote UE from which it received SRAP data PDUs:

[0212] - Determine the UE ID field corresponding to the sl-LocalIdentity configured for the sl-L2IdentityRemote of interest, as specified in TS 38.331[3];

[0213] - Set the bearer ID field to 0 (i.e., set the bearer ID field to 0).

[0214] 5.3.3.2 Determination of the Egress RLC Channel

[0215] For the SRAP data PDU to be transmitted, the SRAP entity should:

[0216] - If an entry exists in sl-RemoteUE-ToAddModList, its sl-LocalIdentity contained in sl-SRAP-ConfigRelay matches the UE ID field in the SRAP data PDU:

[0217] -If the SRAP data PDU is for SRB0:

[0218] - Determine the egress Uu relay RLC channel corresponding to the sl-EgressRLC-ChannelUu configured for the SRB0 for the sl-LocalIdentity of interest, as specified in TS 38.331[3].

[0219] - Otherwise, if the SRAP data PDU is received from SL-RLC1, as specified in TS 38.331[3]:

[0220] - Determine the egress Uu relay RLC channel corresponding to the sl-EgressRLC-ChannelUu configured for the SRB1 for the sl-LocalIdentity of interest, as specified in TS 38.331[3].

[0221] - Otherwise, if an entry exists in sl-RemoteUE-ToAddModList containing an sl-RemoteUE-RB-Identity that matches the SRB or DRB identity of the SRAP data PDU determined by the bearer ID field (for bearer IDs shared by SRB and DRB, SRB and DRB are distinguished based on the sl-RemoteUE-RB-Identity associated with an entry containing an sl-EgressRLC-ChannelPC5 entry that matches the LCID of the PC5 Relay RLC channel from which the SRAP data PDU was received, and for DRB, the DRB identity is the bearer ID plus 1):

[0222] - Determine the egress Uu relay RLC channel corresponding to the sl-EgressRLC-ChannelUu configured for the sl-LocalIdentity and the sl-RemoteUE-RB-Identity of interest, as specified in TS 38.331[3].

[0223] 6. Protocol Data Units, Formats, and Parameters

[0224] 6.1 Protocol Data Unit

[0225] 6.1.1 Data PDU

[0226] SRAP data PDUs are used to deliver the following content with or without a PDU header:

[0227] - Upper-level data.

[0228] 6.2 format

[0229] 6.2.1 General Provisions

[0230] SRAP data PDUs are bit strings that are byte-aligned (i.e., multiples of 8 bits) in length. The format of SRAP data PDUs is described in Clause 6.2.2 and their parameters are described in Clause 6.3.

[0231] 6.2.2 Data PDU

[0232] Figure 6 .2.2-1 shows the format of a U2N SRAP data PDU, with the SRAP header configured. This SRAP data PDU format applies to U2N SRAP SDUs, except for those used for SRB0s delivered via the PC5 interface.

[0233] The 3GPP TS 38.351V18.2.0 standard is titled "U2N SRAP Data PDU Format with SRAP Header". Figure 6 .2.2-1 was reproduced as Figure 10 ]

[0234] Figure 6 .2.2-2 illustrates the format of a U2N SRAP data PDU consisting only of data fields without any SRAP header. This SRAP data PDU format is suitable for U2N SRAP SDUs used for delivery of SRB0 via the PC5 interface.

[0235] The 3GPP TS 38.351V18.2.0 standard is titled "U2N SRAP Data PDU Format without SRAP Header". Figure 6 .2.2-2 was reproduced as Figure 11 ]

[0236] [...]

[0237] 6.3 Parameters

[0238] 6.3.1 General Provisions

[0239] Unless otherwise specified in the definition of each field, the bits in the parameters should be interpreted as follows: the leftmost bit is the first and most significant bit, and the rightmost bit is the last and least significant bit.

[0240] Unless otherwise specified, integers are encoded according to the standard binary encoding used for unsigned integers. In all cases, when read from the PDU, the bits are arranged in order from MSB to LSB.

[0241] 6.3.2 UE ID

[0242] Length: 8 bits.

[0243] In U2N relay mode, this field carries the local identity of the U2N remote UE. In U2U relay mode, there are two UE ID fields: the first carries the local identity of the SRC U2U remote UE, and the second carries the local identity of the DST U2U remote UE.

[0244] 6.3.3 Bearer ID

[0245] Length: 5 characters.

[0246] In U2N relay scenarios, this field carries information identifying the Uu radio bearer used for U2N remote UEs. For SRB, the value is set to the SRB identity (configured by the RRC parameter srb-Identity). For DRB, the value is set to the DRB identity (configured by the RRC parameter drb-Identity) minus 1.

[0247] In the U2U relay case, this field carries information to identify the end-to-end PC5 radio bearer used for the U2U remote UE. For SL-SRB, the value is set to 0 / 1 / 2 / 3 for SL-SRB 0 / 1 / 2 / 3 respectively. For SL-DRB, the value is set to the 5 LSBs of slrb-PC5-ConfigIndex used in the end-to-end SL DRB configuration procedure, as specified in TS 38.331[3].

[0248] 6.3.4 Data

[0249] Length: Variable

[0250] This field carries the SRAP SDU (i.e., PDCP PDU or RRC PDU).

[0251] 6.3.5R

[0252] Length: 1 digit

[0253] Reserved. In this version, the reserved bit should be set to 0. The receiver should ignore the reserved bit.

[0254] 6.3.6D / C

[0255] Length: 1 digit

[0256] This field indicates whether the corresponding SRAP PDU is an SRAP data PDU or an SRAP control PDU (not used in this version).

[0257] Table 6.3.6-1 of 3GPP TS 38.351V18.2.0, named "D / C Field", is reproduced as follows: Figure 12 ]

[0258] 3GPP TS 38.321 specifies the MAC PDU for SL-SCH as follows:

[0259] 6.1.6 MAC PDU (SL-SCH)

[0260] A MAC PDU consists of an SL-SCH subheader and one or more MAC sub-PDUs. Each MAC sub-PDU consists of one of the following:

[0261] - MAC subheader only (including padding);

[0262] -MAC subheader and MAC SDU;

[0263] - MAC subheader and MAC CE;

[0264] -MAC subheader and padding.

[0265] The size of the MAC SDU is variable.

[0266] Each MAC subheader, except for the SL-SCH subheader, corresponds to MAC SDU, MAC CE, or padding.

[0267] The SL-SCH subheader has a fixed size and consists of seven header fields: V / R / R / R / R / SRC / DST.

[0268] The 3GPP TS 38.321V18.2.0 header is named "SL-SCH MAC subheader". Figure 6 .1.6-1 was reproduced as Figure 13 ]

[0269] Besides the fixed-size MAC CE and padding, the MAC subheader consists of four header fields: R / F / LCID / L, such as... Figure 6 .1.2-1 (with an 8-bit L field) and Figure 6 As described in .1.2-2 (with a 16-bit L field). The MAC subheader used for fixed-size MAC CE and padding is as follows: Figure 6 It consists of the two header fields R / LCID described in .1.2-3.

[0270] like Figure 6 As described in .1.6-2, the SL MAC sub-PDU with MAC SDU is placed after the SL-SCH sub-header and before the MAC sub-PDU with MAC CE and the MAC sub-PDU with padding in the MAC PDU. Figure 6 As described in .1.6-2, the SL MAC sub-PDU with MAC CE is placed after all MAC sub-PDUs with MAC SDU and before the MAC sub-PDUs with padding in the MAC PDU. The padding size can be zero.

[0271] The 3GPP TS 38.321V18.2.0 specification is named "An instance of an SL MAC PDU". Figure 6 .1.6-2 was reproduced as Figure 14 ]

[0272] Each MAC entity can transmit a maximum of one MAC PDU per TB.

[0273] [...]

[0274] 6.2.4 MAC subheader for SL-SCH

[0275] The MAC subheader consists of the following fields:

[0276] -V: The MAC PDU format version number field indicates which version of the SL-SCH subheader is used. In the specification for this version, the V field is set to 0. The V field is 4 bits in size;

[0277] -SRC: The SRC field carries the 16 most significant bits of the source layer 2 ID of the identifier provided by the upper layer, as defined in TS23.287

[19] or TS23.304

[26] . This field is 16 bits long;

[0278] -DST: The DST field carries the 8 most significant bits of the destination layer 2 ID set to the identifier provided by the upper layer, as defined in TS23.287

[19] or TS23.304

[26] . This field is 8 bits long;

[0279] -LCID: The Logical Channel ID field identifies the logical channel instance or type of the corresponding MAC CE within the range of a source layer 2 ID and destination layer 2 ID pair for the corresponding MAC SDU or padding, as described in Table 6.2.4-1 for SL-SCH. In addition to the SL-SCH subheader, each MAC subheader contains an LCID field. LCID values ​​from 21 to 36 identify the logical channel from which the replicated RLC SDU is transmitted, with corresponding sequential values ​​from 4 to 19 of the LCID. The LCID field is 6 bits in size.

[0280] -L: The length field indicates the byte length of the corresponding MAC SDU or variable-size MAC CE. In addition to the SL-SCH subheader and the subheader corresponding to a fixed-size MAC CE or padding, there is one L field for each MAC subheader. The size of the L field is indicated by the F field;

[0281] -F: The format field indicates the size of the length field. In addition to the SL-SCH subheader and the subheader corresponding to a fixed-size MAC CE or padding, there is one F field per MAC subheader. The F field is 1 bit in size. A value of 0 indicates an 8-bit length field. A value of 1 indicates a 16-bit length field.

[0282] -R: Reserved bit, set to 0.

[0283] The MAC subheader is octet aligned.

[0284] Table 6.2.4-1 of 3GPP TS 38.321V18.2.0, entitled "Values ​​of LCID for SL-SCH", is reproduced as follows: Figure 15 ]

[0285] Version 18 specifies single-hop UE-to-network (U2N) relay. For single-hop U2N relay, a U2N relay UE can be used to support data communication between the remote UE and the network when the remote UE cannot communicate directly with the network. The U2N relay UE needs to establish a PC5 unicast link (or PC5 RRC connection) with the remote UE and an RRC connection with the network node (e.g., gNB) to support data communication between the remote UE and the network via the U2N relay UE.

[0286] According to 3GPP TR 23.700-03, multi-hop U2N relay will be supported in version 19, and network operators should be able to define the maximum number of hops supported in their networks when using relay UEs. 3GPP TR 23.700-03 Figure 6 Figure 1.1-1 (not shown) illustrates an example architecture for multi-hop UE to network relay, where a 5G ProSe remote UE connects to the NG-RAN via an intermediate U2N relay UE and a 5GProSe U2N relay UE (or an L2 U2N relay UE). As shown in the figure, it is only explicitly stated that the 5G ProSe U2N relay UE needs to be within the coverage area of ​​the NG-RAN and capable of establishing an RRC connection with the NG-RAN to support multi-hop UE to network relay. Other intermediate U2N relay UEs may be within or outside the coverage area.

[0287] 3GPP TS 38.300 Figure 16 .12.2.1-2 (reproduced as) Figure 6 This diagram illustrates the control plane protocol stack for single-hop L2 U2N trunking. It assumes that a PC5 interface will be used between the intermediate U2N trunk UE and the L2 U2N trunk UE to support multi-hop L2 U2N trunking, as follows... Figure 16 As shown.

[0288] 3GPP TS 38.300 Figure 16 .12.5.1-1 (reproduced as) Figure 5This specifies the L2U2N remote UE connection establishment procedure for single-hop L2 U2N relay. During this procedure, the remote UE sends an RRCSetupRequest message to the gNB via the L2 U2N relay UE on SRB0, and receives an RRCSetup message from the gNB via the L2 U2N relay UE on SRB0. As described in section 16.12.2.1 of 3GPP TS 38.300, for messages from L2 U2N remote UEs on SRB0, the SRAP header is not present on the PC5 hop, but the SRAP header is present on the Uu hop for both UL and DL. In the case of multi-hop L2 U2N relay, it is expected that the intermediate U2N relay UE should also forward the RRCSetupRequest message received from the remote UE to the gNB via the L2 U2N relay UE. Since the SRAP header exists on the Uu hop of messages used by L2 U2N remote UEs on SRB0, the Uu-SRAP PDU sent from the L2 U2N relay UE to the gNB should contain the remote UE's local ID (or local remote UE ID), while the PC5-SRAP PDU sent from the remote UE to the intermediate U2N relay UE does not contain the header. Consideration should be given to how to enable the L2 U2N relay UE to include the remote UE's local ID in the Uu-SRAP PDU sent to the gNB.

[0289] There are two potential directions to consider: (1) the SRAP header does not exist on the PC5 hop between the intermediate U2N relay UE and the L2 U2N relay UE, and (2) the SRAP header exists on the PC5 hop between the intermediate U2N relay UE and the L2 U2N relay UE.

[0290] Direction (1): For messages of L2 U2N remote UEs on SRB0, the SRAP header does not exist on the PC5 hop between the intermediate U2N relay UE and the L2 U2N relay UE.

[0291] Similar to the L2 U2N remote UE connection establishment procedure specified in 3GPP TS 38.300 for single-hop L2 U2N relays, a relay discovery procedure and a PC5 connection establishment procedure should be performed between the remote UE, the intermediate U2N relay UE, and the L2U2N relay UE before the remote UE sends the RRCSetupRequest message. This allows the remote UE to discover the intermediate U2N relay UE and the L2 U2N relay UE for connecting to the gNB. Therefore, the remote UE may be aware of the L2 U2N relay UE during the relay discovery procedure or the PC5 connection establishment procedure. For example, information identifying the remote UE (e.g., the remote UE's user information ID or L2 ID) may be included in the relay discovery message or direct communication request message received by the L2 U2N relay UE.

[0292] In this scenario, a feasible limitation is that only one L2 U2N remote UE connection establishment procedure can be executed at a time, allowing the L2 U2N relay UE to assume that the RRCSetupRequest message received from the intermediate U2N relay UE and contained in the PC5 SRAP PDU (without a header) is from a remote UE known from a previous relay discovery procedure or PC5 connection establishment procedure. In this case, the L2 U2N relay UE can include the remote UE's (local) UE ID in the header of the Uu SRAP PDU (carrying the RRCSetupRequest message) sent to the gNB. In one embodiment, the remote UE's (local) UE ID is provided by the gNB (e.g., in response to receiving a sidelink UE information message from the L2 U2N relay UE). The remote UE's (local) UE ID can be included along with the remote UE's L2 ID or user information ID in the RRC reconfiguration message sent from the gNB.

[0293] Similarly, when an intermediate U2N relay UE receives an RRCSetup message (on SRB0) in a PC5 SRAP PDU without a header, the intermediate U2N relay UE can assume that the RRCSetup message is for a remote UE known from a previous relay discovery procedure or PC5 connection establishment procedure, so that the intermediate U2N relay UE can forward the RRCSetup message to the remote UE in a PC5 SRAP PDU without a header, wherein the header of the MAC PDU carrying the PC5 SRAP PDU contains a field identifying the remote UE.

[0294] Direction (2): For messages of L2 U2N remote UEs on SRB0, the SRAP header exists at the PC5 hop between the intermediate U2N relay UE and the L2 U2N relay UE.

[0295] It is possible that the intermediate U2N relay UE obtains the (local) UE ID of the remote UE from the gNB. For example, the (local) UE ID of the remote UE can be provided by the gNB (e.g., in response to receiving a sidelink UE information message from the intermediate U2N relay UE). In one embodiment, the intermediate U2N relay UE can send a sidelink UE information message to the gNB (via the L2 U2N relay UE) after receiving an RRCSetupRequest message from the remote UE on the SRB0, wherein the RRCSetupRequest message is contained in a PC5 SRAP PDU without a header.

[0296] The remote UE's (local) UE ID can be included along with the remote UE's L2 ID or user information ID in the RRC reconfiguration message sent from the gNB (via the L2U2N relay UE), where the remote UE's L2 ID or user information ID may have been known to the intermediate U2N relay UE during the previous relay discovery procedure or PC5 connection establishment procedure. When an RRCSetupRequest message is received on SRB0, the intermediate U2N relay UE can identify the remote UE based on the destination field in the header of the MACPDU carrying a PC5 SRAP PDU without a header. In this case, the intermediate U2N relay UE can subsequently include the remote UE's (local) UE ID in the header of the PC5 SRAP PDU used to send the RRCSetupRequest message to the L2 U2N relay UE. A bearer ID field with '0' may also be included in the header.

[0297] Similarly, when an L2 U2N relay UE receives an RRCSetup message (on SRB0) from a gNB in ​​a Uu SRAP PDU with a header, it can also send the RRCSetup message to an intermediate U2N relay UE in a PC5 SRAP PDU with a header containing the remote UE's (local) UE ID and a bearer ID field with '0'. Subsequently, the intermediate U2N relay UE can forward the RRCSetup message to the remote UE in a PC5 SRAP PDU without a header, where the header of the MACPDU carrying the PC5 SRAP PDU contains a field identifying the remote UE.

[0298] After receiving the RRCSetup message, the remote UE can transmit the RRCSetupComplete message to the gNB on SRB1 via the intermediate U2N relay UE and L2 U2N relay UE, wherein each SRAP PDU carrying the RRCSetupComplete message on all three hops has a header.

[0299] Figure 17 An example of direction (2) based L2U2N remote UE connection establishment for two-hop L2 UE to network relay is shown according to an exemplary embodiment.

[0300] Figure 18 This is flowchart 1300 for an intermediate U2N relay UE. In step 1805, the intermediate U2N relay UE establishes a first PC5 connection with the remote UE and a second PC5 connection with the Layer 2 (L2) U2N relay UE. In step 1810, the intermediate U2N relay UE receives a Radio Resource Control (RRC) setup request message from the remote UE on SRB0, wherein the RRC setup request message is contained in a first PC5 Side Link Relay Adaptation Protocol (SRAP) Protocol Data Unit (PDU) without a header. In step 1815, the intermediate U2N relay UE transmits the RRC setup request message to the L2 U2N relay UE on SRB0, wherein the RRC setup request message is contained in a second PC5 SRAP PDU with a first header, and the first header contains the UE identity (ID) of the remote UE, wherein the UE ID of the remote UE is contained in an RRC reconfiguration message received from the network node.

[0301] In one embodiment, the first PC5 SRAP PDU may be included in a Media Access Control (MAC) PDU, and the header of the MAC PDU may include a field identifying the remote UE.

[0302] In one embodiment, an intermediate U2N relay UE can receive an RRC setup message from an L2 U2N relay UE on SRB0, wherein the RRC setup message is contained in a third PC5 SRAP PDU having a second header, and the second header may contain the UE ID of the remote UE. According to the method of claim 3, wherein the first header or the second header may further contain a bearer ID of "0".

[0303] In one embodiment, an intermediate U2N relay UE can transmit an RRC setup message to a remote UE on SRB0, wherein the RRC setup message is contained in a fourth PC5 SRAP PDU without a header. The intermediate U2N relay UE can receive an RRC setup complete message from the remote UE on SRB1, wherein the RRC setup complete message is contained in a fifth PC5 SRAP PDU with a third header, and the third header contains the UE ID of the remote UE. The intermediate U2N relay UE can transmit an RRC setup complete message to an L2 U2N relay UE on SRB1, wherein the RRC setup complete message is contained in a sixth PC5 SRAP PDU with a fourth header, and the fourth header contains the UE ID of the remote UE. The third or fourth header may further contain a bearer ID of "1".

[0304] In one embodiment, the intermediate U2N relay UE can transmit a sidelink UE information message to the network node after receiving an RRC setup request message from the remote UE. It can also receive an RRC reconfiguration message from the network node after transmitting the sidelink UE information message to the network node.

[0305] Return to reference Figure 3 and Figure 4 In an exemplary embodiment from the perspective of the UE, the UE 300 includes program code 312 stored in memory 310. The CPU 308 can execute program code 312 to enable the intermediate U2N relay UE to (i)..., (ii)..., and (ii)... Furthermore, the CPU 308 can execute program code 312 to perform all the foregoing actions and steps or other actions and steps described herein.

[0306] Various aspects of this disclosure have been described above. It should be understood that the teachings herein can be implemented in a wide variety of forms, and any specific structure, function, or both disclosed herein are merely representative. Based on the teachings herein, those skilled in the art will understand that the aspects disclosed herein can be implemented independently of any other aspects, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement an apparatus or practice. Furthermore, such apparatuses or practices can be implemented using structures, functions, or structures and functions other than or different from those set forth herein. As examples of some of the foregoing concepts, in some aspects, a parallel channel can be established based on the pulse repetition frequency. In some aspects, a parallel channel can be established based on the pulse position or offset. In some aspects, a parallel channel can be established based on a time jump sequence. In some aspects, a parallel channel can be established based on the pulse repetition frequency, the pulse position or offset, and the time jump sequence.

[0307] Those skilled in the art will understand that information and signals can be represented using any of a variety of different techniques and skills. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles, or any combination thereof.

[0308] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, processors, components, circuits, and algorithm steps described in conjunction with the aspects disclosed herein can be implemented as electronic hardware (e.g., digital implementations, analog implementations, or a combination of both, which may be designed using source decoding or some other technique) and have instructions in various forms of program or design code (which, for convenience, may be referred to herein as "software" or "software module"), or a combination of both. To clearly illustrate the interchangeability of hardware and software, the various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as a departure from the scope of this disclosure.

[0309] Furthermore, the various illustrative logic blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented within or executed by an integrated circuit (“IC”), access terminal, or access point. An IC may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electrical components, optical components, mechanical components, or any combination thereof designed to perform the functions described herein, and may execute code or instructions residing within the IC, outside the IC, or both. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration.

[0310] It should be understood that any particular order or hierarchy of steps in any disclosed process is an instance of a sample method. It should be understood that the specific order or hierarchy of steps in a process can be rearranged based on design preferences, while remaining within the scope of this disclosure. The appended method claims present the elements of the various steps in a sample order and are not intended to be limited to any particular order or hierarchy presented.

[0311] The steps of the methods or algorithms described in conjunction with the aspects disclosed herein can be implemented directly in hardware, with software modules executed by a processor, or a combination of both. Software modules (e.g., containing executable instructions and associated data) and other data can reside in data memory, such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of computer-readable storage medium known in the art. The sample storage medium can be coupled to a machine such as a computer / processor (for convenience, this machine may be referred to herein as a "processor"), such that the processor can read information (e.g., code) from the storage medium and write information to the storage medium. The sample storage medium can be integrated with the processor. The processor and storage medium can reside in an ASIC. The ASIC can reside in a user equipment. Alternatively, the processor and storage medium can reside as discrete components in a user equipment. Furthermore, in some aspects, any suitable computer program product may include a computer-readable medium comprising code associated with one or more aspects of this disclosure. In some respects, computer program products may include packaging materials.

[0312] While the invention has been described in conjunction with various aspects, it should be understood that further modifications are possible. This application is intended to cover any changes, uses, or adaptations to the invention that generally follow the principles of the invention and include such deviations from this disclosure that fall within the scope of known and customary practice in the art to which this invention pertains.

Claims

1. A method for intermediate UE-to-network (U2N) relay user equipment (UE), comprising: The intermediate U2N relay UE establishes a first PC5 connection with the remote UE and a second PC5 connection with the layer 2 (L2) U2N relay UE; The intermediate U2N relay UE receives a Radio Resource Control (RRC) setup request message from the remote UE on SRB0, wherein the RRC setup request message is contained in a first PC5 Sidelink Relay Adaptation Protocol (SRAP) Protocol Data Unit (PDU) without a header; and The intermediate U2N relay UE transmits the RRC setup request message to the L2 U2N relay UE on SRB0, wherein the RRC setup request message is contained in a second PC5 SRAP PDU with a first header and the first header contains the UE identity (ID) of the remote UE, and wherein the UE ID of the remote UE is contained in the RRC reconfiguration message received by the intermediate U2N relay UE from the network node.

2. The method according to claim 1, wherein, The first PC5 SRAP PDU is contained in a Media Access Control (MAC) PDU, and the header of the MAC PDU contains a field that identifies the remote UE.

3. The method according to claim 1, further comprising: The intermediate U2N relay UE receives an RRC setting message from the L2 U2N relay UE on SRB0, wherein the RRC setting message is contained in a third PC5 SRAP PDU having a second header and the second header containing the UE ID of the remote UE.

4. The method according to claim 3, wherein, The first header or the second header also contains a BEARER ID of "0".

5. The method according to claim 3, further comprising: The intermediate U2N relay UE transmits the RRC setting message to the remote UE on SRB0, wherein the RRC setting message is contained in a fourth PC5 SRAP PDU without a header.

6. The method according to claim 5, further comprising: The intermediate U2N relay UE receives an RRC setup complete message from the remote UE on SRB1, wherein the RRC setup complete message is contained in a fifth PC5 SRAP PDU with a third header and the third header contains the UE ID of the remote UE.

7. The method according to claim 6, further comprising: The intermediate U2N relay UE transmits the RRC setup complete message to the L2 U2N relay UE on SRB1, wherein the RRC setup complete message is contained in a sixth PC5 SRAP PDU with a fourth header and the fourth header contains the UE ID of the remote UE.

8. The method according to claim 7, wherein, The third header or the fourth header also contains a BEARER ID of "1".

9. The method according to claim 1, wherein, The method further includes: After receiving the RRC setting request message from the remote UE, the intermediate U2N relay UE transmits the sidelink UE information message to the network node.

10. The method according to claim 9, wherein, After the sidelink UE information message is transmitted to the network node, the RRC reconfiguration message is received from the network node.

11. An intermediate user equipment to network (U2N) relay user equipment (UE), comprising: Control circuit; A processor, which is installed in the control circuit; A memory, which is mounted in the control circuit and coupled to the processor; The processor is configured to execute program code stored in the memory to: Establish a first PC5 connection with a remote UE and a second PC5 connection with a Layer 2 (L2) U2N relay UE; On SRB0, a Radio Resource Control (RRC) Setting Request message is received from the remote UE, wherein the RRC Setting Request message is contained in a first PC5 Side Link Relay Adaptation Protocol (SRAP) Protocol Data Unit (PDU) without a header; as well as The RRC setup request message is transmitted on SRB0 to the L2 U2N relay UE, wherein the RRC setup request message is contained in a second PC5 SRAP PDU having a first header and the first header contains the UE identity (ID) of the remote UE, and wherein the UE ID of the remote UE is contained in the RRC reconfiguration message received by the intermediate U2N relay UE from the network node.

12. The intermediate U2N relay UE according to claim 11, wherein, The first PC5 SRAP PDU is contained in a Media Access Control Protocol Data Unit (MAC) PDU, and the header of the MAC PDU contains a field that identifies the remote UE.

13. The intermediate U2N relay UE according to claim 11, wherein, The processor is also configured to execute program code stored in the memory to: On SRB0, an RRC setting message is received from the L2 U2N relay UE, wherein the RRC setting message is contained in a third PC5 SRAP PDU having a second header and the second header containing the UE ID of the remote UE.

14. The intermediate U2N relay UE according to claim 13, wherein, The first header or the second header also contains a bearer ID of "0".

15. The intermediate U2N relay UE according to claim 13, wherein, The processor is also configured to execute program code stored in the memory to: The RRC setting message is transmitted to the remote UE on SRB0, wherein the RRC setting message is contained in a fourth PC5 SRAP PDU without a header.

16. The intermediate U2N relay UE according to claim 15, wherein, The processor is also configured to execute program code stored in the memory to: On SRB1, an RRC setup completion message is received from the remote UE, wherein the RRC setup completion message is contained in a fifth PC5 SRAP PDU having a third header and the third header containing the UE ID of the remote UE.

17. The intermediate U2N relay UE according to claim 16, wherein, The processor is also configured to execute program code stored in the memory to: The RRC setup complete message is transmitted on SRB1 to the L2 U2N relay UE, wherein the RRC setup complete message is contained in a sixth PC5 SRAP PDU with a fourth header and the fourth header contains the UEID of the remote UE.

18. The intermediate U2N relay UE according to claim 17, wherein, The third header or the fourth header also contains a BEARER ID of "1".

19. The intermediate U2N relay UE according to claim 11, wherein, The processor is also configured to execute program code stored in the memory to: After receiving the RRC setting request message from the remote UE, the sidelink UE information message is transmitted to the network node.

20. The intermediate U2N relay UE according to claim 19, wherein, The RRC reconfiguration message is received from the network node after the sidelink UE information message is transmitted to the network node.

Images