Method and device for supporting user equipment to network relay communication in wireless communication system

Abstract

The present invention discloses a method and apparatus for relaying user equipment. The relay user equipment is connected to a remote user equipment or serves the remote user equipment for relay communication with a network node. The relay user equipment receives a message from the remote user equipment on a PC5 radio link control channel, wherein the PC5 radio link control channel is associated with a Uu SRB1 of the remote user equipment or a Uu signaling radio bearer used by the remote user equipment to transmit radio resource control signaling under RRC_CONNECTED. In response to receiving a message on the PC5 radio link control channel or when data is available for transmission from the relay user equipment to the network node on a Uu radio link control channel associated with a Uu SRB1 of the remote user equipment or a Uu signaling radio bearer used by the remote user equipment to transmit radio resource control signaling under RRC_CONNECTED, the relay user equipment and the network node initiate or perform a radio resource control connection recovery procedure.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application Nos. 63 / 127,884 and 63 / 127,904, filed on December 18, 2020, the entire disclosures of which are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure relates generally to wireless communication networks, and more particularly, to a method and apparatus for supporting UE-to-network relay communications in a wireless communication system. Background Art

[0004] With the rapid growth of the demand for transmitting large amounts of data to and from mobile communication devices, traditional mobile voice communication networks have evolved into networks with Internet Protocol (IP) packet communications, which can provide IP-based voice, multimedia, multicast and on-demand communication services to users of mobile communication devices.

[0005] An exemplary network structure is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The E-UTRAN system can provide high data throughput to enable the above-mentioned IP-borne voice and multimedia services. Currently, the 3rd Generation Partnership Project (3GPP) standards organization is discussing new radio technologies for the next generation (e.g., 5G). Therefore, changes to the current body of 3GPP standards are currently being submitted and considered to evolve and finalize the 3GPP standards. Summary of the invention

[0006] The present invention discloses a method and apparatus for relaying user equipment (UE). In one embodiment, the relay UE is connected to a remote UE or serves the remote UE for relay communication with a network node. In addition, the relay UE receives a message from the remote UE on a PC5 radio link control (RLC) channel, wherein the PC5RLC channel is associated with the Uu SRB1 of the remote UE or the Uu signaling radio bearer (SRB) used by the remote UE to transmit the radio resource control (RRC) signaling under RRC_CONNECTED. And, in response to receiving a message on the PC5 RLC channel or when data is available for transmission from the relay UE to the network node on a Uu RLC channel associated with the Uu SRB1 of the remote UE or the Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED, the relay UE and the network node initiate or perform an RRC connection recovery procedure. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0008] Figure 2 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 is a functional block diagram of a communication system according to an exemplary embodiment.

[0010] Figure 4 According to an exemplary embodiment Figure 3 Functional block diagram of the program code.

[0011] Figure 5 For 3GPP TS 38.331 V16.2.0 Figure 5 .Reproduction of 3.3.1-1.

[0012] Figure 6 For 3GPP TS 38.331 V16.2.0 Figure 5 .Reproduction of 3.5.1-1.

[0013] Figure 7 For 3GPP TS 38.331 V16.2.0 Figure 5 .Reproduction of 3.8.1-1.

[0014] Figure 8For 3GPP TS 38.331 V16.2.0 Figure 5 .Reproduction of 3.13.1-1.

[0015] Fig. 9 For 3GPP TS 38.331 V16.2.0 Figure 5 .Reproduction of 3.13.1-4.

[0016] Fig.10 For 3GPP TR 23.752 V0.5.1 Figure 6 .7.2.6-1 reappearance.

[0017] Fig.11 For 3GPP TR 23.752 V0.5.1 Figure 6 .7.2.6-2 reappearance.

[0018] Fig.12 For 3GPP TR 23.752 V0.5.1 Figure 6 .7.3-1 reappearance.

[0019] Fig.13 For 3GPP TR 38.836 V1.0.0 Figure 4 .Reproduction of 1-1.

[0020] Fig.14 For 3GPP TR 38.836 V1.0.0 Figure 4 .Reproduction of 5.1.1-1.

[0021] Fig.15 For 3GPP TR 38.836 V1.0.0 Figure 4 .Reproduction of 5.1.1-2.

[0022] Fig.16 For 3GPP TR 38.836 V1.0.0 Figure 4 .Reproduction of 5.1.1-3.

[0023] Fig.17 For 3GPP TR 38.836 V1.0.0 Figure 4 .Reproduction of 5.1.1-4.

[0024] Fig.18 For 3GPP TR 38.836 V1.0.0 Figure 4 .Reproduction of 5.5.1-1.

[0025] Fig.19 For 3GPP TS 23.287 V16.4.0 Figure 6.Reproduction of 3.3.1-1.

[0026] Fig. 20 An example of a protocol stack for layer 2 UE-to-network relay according to an exemplary embodiment is shown.

[0027] Fig.21 An example of association between the Uu SRB, the PC5 RLC channel and the Uu RLC channel according to an exemplary embodiment is shown.

[0028] Fig. 22 An exemplary flow chart of a UE performing a RA procedure for RRC state transition based on 3GPP TS 38.321 and TS 38.331 according to an exemplary embodiment is shown.

[0029] Fig.23 An exemplary flow chart showing a relay UE performing a RA procedure for entering RRC_CONNECTED in response to a remote UE entering RRC_CONNECTED according to an exemplary embodiment.

[0030] Fig.24 is a flow chart according to an exemplary embodiment.

[0031] Fig.25 is a flow chart according to an exemplary embodiment. DETAILED DESCRIPTION

[0032] The exemplary wireless communication systems and devices described below employ wireless communication systems to support broadcast services. Wireless communication systems are widely deployed to provide various types of communications such as voice, data, etc. These systems can 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 or Advanced LTE), 3GPP2 Ultra Mobile Broadband (UMB), WiMax, 3GPP New Radio (NR), or some other modulation technology.

[0033] Specifically, the exemplary wireless communication systems and devices described below may be designed to support one or more standards, such as those provided by a consortium named "3rd Generation Partnership Project" referred to herein as 3GPP, including: TS 38.331 V16.2.0, "NR; Radio Resource Control (RRC) Protocol Specification (Release 16)"; TS 38.300 V16.1.0, "NR; NR and NG-RAN Overall Description; Stage 2 (Release 16)"; TR 23.752 V0.5.1, "Study of System Enhancements for Proximity-based Services (ProSe) in 5G Systems (5GS) (Release 17)"; TS 38.321 V16.2.1, "NR Medium Access Control (MAC) Protocol Specification (Release 16)"; TR 38.836 V0.2.0, "Study of NR Sidelink Relay; (Release 17)" and TS 23.287 V16.4.0, “Architecture Enhancements for 5G System (5GS) Supporting Vehicle-to-Everything (V2X) Services (Release 16)”. The standards and documents listed above are expressly incorporated herein by reference in their entirety.

[0034] Figure 1 A multiple access wireless communication system according to one embodiment of the present invention is shown. Access network 100 (AN) includes multiple antenna groups, one group includes 104 and 106, another group includes 108 and 110, and an additional group includes 112 and 114. Figure 1 , only two antennas are shown for each antenna group, however, each antenna group may utilize more or fewer antennas. 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 a frequency division duplex (FDD) system, communication links 118, 120, 124, and 126 may use different frequencies for communication. For example, the frequency used by forward link 120 may be different from the frequency used by reverse link 118.

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

[0036] When communicating via forward links 120 and 126, the transmit antennas of access network 100 may utilize beamforming to improve the signal-to-noise ratio of the forward links for the different access terminals 116 and 122. Also, an access network's use of beamforming to transmit to access terminals randomly dispersed within its coverage area may cause less interference to access terminals in neighboring cells than if the access network transmitted to all of its access terminals via a single antenna.

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

[0038] Figure 2 A simplified block diagram of an embodiment of a transmitter system 210 (also referred to as an access network) and a receiver system 250 (also referred to as an access terminal (AT) or user equipment (UE)) in a multiple-input multi-output (MIMO) system 200. At the transmitter system 210, traffic data for a plurality of data streams is provided from a data source 212 to a transmit (TX) data processor 214.

[0039] In one embodiment, each data stream is transmitted via a respective transmit antenna.TX data processor 214 formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data.

[0040] The coded data for each data stream may be multiplexed with pilot data using Orthogonal Frequency Division Multiplexing (OFDM) techniques. The pilot data is typically a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream is then modulated (i.e., symbol mapped) based on a particular modulation scheme selected for that data stream (e.g., Binary Phase Shift Keying (BPSK), Quadrature Phase Shift Keying (QPSK), Multiple Phase Shift Keying (M-PSK), or Quadrature Amplitude Modulation (M-QAM)) to provide modulation symbols. The data rate, coding, and modulation for each data stream may be determined by instructions executed by processor 230.

[0041] The modulation symbols for all data streams are then provided to a TX MIMO processor 220, which may further process the modulation symbols (e.g., for OFDM). T The modulation symbol streams are provided to N T transmitters (TMTR) 222a through 222t. In certain embodiments, TX MIMO processor 220 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

[0042] Each transmitter 222 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. T The antennas 224a to 224t transmit the N signals from the transmitters 222a to 222t. T a modulated signal.

[0043] At the receiver system 250, N R The transmitted modulated signals are received by each antenna 252a through 252r and the received signal from each antenna 252 is provided to a respective receiver (RCVR) 254a through 254r. Each receiver 254 conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the conditioned signal to obtain samples, and further processes the samples to obtain a corresponding “received” symbol stream.

[0044] The RX data processor 260 then receives and processes the N R The N received by the receiver 254 R symbol streams to obtain N T The RX data processor 260 then demodulates, deinterleaves, and decodes each detected symbol stream to recover the traffic data for the data stream. The processing by the RX data processor 260 is complementary to the processing performed by the TX MIMO processor 220 and the TX data processor 214 at the transmitter system 210.

[0045] Processor 270 periodically determines which pre-coding matrix to use (discussed below). Processor 270 formulates a reverse link message comprising a matrix index portion and a rank value portion.

[0046] 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 traffic data for a plurality of data streams from the data source 236, modulated by the modulator 280, conditioned by the transmitters 254a to 254r, and transmitted back to the transmitter system 210.

[0047] At the transmitter system 210, the modulated signals from the receiver system 250 are received by the antenna 224, conditioned by the receiver 222, demodulated by the demodulator 240, and processed by the RX data processor 242 to extract the reverse link message transmitted by the receiver system 250. The processor 230 then determines which precoding matrix to use to determine the beamforming weights and then processes the extracted message.

[0048] Steering Figure 3 , this figure shows an alternative simplified functional block diagram of a communication device according to one embodiment of the present invention. Figure 3 As shown, the communication device 300 in the wireless communication system can be used to implement Figure 1 UE (or AT) 116 and 122 in or Figure 1The base station (or AN) 100 in 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, a program code 312 and a transceiver 314. The control circuit 306 executes the program code 312 in the memory 310 through the CPU 308, thereby controlling the operation of the communication device 300. The communication device 300 can receive signals input by the user through the input device 302 (such as a keyboard or a keypad), and can output images and sounds through the output device 304 (such as a display or a speaker). The transceiver 314 is used to receive and transmit wireless signals, pass the received signals to the control circuit 306, and wirelessly output the signals generated by the control circuit 306. The communication device 300 in the wireless communication system can also be used to implement Figure 1 AN 100 in.

[0049] Figure 4 According to one embodiment of the present invention, Figure 3 4. In this embodiment, program code 312 includes application layer 400, layer 3 portion 402, and layer 2 portion 404, and is coupled to 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 connectivity.

[0050] 3GPP TS 38.331 introduces the following:

[0051] 5.3.3RRC Connection Establishment

[0052] 5.3.3.1 Overview

[0053] [3GPP TS 38.331 V16.2.0 titled "RRC Connection Establishment Successful" Figure 5 .3.3.1-1 Reproduced as Figure 5 ]

[0054] […]

[0055] The purpose of this procedure is to establish an RRC connection. RRC connection establishment involves SRB1 establishment. The procedure is also used to transfer initial NAS dedicated information / messages from the UE to the network.

[0056] For example, the following network applications:

[0057] -When an RRC connection is established;

[0058] -When the UE is resuming or re-establishing an RRC connection and the network is unable to retrieve or verify the UE context. In this case, the UE receives RRCSetup and responds with RRCSetupComplete.

[0059] 5.3.3.1a Conditions for establishing an RRC connection for sidelink communication

[0060] For NR sidelink communications, RRC connection establishment is initiated only in the following cases:

[0061] 1> If configured by upper layers to transmit NR sidelink communications and relevant data is available for transmission, then:

[0062] 2> If the frequency configured by the UE for transmitting NR sidelink communications is contained in the sl-FreqInfoList within the SIB12 provided by the cell in which the UE resides; and if the valid version of SIB12 does not contain sl-TxPoolSelectedNormal for the frequency of interest;

[0063] For V2X sidelink communication, an RRC connection is initiated only when the conditions for V2X sidelink communication in subclause 5.3.3.1a of TS 36.331

[10] are met.

[0064] Note: Upper layers initiate the RRC connection. Interaction with NAS depends on the UE implementation.

[0065] 5.3.3.2 Initiation

[0066] The UE initiates the procedure when upper layers request establishment of an RRC connection while the UE is in RRC_IDLE and it has acquired basic system information as described in 5.2.2.1, or for sidelink communication as specified in subclause 5.3.3.1a.

[0067] Before initiating this procedure, the UE shall ensure that it has valid and up-to-date basic system information as specified in clause 5.2.2.2.

[0068] After initiating the procedure, the UE shall:

[0069] 1> If the upper layer provides an access category and one or more access identifiers when requesting to establish an RRC connection, then:

[0070] 2> Use the access category and access identifier provided by the upper layer to implement the unified access control procedures specified in 5.3.14;

[0071] 3> If the access attempt is blocked, the procedure ends;

[0072] 1> As specified in the corresponding physical layer specification, the preset L1 parameter values ​​apply, except for parameters whose values ​​are provided in SIB1;

[0073] 1> As specified in 9.2.2, the preset MAC cell group configuration is applied;

[0074] 1> Apply CCCH configuration as specified in 9.1.1.2;

[0075] 1> Apply timeAlignmentTimerCommon contained in SIB1;

[0076] 1>Start timer T300;

[0077] 1> Initiate the transmission of RRCSetupRequest message according to 5.3.3.3;

[0078] 5.3.3.3 Actions related to the transmission of the RRCSetupRequest message

[0079] The UE shall set the content of the RRCSetupRequest message as follows:

[0080] 1>Set ue-Identity as follows:

[0081] 2> If the upper layer provides 5G-S-TMSI, then:

[0082] 3> Set ue-Identity to ng-5G-S-TMSI-Part1;

[0083] 2> Otherwise:

[0084] 3> Extraction range 0..2 39 -1 and set ue-Identity to this value;

[0085] NOTE 1: If the UE is registered in the TA of the current cell, the upper layers provide the 5G-S-TMSI.

[0086] 1>Set establishmentCause based on the information received from the upper layer;

[0087] The UE shall submit an RRCSetupRequest message to lower layers for transmission.

[0088] The UE shall continue to perform cell reselection related measurements and cell reselection evaluation. If the conditions for cell reselection are met, the UE shall perform cell reselection as specified in 5.3.3.6.

[0089] 5.3.3.4 Receiving RRCSetup via UE

[0090] The UE shall perform the following actions immediately after receiving RRCSetup:

[0091] 1> if RRCSetup is received in response to RRCReestablishmentRequest; or

[0092] 1> If RRCSetup is received in response to RRCResumeRequest or RRCResumeRequest1, then:

[0093] 2> discard any stored UE inactive AS context and suspendConfig;

[0094] 2>Discard any current AS security context, including K RRCenc Key, K RRCint Key, K UPint Key and K UPenc Key;

[0095] 2> Release the radio resources for all established RBs except SRB0, including the release of the RLC entity, the associated PDCP entity and the SDAP;

[0096] 2> Release the RRC configuration, except for the preset L1 parameter value, preset MAC cell group configuration and CCCH configuration;

[0097] 2>Indicate the fallback of RRC connection to the upper layer;

[0098] 2> If it is running, stop timer T380;

[0099] 1> Perform the cell group configuration procedure according to the received masterCellGroup and as specified in 5.3.5.5;

[0100] 1> Perform the radio bearer configuration procedure according to the received radioBearerConfig and as specified in 5.3.5.6;

[0101] 1> If stored, discard the cell reselection priority information provided by cellReselectionPriorities or inherited from another RAT;

[0102] 1> If it is running, stop timer T300, T301 or T319;

[0103] 1> If T390 is running, then:

[0104] 2> Stop timer T390 for all access categories;

[0105] 2> Perform the actions specified in 5.3.14.4;

[0106] 1> If T302 is running, then:

[0107] 2> Stop timer T302;

[0108] 2> Perform the actions specified in 5.3.14.4;

[0109] 1> If it is running, stop timer T320;

[0110] 1> If RRCSetup is received in response to RRCResumeRequest, RRCResumeRequest1, or RRCSetupRequest, then:

[0111] 2> If T331 is running, then:

[0112] 3> Stop timer T331;

[0113] 3>Perform the actions specified in 5.7.8.3;

[0114] 2> Enter RRC_CONNECTED;

[0115] 2> Stop the cell reselection procedure;

[0116] 1> Treat the current cell as PCell;

[0117] 1> Set the content of the RRCSetupComplete message as follows:

[0118] 2> If the upper layer provides 5G-S-TMSI:

[0119] 3> If RRCSetup is received in response to RRCSetupRequest:

[0120] 4> Set ng-5G-S-TMSI-Value to ng-5G-S-TMSI-Part2;

[0121] 3> Otherwise:

[0122] 4>Set ng-5G-S-TMSI-Value to ng-5G-S-TMSI;

[0123] 2> set selectedPLMN-Identity to the PLMN or SNPN selected by the upper layer (TS 24.501

[23] ) from the PLMNs contained in the plmn-IdentityList or the PLMN or SNPN contained in the npn-IdentityInfoList in SIB1;

[0124] 2> If the upper layer provides 'Registered AMF', then:

[0125] 3> Include and set registeredAMF as follows:

[0126] 4> If the PLMN identity of the 'registered AMF' is different from the PLMN selected by upper layers, then:

[0127] 5> Include plmnIdentity in registeredAMF and set it to the value of the PLMN identity in the 'registeredAMF' received from the upper layer;

[0128] 4> Set amf-Identifier to the value received from the upper layer;

[0129] 3> Include and set guami-Type to the value provided by the upper layer;

[0130] 2> If the upper layer provides one or more S-NSSAIs (see TS 23.003

[21] ), then:

[0131] 3> Include s-NSSAI-List and set the content to the value provided by the upper layer;

[0132] 2> Set dedicatedNAS-Message to contain the information received from the upper layer;

[0133] 2> If connected as an IAB-node, then:

[0134] 3>Contains iab-NodeIndication;

[0135] 2> if SIB1 contains idleModeMeasurementsNR and the UE has NR idle / inactive measurement information for cells other than PCell available in VarMeasIdleReport; or

[0136] 2> If SIB1 contains idleModeMeasurementsEUTRA and the UE has E-UTRA idle / inactive measurement information available in VarMeasIdleReport, then:

[0137] 3> Include idleMeasAvailable;

[0138] 2> If the UE has logged measurements available for NR and if the RPLMN is contained in the plmn-IdentityList stored in the VarLogMeasReport, then:

[0139] 3> Include logMeasAvailable in the RRCSetupComplete message;

[0140] 2> If the UE has available Bluetooth logged measurements and if the RPLMN is contained in the plmn-IdentityList stored in the VarLogMeasReport, then:

[0141] 3> Include logMeasAvailableBT in the RRCSetupComplete message;

[0142] 2> If the UE has available WLAN logged measurements and if the RPLMN is contained in the plmn-IdentityList stored in the VarLogMeasReport, then:

[0143] 3> Include logMeasAvailableWLAN in the RRCSetupComplete message;

[0144] 2> If the UE has connection establishment failure or connection recovery failure information available in VarConnEstFailReport and if RPLMN is equal to the plmn-Identity stored in VarConnEstFailReport, then:

[0145] 3> Include connEstFailInfoAvailable in the RRCSetupComplete message;

[0146] 2> If the UE has radio link failure or handover failure information available in the VarRLF-Report and if the RPLMN is contained in the plmn-IdentityList stored in the VarRLF-Report, then:

[0147] 3> If reconnectCellId in VarRLF-Report is not set, then:

[0148] 4> Set timeUntilReconnection in VarRLF-Report to the time that has passed since the last radio link or handover failure;

[0149] 4> Set nrReconnectCellId in reconnectCellId in VarRLF-Report to the global cell identity tracking area code of PCell;

[0150] 3> Include rlf-InfoAvailable in the RRCSetupComplete message;

[0151] 2> If the UE supports RLF reporting for inter-RAT MRO NR as defined in TS 36.306

[62] and if the UE has radio link failure or handover failure information available in VarRLF-Report of TS 36.331

[10] , then:

[0152] 3> If the reconnectCellId in the VarRLF-Report of TS 36.331

[10] is not set, then:

[0153] 4> Set timeUntilReconnection in VarRLF-Report of TS 36.331

[10] to the time elapsed since the last radio link or handover failure in LTE;

[0154] 4> Set nrReconnectCellId in reconnectCellId in VarRLF-Report of TS 36.331

[10] to the global cell identity and tracking area code of PCell;

[0155] 3> If the UE is capable of inter-RAT RLF reporting and if the RPLMN is contained in the plmn-IdentityList stored in the VarRLF-Report of TS 36.331

[10] , then

[0156] 4> Include rlf-InfoAvailable in the RRCSetupComplete message;

[0157] 2> If the UE supports storage of mobility history information and the UE has mobility history information available in VarMobilityHistoryReport, then:

[0158] 3> Include mobilityHistoryAvail in the RRCSetupComplete message;

[0159] 2> If RRCSetup is received in response to RRCResumeRequest, RRCResumeRequest1, or RRCSetupRequest, then:

[0160] 3> If speedStateReselectionPars is configured in SIB2:

[0161] 4> Include mobilityState in the RRCSetupComplete message and set it to the UE's mobility state immediately before entering the RRC_CONNECTED state (as specified in TS 38.304

[20]

[0162] Specified in );

[0163] 1> Submit the RRCSetupComplete message to the lower layer for transmission, after which the procedure ends immediately.

[0164] […]

[0165] 5.3.5RRC Reconfiguration

[0166] 5.3.5.1 Overview

[0167] [3GPP TS 38.331 V16.2.0 titled "RRC reconfiguration successful" Figure 5 .3.5.1-1 Reproduced as Figure 6 ]

[0168] […]

[0169] 5.3.8RRC Connection Release

[0170] 5.3.8.1 Overview

[0171] [3GPP TS 38.331 V16.2.0 titled "RRC Connection Release Successful" Figure 5 .3.8.1-1 Reproduced as Figure 7 ]

[0172] The purpose of this program is to:

[0173] - Release the RRC connection, which includes the release of established radio bearers and all radio resources; or

[0174] - Suspend the RRC connection only on SRB2 setup of SRB2 and at least one DRB or IAB, which includes suspension of established radio bearers.

[0175] 5.3.8.2 Initiation

[0176] The network initiates the RRC connection release procedure to transition a UE in RRC_CONNECTED to RRC_IDLE; or transition a UE in RRC_CONNECTED to RRC_INACTIVE only when SRB2 and at least one DRB or IAB's SRB2 are set in RRC_CONNECTED; or transition a UE in RRC_INACTIVE back to RRC_INACTIVE when the UE attempts to recover; or transition a UE in RRC_INACTIVE to RRC_IDLE when the UE attempts to recover. The procedure can also be used to release and redirect the UE to another frequency.

[0177] 5.3.8.3 Receiving RRCRelease via UE

[0178] UE will:

[0179] 1> Delay the following actions defined in this subclause by 60ms from the moment the RRCRelease message is received or the moment when the lower layer indicates that it has successfully confirmed receipt of the RRCRelease message (the earlier of the two cases);

[0180] 1> If it is running, stop timer T380;

[0181] 1> If it is running, stop timer T320;

[0182] 1> If timer T316 is running, then;

[0183] 2> Stop timer T316;

[0184] 2> Clear the information contained in VarRLF-Report (if any);

[0185] 1> If it is running, stop timer T350;

[0186] 1> If AS security is not activated, then:

[0187] 2> Ignore any fields except waitTime contained in the RRCRelease message;

[0188] 2> Perform actions after entering RRC_IDLE as specified in 5.3.11, where the release cause is 'other', after which the procedure ends;

[0189] 1> If the RRCRelease message contains redirectedCarrierInfo indicating redirection to eutra:

[0190] 2> If cnType is included, then:

[0191] 3> After cell selection, indicate the available CN types and received cnType to the upper layer;

[0192] NOTE 1: If the E-UTRA cell selected after redirection does not support the core network type specified by cnType, the situation handling depends on the UE implementation.

[0193] 2> If voiceFallbackIndication is included, then:

[0194] 3> Treat RRC connection release as EPS fallback for IMS voice (see TS 23.502

[43] );

[0195] 1> If the RRCRelease message contains cellReselectionPriorities, then:

[0196] 2>Store the cell reselection priority information provided by cellReselectionPriorities;

[0197] 2> If t320 is included, then:

[0198] 3>Start timer T320, where the timer value is set according to the value of t320;

[0199] 1> Otherwise:

[0200] 2> Apply the cell reselection priority information broadcast in the system information;

[0201] 1> If deprioritisationReq is included, then:

[0202] 2> Start or restart timer T325, where the timer value is set to the transmitted deprioritisationTimer;

[0203] 2>Store deprioritisationReq until T325 expires;

[0204] 1> If RRCRelease contains measIdleConfig:

[0205] 2> If T331 is running, then:

[0206] 3> Stop timer T331;

[0207] 3>Perform the actions specified in 5.7.8.3;

[0208] 2>If measIdleConfig is set to settings, then:

[0209] 3>Store the received measIdleDuration in VarMeasIdleConfig;

[0210] 3>Start timer T331, where the value is set to measIdleDuration;

[0211] 3>If measIdleConfig contains measIdleCarrierListNR, then:

[0212] 4>Store the received measIdleCarrierListNR in VarMeasIdleConfig;

[0213] 3>If measIdleConfig contains measIdleCarrierListEUTRA, then:

[0214] 4>Store the received measIdleCarrierListEUTRA in VarMeasIdleConfig;

[0215] 3>If measIdleConfig contains validityAreaList, then:

[0216] 4>Store the received validityAreaList in VarMeasIdleConfig;

[0217] 1> If RRCRelease contains suspendConfig, then:

[0218] 2> The suspendConfig received by the application;

[0219] 2> Remove all entries in VarConditionalReconfig, if they exist;

[0220] 2>For each measId, if the associated reportConfig has reportType set to condTriggerConfig, then:

[0221] 3>For the associated reportConfigId:

[0222] 4> Remove the entry with matching reportConfigId from reportConfigList in VarMeasConfig;

[0223] 3> If the associated measObjectId is associated only with a reportConfig that has a reportType set to condTriggerConfig, then:

[0224] 4> Remove the entry with matching measObjectId from measObjectList in VarMeasConfig;

[0225] 3> Remove the entry with matching measId from measIdList in VarMeasConfig;

[0226] 2> Reset MAC and release the preset MAC cell group configuration, if any;

[0227] 2>Rebuild the RLC entity for SRB1;

[0228] 2> If a RRCRelease message with suspendConfig is received in response to RRCResumeRequest or RRCResumeRequest1, then:

[0229] 3> If it is running, stop timer T319;

[0230] 3> In the stored UE inactive AS context:

[0231] 4>Use the current K gNB and K RRCint Key replacement K gNB and K RRCint Key;

[0232] 4> Replace the C-RNTI with the temporary C-RNTI in the cell where the UE has received the RRCRelease message;

[0233] 4> Replace cellIdentity with the cellIdentity of the cell in which the UE has received the RRCRelease message;

[0234] 4> Replace the physical cell identity with the physical cell identity of the cell in which the UE has received the RRCRelease message;

[0235] 2> Otherwise:

[0236] 3> Store the current K in the UE inactive AS context gNB and K RRCintkeys, ROHC state, stored QoS flow to DRB mapping rules, C-RNTI for source PCell, cellIdentity and physical cell identity of source PCell, spCellConfigCommon within ReconfigurationWithSync of NR PSCell (if configured), and all other configuration parameters except the following:

[0237] -Parameters in ReconfigurationWithSync of PCell;

[0238] -Parameters within ReconfigurationWithSync of NR PSCell (if configured);

[0239] - parameters within the MobilityControlInfoSCG of the E-UTRA PSCell (if configured);

[0240] -servingCellConfigCommonSIB;

[0241] NOTE 2: When the UE enters RRC_INACTIVE, the NR sidelink communication related configuration and the logged measurement configuration are not stored as UE inactive AS context.

[0242] 2>Suspend all SRBs and DRBs except SRB0;

[0243] 2> Instruct the lower layers of all DRBs to suspend PDCP;

[0244] 2> If t380 is included, then:

[0245] 3>Start timer T380, where the timer value is set to t380:

[0246] 2> If the RRCRelease message contains waitTime, then:

[0247] 3>Start timer T302, where the value is set to waitTime;

[0248] 3> Notify upper layers that access barring applies to all access categories except categories '0' and '2'.

[0249] 2> If T390 is running, then:

[0250] 3> Stop timer T390 for all access categories;

[0251] 3>Perform the actions specified in 5.3.14.4;

[0252] 2> Indicate to the upper layer the suspension of the RRC connection;

[0253] 2> Enter RRC_INACTIVE and perform cell selection as specified in TS 38.304

[20] ;

[0254] 1> Otherwise

[0255] 2> Perform actions after entering RRC_IDLE as specified in 5.3.11, where the release cause is 'other'.

[0256] […]

[0257] 5.3.13RRC Connection Recovery

[0258] 5.3.13.1 Overview

[0259] [3GPP TS 38.331 V16.2.0 titled "RRC Connection Recovery Success" Figure 5 .3.13.1-1 Reproduced as Figure 8 ]

[0260] […]

[0261] [3GPP TS 38.331 V16.2.0 entitled "Successful RRC connection resumption followed by network suspension" Figure 5 .3.13.1-4 reproduced as Fig. 9 ]

[0262] […]

[0263] The purpose of this procedure is to resume a suspended RRC connection, including resuming SRBs and DRBs or performing RNA updates.

[0264] […]

[0265] 5.3.13.2 Initiation

[0266] The UE initiates the procedure when upper layers or the AS request to resume a suspended RRC connection (when responding to RAN paging, when following a RNA update triggered when the UE is in RRC_INACTIVE, or for sidelink communications as specified in subclause 5.3.13.1a).

[0267] Before initiating this procedure, the UE shall ensure that it has valid and up-to-date basic system information as specified in clause 5.2.2.2.

[0268] After initiating the procedure, the UE shall:

[0269] 1> If the resumption of the RRC connection is triggered by responding to NG-RAN paging, then:

[0270] 2>Select '0' as the access category;

[0271] 2> Use the selected access category and one or more access identifiers provided by the upper layer to perform the unified access control procedures specified in 5.3.14;

[0272] 3> If the access attempt is blocked, the procedure ends;

[0273] 1> Otherwise, if the recovery of the RRC connection is triggered by upper layers:

[0274] 2> If the upper layer provides an access category and one or more access identifiers:

[0275] 3> Use the access category and access identifier provided by the upper layer to implement the unified access control procedures specified in 5.3.14;

[0276] 4> If the access attempt is blocked, the procedure ends;

[0277] 2> Set resumeCause based on the information received from the upper layer;

[0278] 1> Otherwise, if the resumption of the RRC connection is triggered due to an RNA update as specified in 5.3.13.8:

[0279] 2> If emergency services are in progress, then:

[0280] NOTE: How the RRC layer in the UE perceives the ongoing emergency services depends on the UE implementation.

[0281] 3>Select '2' as the access category;

[0282] 3> Set resumeCause to emergency;

[0283] 2> Otherwise:

[0284] 3>Select '8' as the access category;

[0285] 2> perform the unified access control procedures as specified in 5.3.14 using the selected access category and one or more access identifiers to be applied as specified in TS 24.501

[23] ;

[0286] 3> If the access attempt is blocked, then:

[0287] 4>Set the variable pendingRNA-Update to true;

[0288] 4>The program ends;

[0289] 1> If the UE is in NE-DC or NR-DC:

[0290] 2> If the UE does not support maintaining the SCG configuration after the connection is restored, then:

[0291] 3> if stored, release the MR-DC related configuration from the UE inactive AS context (i.e. as specified in 5.3.5.10);

[0292] 1> If the UE does not support maintaining the MCG SCell configuration after the connection is restored:

[0293] 2> If stored, release the MCG SCell from the UE inactive AS context;

[0294] 1> As specified in the corresponding physical layer specification, the preset L1 parameter values ​​apply, except for parameters whose values ​​are provided in SIB1;

[0295] 1> Apply the preset SRB1 configuration as specified in 9.2.1;

[0296] 1> As specified in 9.2.2, the preset MAC cell group configuration is applied;

[0297] 1> If stored, release delayBudgetReportingConfig from the UE inactive AS context;

[0298] 1> If it is running, stop timer T342;

[0299] 1> If stored, release overheatingAssistanceConfig from the UE inactive AS context;

[0300] 1> If it is running, stop timer T345;

[0301] 1> If stored, release the idc-AssistanceConfig from the UE inactive AS context;

[0302] 1> If stored, release the drx-PreferenceConfig for all configured cell groups from the UE inactive AS context;

[0303] 1> If running, stop all instances of timer T346a;

[0304] 1> if stored, release the maxBW-PreferenceConfig for all configured cell groups from the UE inactive AS context;

[0305] 1> If running, stop all instances of timer T346b;

[0306] 1> if stored, release the maxCC-PreferenceConfig for all configured cell groups from the UE inactive AS context;

[0307] 1> If running, stop all instances of timer T346c;

[0308] 1> if stored, release the maxMIMO-LayerPreferenceConfig for all configured cell groups from the UE inactive AS context;

[0309] 1> If running, stop all instances of timer T346d;

[0310] 1> if stored, release the minSchedulingOffsetPreferenceConfig for all configured cell groups from the UE inactive AS context;

[0311] 1> Stop all instances of timer T346e if they are running;

[0312] 1> If stored, release releasePreferenceConfig from the UE inactive AS context;

[0313] 1> If it is running, stop timer T346f;

[0314] 1> Apply CCCH configuration as specified in 9.1.1.2;

[0315] 1> Apply timeAlignmentTimerCommon contained in SIB1;

[0316] 1>Start timer T319;

[0317] 1>Set the variable pendingRNA-Update to false;

[0318] 1> Initiate the transmission of RRCResumeRequest message or RRCResumeRequest1 according to 5.3.13.3.

[0319] 5.3.13.3 Actions related to the transmission of RRCResumeRequest or RRCResumeRequest1 messages

[0320] The UE shall set the content of the RRCResumeRequest or RRCResumeRequest1 message as follows:

[0321] 1> If the field useFullResumeID is signaled in SIB1, then:

[0322] 2>Select RRCResumeRequest1 as the message to be used;

[0323] 2> Set resumeIdentity to the stored fullI-RNTI value;

[0324] 1> Otherwise:

[0325] 2>Select RRCResumeRequest as the message to be used;

[0326] 2> Set resumeIdentity to the stored shortI-RNTI value;

[0327] 1> Restore the RRC configuration, RoHC state, stored QoS flow to DRB mapping rules, and K from the stored UE inactive AS context gNB and K RRCint Keys, except for the following:

[0328] -masterCellGroup;

[0329] - if stored, mrdc-SecondaryCellGroup; and

[0330] -pdcp-Config;

[0331] 1> Set resumeMAC-I to the 16 least significant bits of the calculated MAC-I:

[0332] 2> via ASN.1 encoding as VarResumeMAC-Input according to clause 8 (i.e., a multiple of 8 bits);

[0333] 2>Use K in the UE inactive AS context RRCint The key and previously configured integrity protection algorithm; and

[0334] 2> All input bits of COUNT, BEARER and DIRECTION are set to binary bits;

[0335] 1>Use the stored nextHopChainingCount value based on the current K gNB Key or NH export K gNBKeys, as specified in TS 33.501

[11] ;

[0336] 1>Export K RRCenc Key, K RRCint Key, K UPint Key and K UPenc Key;

[0337] 1> Then use the configured algorithm and K derived in this subclause RRCint Key and K UPint The key configures the lower layers to apply integrity protection to all radio bearers except SRB0, i.e. integrity protection will be applied to all subsequent messages received and sent by the UE;

[0338] NOTE 1: Only DRBs with previously configured UP integrity protection will have integrity protection restored.

[0339] 1> Configure lower layers to apply ciphering to all radio bearers except SRB0 and apply the configured ciphering algorithm and K derived in this subclause RRCenc Key and K UPenc The key, i.e., the encryption configuration will be applied to all subsequent messages received and sent by the UE;

[0340] 1>Reestablish the PDCP entity for SRB1;

[0341] 1>Restore SRB1;

[0342] 1>Submit the selected message RRCResumeRequest or RRCResumeRequest1 for transmission to the lower layer.

[0343] Note 2: Only DRBs with previously configured UP encryption will resume encryption.

[0344] If the lower layer indicates that the integrity check has failed while T319 is running, the actions specified in 5.3.13.5 are performed.

[0345] The UE shall continue to perform cell reselection related measurements and cell reselection evaluation. If the cell reselection conditions are met, the UE shall perform cell reselection as specified in 5.3.13.6.

[0346] […]

[0347] 5.3.13.8 RNA Update

[0348] In the RRC_INACTIVE state, the UE shall:

[0349] 1> If T380 expires; or

[0350] 1> If RNA update is triggered upon reception of SIB1, as specified in 5.2.2.4.2, then:

[0351] 2> Initiate the RRC connection recovery procedure in 5.3.13.2, where resumeCause is set to rna-Update;

[0352] 1> If the restriction is relaxed for access category '8' or access category '2' as specified in 5.3.14.4:

[0353] 2> If the upper layer does not request RRC to restart the RRC connection, and

[0354] 2>If the variable pendingRNA-Update is set to true:

[0355] 3> Initiate the RRC connection recovery procedure in 5.3.13.2, where the resumeCause value is set to rna-Update.

[0356] If a UE in RRC_INACTIVE state fails to find a suitable cell and camps on an acceptable cell to obtain limited service as defined in TS 38.304

[20] , the UE shall:

[0357] 1> Perform actions after entering RRC_IDLE as specified in 5.3.11, where the release cause is 'other'.

[0358] NOTE: When the UE is neither camping on a suitable cell nor camping on an acceptable cell, how it behaves when T380 expires depends on the UE implementation.

[0359] 5.3.13.9 Receiving RRCRelease via UE

[0360] UE will:

[0361] 1>Execute the actions specified in 5.3.8.

[0362] […]

[0363] 6.2.1 General message structure

[0364] […]

[0365] -UL-CCCH-Message

[0366] The UL-CCCH-Message class is a set of 48-bit RRC messages that can be sent from the UE to the network on the uplink CCCH logical channel.

[0367]

[0368] […]

[0369] 6.2.2 Message Limitation

[0370] […]

[0371] -RRCResumeRequest

[0372] The RRCResumeRequest message is used to request to restart a suspended RRC connection or perform an RNA update.

[0373] Signaling Radio Bearer: SRB0

[0374] RLC-SAP:TM

[0375] Logical channel: CCCH

[0376] Direction: UE to network

[0377] RRCResumeRequest message

[0378]

[0379]

[0380]

[0381] -RRCResumeRequest1

[0382] The RRCResumeRequest1 message is used to request to restart a suspended RRC connection or perform RNA update.

[0383] Signaling Radio Bearer: SRB0

[0384] RLC-SAP:TM

[0385] Logical channel: CCCH1

[0386] Direction: UE to network

[0387] RRCResumeRequest1 message

[0388]

[0389]

[0390]

[0391] […]

[0392] -RRCResume

[0393] The RRCResume message is used to resume a suspended RRC connection.

[0394] Signaling Radio Bearer: SRB1

[0395] RLC-SAP:AM

[0396] Logical channel: DCCH

[0397] Direction: Network to UE

[0398] RRCResume message

[0399]

[0400]

[0401] […]

[0402] -RRCResumeComplete

[0403] The RRCResumeComplete message is used to confirm the successful completion of the RRC connection resumption.

[0404] Signaling Radio Bearer: SRB1

[0405] RLC-SAP:AM

[0406] Logical channel: DCCH

[0407] Direction: UE to network

[0408] RRCResumeComplete message

[0409]

[0410]

[0411] […]

[0412] -RRCRelease

[0413] The RRCRelease message is used to command the release of the RRC connection or the suspension of the RRC connection.

[0414] Signaling Radio Bearer: SRB1

[0415] RLC-SAP:AM

[0416] Logical channel: DCCH

[0417] Direction: Network to UE

[0418] RRCRelease message

[0419]

[0420]

[0421]

[0422] […]

[0423] -RRCSetup

[0424] The RRCSetup message is used to establish SRB1.

[0425] Signaling Radio Bearer: SRB0

[0426] RLC-SAP:TM

[0427] Logical channel: CCCH

[0428] Direction: Network to UE

[0429] RRCSetup message

[0430]

[0431]

[0432]

[0433] -RRCSetupComplete

[0434] The RRCResumeComplete message is used to confirm the successful completion of the RRC connection establishment.

[0435] Signaling Radio Bearer: SRB1

[0436] RLC-SAP:AM

[0437] Logical channel: DCCH

[0438] Direction: UE to network

[0439] RRCSetupComplete message

[0440]

[0441]

[0442]

[0443] -RRCSetupRequest

[0444] The RRCSetupRequest message is used to request to establish an RRC connection.

[0445] Signaling Radio Bearer: SRB0

[0446] RLC-SAP:TM

[0447] Logical channel: CCCH

[0448] Direction: UE to network

[0449] RRCSetupRequest message

[0450]

[0451]

[0452]

[0453]

[0454] […]

[0455] 6.3.2 Radio Resource Control Information Elements

[0456] […]

[0457] -ResumeCause

[0458] IE ResumeCause is used to indicate the resumption reason in RRCResumeRequest and RRCResumeRequest1.

[0459] ResumeCause Information Element

[0460]

[0461]

[0462] […]

[0463] 7.4UE variables

[0464] […]

[0465] -VarResumeMAC-Input

[0466] The UE variable VarResumeMAC-Input specifies the input used to generate resumeMAC-I during the RRC connection resumption procedure.

[0467] VarResumeMAC - Input variable

[0468]

[0469]

[0470] 3GPP TS 38.300 introduces the following:

[0471] 9.2.2 Mobility in RRC_INACTIVE

[0472] 9.2.2.1 Overview

[0473] […]

[0474] When a UE in RRC_INACTIVE state moves out of a configured RNA, the UE needs to initiate an RNA update procedure. When an RNA update request is received from the UE, the receiving gNB triggers the XnAP Retrieve UE Context procedure to get the UE context from the last serving gNB, and may decide to send the UE back to the RRC_INACTIVE state, put the UE into the RRC_CONNECTED state, or send the UE to RRC_IDLE. In case of periodic RNA updates, if the last serving gNB decides not to relocate the UE context, it fails to retrieve the UE context procedure and sends the UE back to RRC_INACTIVE, or directly to RRC_IDLE via an encapsulated RRCRelease message.

[0475] […]

[0476] 3GPP TR 23.752 introduces the following:

[0477] 6.7 Solution #7: Indirect communication via Layer 2 UE to Network Relay UE

[0478] 6.7.1 Introduction

[0479] The solution addresses the following aspects highlighted in Key Issue #3 (Supporting UE to Network Relay UE):

[0480] -How to transfer data between remote UE and network via UE to network relay UE.

[0481] The solution proposes a protocol architecture that supports layer 2 UE to network relay UE (see Annex A).

[0482] This solution is only applicable to NR / 5GC network relay. It is not applicable when the UE to network relay UE is out of the coverage of NR / 5GC.

[0483] 6.7.2 Functional Description

[0484] 6.7.2.1 Overview

[0485] In this clause, a protocol architecture supporting L2 UE to network relay UE is provided.

[0486] The L2 UE to network relay UE provides forwarding functionality, which can relay any type of service on the PC5 link.

[0487] L2 UE to Network Relay UE provides functionality to support connectivity to 5GS for remote UEs. If a PC5 link to L2 UE to Network Relay UE is successfully established, the UE is considered a remote UE. The remote UE may be located within or outside the NG-RAN coverage.

[0488] 6.7.2.2 Control and user plane protocols

[0489] The control and user plane protocol stacks are based on the architecture reference model described in Annex A.

[0490] 6.7.2.3 Network Selection

[0491] Network selection includes PLMN selection and access network selection. Access network selection for remote UE includes discovery and selection of UE to network relay. Remote UE performs PLMN selection according to the PLMN selected by UE to network relay. Relay UE provides serving PLMN information and other PLMN information in system information to remote UE in order to perform PLMN selection during discovery.

[0492] Editor's note: Which and how many PLMNs the L2 UE to Network Relay is expected to support and recommend is for further study. For example whether it is only its registered PLMNs, its registered PLMNs and equivalent to the registered PLMNs or it can be (hard) configured to include any PLMN similar to the MOCN configuration.

[0493] Remote UEs and UE-to-network relay UEs are by definition served by the same NG-RAN.

[0494] 6.7.2.4 Authorization and Provisioning

[0495] In order to enable out-of-coverage (remote) UEs to gain connectivity to the network, it is important to allow such UEs to discover potential UE-to-network relay UEs through which they can gain access to the 5GS by means of (pre-)configuration. To achieve this:

[0496] Parameters for UE to Network Relay UE discovery and for communication over NR PC5 may be made available to the remote UE as follows:

[0497] - Pre-configured in the ME and / or configured in the UICC;

[0498] -Provided by the PCF or updated to the UE in the serving PLMN.

[0499] It is also important that the UE is authorized to operate as a UE-to-network relay UE.The UE may operate as a UE-to-network relay UE only when served by the network.

[0500] Parameters for the UE to operate as a UE to network relay UE, for discovery of remote UEs through NR PC5 and for communication through NR PC5 may be made available to the UE as follows:

[0501] - Pre-configured in the ME and / or configured in the UICC;

[0502] -Provided by the PCF or updated to the UE in the serving PLMN.

[0503] It should be possible for the HPLMN PCF to provide authorization for the UE to operate as a remote UE or as a UE-to-network relay UE on a per PLMN basis. It should also be possible for the serving PLMN to provide / revoke such authorization, in which case any corresponding information provided by the HPLMN should be overridden.

[0504] The PCF-based service authorization and provisioning solution for Layer 2 UE to network relay may reuse Solution #35.

[0505] 6.7.2.5 Registration and connection management

[0506] 6.7.2.5.1 Registration management

[0507] Registration management for UE to network relay UE follows the principles and procedures defined in TS 23.501 [6] and TS 23.502 [8]. UE to network relay is served by the first AMF.

[0508] Registration management for remote UEs follows the principles and procedures defined in TS 23.501 [6] and TS 23.502 [8]. The remote UE is served by a second AMF which may or may not be the same as the first AMF.

[0509] NOTE: A UE is authorized to act as a UE-to-network relay only if the network (including RAN / CN) does not restrict, e.g. authorization, unified access control, and the remote UE and the UE-to-network relay are in the same rPLMN or ePLMN.

[0510] 6.7.2.5.2 Connection Management

[0511] Connection management for UE to network relay UE follows at least the principles and procedures defined in TS 23.501 [6] and TS 23.502 [8].

[0512] Connection management for remote UEs follows the principles and procedures defined in TS 23.501 [6] and TS 23.502 [8].

[0513] The UE-to-network relay may relay data / signaling for a remote UE only when the UE-to-network relay is in CM-CONNECTED / RRC connected state. If a UE-to-network relay in CM_IDLE state receives a PC5 connection request for relaying from a remote UE, the UE-to-network relay shall trigger a service request procedure to enter the CM_CONNECTED state before relaying signaling.

[0514] - If any remote UE connected to the UE-to-network relay UE is in CM-CONNECTED, the UE-to-network relay UE shall remain in CM-CONNECTED state.

[0515] -If all remote UEs connected to the UE-to-network relay UE enter CM-IDLE, the UE-to-network relay UE may enter CM-IDLE state.

[0516] Note: The status of the application needs to be coordinated and confirmed by RAN WG2. RAN WG2 will also study the impact on the inactive RRC.

[0517] When the remote UE is in CM-IDLE or CM-CONNECTED, the relay UE and the remote UE maintain a PC5 link.

[0518] For paging remote UEs, the solution reached in clause 6.6.2 of TR 23.733

[26] may be reused based on the assumption that RAN WG2 adopts option 2 of TR 36.746

[27] .

[0519] Editor's note: Whether RAN WG2 will adopt paging option 2 of TR 36.746

[27] for 5G ProSe needs to be confirmed by the RAN group.

[0520] 6.7.2.5.3 NAS-level congestion control

[0521] The UE-to-network relay may be subject to NAS-level congestion control as specified in clause 5.19.7 of TS 23.501 [6].

[0522] When NAS mobility management congestion control is activated, i.e. when the UE to network relay receives the mobility management back-off timer from the AMF, the UE to network relay cannot properly serve the remote UE after the UE to network relay enters the CM_IDLE state. In that case, the UE to network relay needs to inform the remote UE that there is a mobility management back-off timer running at the UE to network relay so that the remote UE can (re)select another UE to network relay.

[0523] Remote UEs may also be subject to NAS level congestion control. The existing behavior defined in TS 23.501 [6] shall apply.

[0524] 6.7.2.6QoS

[0525] As shown in Annex A, the NAS endpoints between the remote UE and the network are as currently specified, so that the operation of relaying the UE via the UE to the network should be transparent to the network NAS, except for the authorization / provisioning identified in clause 6.7.2.4.

[0526] This means that the 5GS flow based QoS concept should be reused in particular between the remote UE and the network, and the necessary adaptations are made on the radio interfaces, namely PC5 (for remote UE and UE to network relay UE) and Uu (for UE to network relay UE). When the RAN obtains the QoS attribute set from the CN, the RAN performs QoS enforcement on the PC5 interface and the Uu interface. For example, the RAN performs QoS enforcement with AS layer configuration and makes the necessary adaptations on the PC5 interface and the Uu interface. In other words, the QoS flow established between the network and the remote UE will be mapped to the PC5 "radio bearer" seen by the remote UE and the normal Uu radio bearer seen by the network, whereby the UE to network relay UE performs the necessary adaptations between Uu and PC5.

[0527] Editor's Note: How to perform the AS layer configuration for the PC5 interface and the Uu interface depends on the RAN.

[0528] 6.7.2.7 Mobility

[0529] 6.7.2.7.1 Mobility restrictions

[0530] The remote UE is expected to operate within the bounds of the mobility restrictions applicable to UEs to network relay UEs.

[0531] Mobility restriction in CM-IDLE state is performed by the UE based on information received from the network. For UE to network relay case, if the remote UE is out of coverage, the remote UE may not be able to obtain mobility restriction related information. The remote UE can obtain mobility restriction related information, such as tracking area, from the relay UE, and the remote UE itself performs network selection and access control in CM_IDLE state based on the received information.

[0532] RAT Restrictions:

[0533] - If the remote UE is restricted to use certain RATs in the PLMN, the remote UE is not allowed to access via the UE-to-network relay using the RAT in the PLMN. If the UE-to-network relay is restricted to use certain RATs in the PLMN, the UE-to-network relay is not allowed to perform relay operations using the RAT in the PLMN.

[0534] Disabled Areas:

[0535] - If a UE-to-network relay is in a disabled area, it is not allowed to perform relay operations. If a UE-to-network relay operates in a disabled area for a remote UE, the remote UE is not allowed to access the network via this UE-to-network relay.

[0536] - The UE-to-Network Relay shall indicate to the remote UE the tracking area of ​​the cell to which the UE-to-Network Relay is connected. The indication is provided during discovery.

[0537] Service area restrictions: allowed area, non-allowed area

[0538] - The allowed zone itself applies to both UE-to-network relays and remote UEs. A UE-to-network relay (respectively a remote UE) is allowed to initiate communications with the network (respectively with the network via the UE-to-network relay) as allowed by the subscription.

[0539] -UE to Network Relay UE to Network Relay operation can only be performed in the allowed area.

[0540] - The non-allowed area itself applies to UE to network relay and remote UE. The UE (UE to network relay or remote UE) and the network are not allowed to initiate service request or SM signaling to obtain user services (in both CM-IDLE and CM-CONNECTED states). The RM procedure for non-3GPP access is not applicable to remote UE.

[0541] - When the UE to network relay UE enters a non-allowed area and the UE to network relay cannot provide relay service, it may release the PC5 unicast connection with a reason code which informs the remote UE of the UE to network relay in the non-allowed area.

[0542] NOTE 1: The above items regarding changes in service area restrictions due to UE to network relay mobility will be evaluated separately from the rest of Solution #7.

[0543] Core network type restrictions:

[0544] -CN type restriction itself applies to UE to network relay and remote UE. UE to network relay or remote UE can only do so when not restricted to use 5GC.

[0545] Closed access group information:

[0546] - A UE that is permitted (respectively, not permitted) to access a CAG cell is implicitly permitted (respectively, not permitted) to access this CAG cell as a remote UE via the UE-to-network relay. When the UE is a remote UE, the UE's allowed CAG list and CAG-only indication apply to this UE.

[0547] - A UE that is permitted (respectively, not permitted) to access a CAG cell is implicitly permitted (respectively, not permitted) to access this CAG cell as a UE-to-network relay. When a UE operates as a UE-to-network relay, the UE's allowed CAG list and CAG-only indication apply to this UE.

[0548] - The UE-to-network relay shall indicate to the remote UE the CAG identifier of the CAG to which the UE-to-network relay is permitted to access the cell via which it is connected. The indication is provided during discovery.

[0549] - If the UE-to-network relay is only permitted to access CAG cells, the UE-to-network relay shall provide its CAG-only indication to the remote UE. The CAG identifier and the CAG-only indication are provided to the remote UE for UE-to-network relay selection during the discovery procedure.

[0550] - The UE-to-network relay may send an update of the CAG identifier and only the CAG indication to the remote UE due to mobility of the UE-to-network relay or a configuration change of the UE-to-network relay, such as the UE configuration update procedure described in TS 23.502 [8] in clause 4.2.4.2. In this case, if the remote UE determines that it is no longer allowed to access the network via the current UE-to-network relay, the remote UE may disconnect the PC5 connection and reselect another UE-to-network relay, or may reselect the same UE-to-network relay if the new configuration is still allowed to be considered.

[0551] NOTE 2: The above two items regarding CAG identifier change and CAG-only indication will be evaluated separately from the rest of Solution 7.

[0552] 6.7.2.7.2 Others

[0553] The mobility of remote UEs within the NG-RAN node will be handled by the NG-RAN and UE to network relay, allowing the remote UE to maintain service without involving the 5GC when changing from direct network connection to indirect network connection (i.e., via L2 UE to network relay UE) and when changing from indirect network connection to direct network connection.

[0554] [3GPP TR 23.752 V0.5.1 titled “Intra-NG-RAN Mobility (without 5GC)” Figure 6 .7.2.6-1 Reproduced as Fig.10 ]

[0555] Inter-NG-RAN mobility is described below. It is expected that mobility is possible with no impact on NAS and mainly impact on lower layers (i.e., RAN WG2).

[0556] [3GPP TR 23.752 V0.5.1 entitled “Inter-NG-RAN Mobility” Figure 6 .7.2.6-2 Reproduced as Fig.11 ]

[0557] 6.7.2.8 Security

[0558] Security (confidentiality and integrity protection) is enforced at the PDCP layer between the endpoints at the remote UE and the gNB. PDCP traffic is securely relayed on two links without exposing any plaintext data of the remote UE to the UE-to-network relay, one link between the remote UE and the UE-to-network relay UE and the other link between the UE-to-network relay UE to the gNB.

[0559] The UP integrity protection for direct PC5 communication and indirect communication is separate. For indirect communication, the NG-RAN and the remote UE are nodes that enforce UP integrity protection for data transfer between the NG-RAN and the remote UE.

[0560] For direct PC5 communication, the UE-to-network relay UE and the remote UE are nodes that enforce UP integrity protection for data transfer between the UE-to-network relay UE and the remote UE.

[0561] NOTE: Further analysis of security requirements will be done in SA WG3.

[0562] 6.7.2.9 UE to Network Relay Discovery and Selection

[0563] Model A and Model B can be applied to layer 2 UE to network relay discovery. The detailed UE to network relay discovery and selection solution for layer 2 UE to network relay can reuse solution #19, except that slice and DNN information do not need to be considered. In addition, mobility restriction related information such as CAG cells and TA can be included in the discovery message.

[0564] Editor's Note: How relay discovery can be performed with PLMN selection for remote UEs will be addressed in a separate solution for KI#3.

[0565] 6.7.2.10 Path selection

[0566] For initial access, the remote UE may perform communication path selection between a direct Uu path and an indirect Uu path based on link quality and a configured threshold (pre-configured or provided by the NG-RAN). For example, if the Uu link quality exceeds the configured threshold, the direct Uu path is selected. Otherwise, the indirect Uu path is selected by performing UE-to-network relay discovery and selection.

[0567] For path switching scenarios, NG-RAN may perform communication path selection based on the signal level / quality of different paths, which may be based on the path switching solution.

[0568] Editor's Note: The final solution should be coordinated with the RAN WG, and the specific radio criteria and corresponding thresholds must comply with the RAN WG definition.

[0569] 6.7.3 Procedure

[0570] [3GPP TR 23.752 V0.5.1 entitled "Connection establishment for indirect communications via UE to network relay UE" Figure 6 .7.3-1 Reproduced as Fig.12 ]

[0571] 0. If within coverage, the remote UE and the UE-to-network relay UE may independently perform initial registration with the network according to the registration procedure in TS 23.502 [8]. The allocated 5G GUTI of the remote UE is maintained when later NAS signaling between the remote UE and the network is exchanged via the UE-to-network relay UE.

[0572] NOTE 1: The current procedures presented here assume a single-hop relay.

[0573] 1. If in coverage, the remote UE and UE-to-network relay UE independently obtain service authorization for indirect communication from the network. Service authorization and parameter provisioning for UE-to-network relay operation is performed for UE-to-network relay UE and remote UE as specified in clause 6.7.2.4.

[0574] If the remote UE is not within coverage, the pre-configured information will be used. The PCF may update the authorization information after step 7 if necessary.

[0575] If the remote UE has not performed initial registration, the remote UE may perform initial registration via indirect network communication in step 7 .

[0576] 2-3. Remote UE and UE-to-network relay UE perform UE-to-network relay UE discovery and selection. The relay UE may perform UE-to-network relay discovery in both CM_IDLE and CM_CM-CONNECTED.

[0577] Details of UE-to-network relay discovery and selection for Layer 2 UE-to-network relay are provided in clause 6.7.2.9 and Solution #19, Solution #41.

[0578] 4. The remote UE initiates a one-to-one communication connection with the selected UE to the network relay UE through PC5 using the procedures as described in TS 23.287 [5].

[0579] 5. If the UE-to-network relay UE is in CM_IDLE state triggered by a communication request received from a remote UE, the UE-to-network relay UE sends a Service Request message to its serving AMF.

[0580] The relaying AMF may perform authentication of the UE to the network relaying UE based on NAS message verification and, if necessary, the AMF shall check the subscription data.

[0581] How to keep the relay UE in CM_CONNECTED state is proposed in clause 6.7.2.5.2.

[0582] 6. The remote UE sends an AS message to the NG-RAN via the UE-to-NW relay UE to establish an AS connection with the same NG-RAN serving the relay UE.

[0583] 7. The remote UE sends a NAS message to the serving AMF. The NAS message is encapsulated in an RRC message sent to the UE-to-network relay UE via PC5, and the UE-to-network relay UE forwards the message to the NG-RAN. The NG-RAN derives the serving AMF of the remote UE and forwards the NAS message to this AMF.

[0584] The NAS message is an initial registration message if the remote UE has not performed an initial registration with the network in step 0. Otherwise, the NAS message is a service request message, or a mobility or periodic registration message.

[0585] Editor's Note: UE to Network Relay How the UE forwards messages to the NG-RAN depends on the L2 relay method specified by the RAN.

[0586] If the remote UE performs an initial registration via the UE-to-network relay, the serving AMF of the remote UE may perform authentication of the remote UE based on NAS message verification and, if necessary, the AMF of the remote UE checks subscription data.

[0587] For the service request case, the user plane connection for the PDU session may also be activated. The other steps follow clause 4.2.3.2 of TS 23.502 [8].

[0588] 8. The remote UE may trigger the PDU Session Establishment procedure as defined in clause 4.3.2.2 of TS 23.502 [8]. The remote UE is provided with PDU Session related attributes allowed during the registration procedure or by pre-configuration as described in step 0 while operating via the UE to NW Relay UE.

[0589] 9. Data is transferred between the remote UE and UPF via the UE-to-Network Relay UE and NG-RAN. The UE-to-Network Relay UE forwards all data messages between the remote UE and the NG-RAN using the L2 relay method specified by the RAN.

[0590] NOTE 2: If the UE to network relay is disconnected, the NG-RAN shall trigger the AN release procedure for the remote UE and the remote UE enters CM-IDLE.

[0591] 6.7.4 Impact on Services, Entities, and Interfaces

[0592] The solution has impact in the following entities:

[0593] AMF:

[0594] - The release of the signalling connection is not initiated based on the authorization of the relaying UE.

[0595] RAN:

[0596] - It is necessary to support L2 relay function for forwarding signaling and user data of remote UE.

[0597] - (If Paging Option 2 of TR 36.746

[27] is confirmed by RAN WG2), when the relay UE is in CM-CONNECTED, the RAN needs to handle paging requests for the remote UE.

[0598] UE to network relay UE:

[0599] -L2 relay functionality needs to be supported for forwarding signaling and user data between remote UE and RAN.

[0600] - (If Paging Option 2 of TR 36.746

[27] is confirmed by RAN WG2) Need to monitor multiple paging occasions for own and remote UEs.

[0601] […]

[0602] 3GPP TS 38.321 introduces the following:

[0603] 5.1 Random Access Procedure

[0604] 5.1.1 Random Access Procedure Initialization

[0605] According to TS 38.300 [2], the random access procedure described in this clause is initiated by a PDCCH order, the MAC entity itself, or an RRC event. In the MAC entity, there is only one ongoing random access procedure at any point in time. The random access procedure on the SCell shall only be initiated by a PDCCH order where the ra-PreambleIndex is different from 0b000000.

[0606] NOTE 1: If a new random access procedure is triggered while another random access procedure is already in progress in the MAC entity, it will depend on the UE implementation to continue the ongoing procedure or start a new procedure (e.g. for SI request).

[0607] NOTE 2: If there is an ongoing random access procedure triggered by a PDCCH order when the UE receives another PDCCH order indicating the same random access preamble, PRACH mask index and uplink carrier, the random access procedure is regarded as the same random access procedure as the ongoing random access procedure and is not initialized again.

[0608] RRC configures the following parameters for the random access procedure:

[0609] -prach-ConfigurationIndex: A set of available PRACH opportunities for transmitting the random access preamble of Msg1. If the PRACH opportunities are shared between 2-step and 4-step RA types, these also apply to MSGA PRACH;

[0610] -prach-ConfigurationPeriodScaling-IAB: A scaling factor defined in TS 38.211 [8] and applicable to IAB-MT, which extends the periodicity of the PRACH opportunity baseline configuration indicated by prach-ConfigurationIndex;

[0611] -prach-ConfigurationFrameOffset-IAB: A frame offset defined in TS 38.211 [8] and applicable to IAB-MT, which changes the RO frame defined in the baseline configuration indicated by prach-ConfigurationIndex;

[0612] -prach-ConfigurationSOffset-IAB: a subframe / timeslot offset defined in TS 38.211 [8] and applicable to IAB-MT, which changes the RO subframe or time slot defined in the baseline configuration indicated by prach-ConfigurationIndex;

[0613] -msgA-prach-ConfigurationIndex: a set of available PRACH opportunities for transmitting the random access preamble of MSGA in 2-step RA type;

[0614] -preambleReceivedTargetPower: initial random access preamble power for 4-step RA type;

[0615] -msgA-PreambleReceivedTargetPower: initial random access preamble power for 2-step RA type;

[0616] -rsrp-ThresholdSSB: RSRP threshold used to select SSB for 4-step RA type. If the random access procedure is initiated for beam failure recovery, the rsrp-ThresholdSSB used to select SSB in candidateBeamRSList refers to the rsrp-ThresholdSSB in BeamFailureRecoveryConfig IE;

[0617] -rsrp-ThresholdCSI-RS: RSRP threshold used to select CSI-RS for 4-step RA type. If the random access procedure is initiated for beam failure recovery, rsrp-ThresholdCSI-RS is equal to rsrp-ThresholdSSB in BeamFailureRecoveryConfig IE;

[0618] -msgA-RSRP-ThresholdSSB: RSRP threshold for selecting SSB for 2-step RA type;

[0619] -rsrp-ThresholdSSB-SUL: RSRP threshold for selecting between NUL carrier and SUL carrier;

[0620] -msgA-RSRP-Threshold: RSRP threshold used to select between 2-step RA type and 4-step RA type when both 2-step and 4-step RA type random access resources are configured in the UL BWP;

[0621] -msgA-TransMax: Maximum number of MSGA transmissions when both 4-step and 2-step RA type random access resources are configured;

[0622] - candidateBeamRSList: a list of reference signals (CSI-RS and / or SSB) identifying candidate beams and associated random access parameters for recovery;

[0623] -recoverySearchSpaceId: the search space identifier used to monitor the response to the beam failure recovery request;

[0624] -powerRampingStep: power ramping factor;

[0625] -msgA-PreamblePowerRampingStep: Power ramping factor for MSGA preamble;

[0626] -powerRampingStepHighPriority: power ramping factor in case of prioritized random access procedure;

[0627] -scalingFactorBI: scaling factor for the prioritized random access procedure;

[0628] -ra-PreambleIndex: random access preamble;

[0629] -ra-ssb-OccasionMaskIndex: defines the PRACH occasions associated with the SSB where the MAC entity may transmit a random access preamble (see clause 7.4);

[0630] -msgA-SSB-SharedRO-MaskIndex: indicates the subset of 4-step RA type PRACH opportunities shared with 2-step RA type PRACH opportunities for each SSB. If 2-step RA type PRACH opportunities are shared with 4-step RA type PRACH opportunities and msgA-SSB-SharedRO-MaskIndex is not configured, all 4-step RA type PRACH opportunities can be used for 2-step RA type (see clause 7.4);

[0631] -ra-OccasionList: defines the PRACH opportunities associated with the CSI-RS in which the MAC entity can transmit the random access preamble;

[0632] -ra-PreambleStartIndex: the start index of the random access preamble for on-demand SI request;

[0633] -preambleTransMax: Maximum number of random access preamble transmissions;

[0634] -ssb-perRACH-OccasionAndCB-PreamblesPerSSB: limits the number of SSBs mapped to each PRACH opportunity of 4-step RA type and the number of contention-based random access preambles mapped to each SSB;

[0635] -msgA-CB-PreamblesPerSSB-PerSharedRO: defines the number of contention-based random access preambles of 2-step RA type mapped to each SSB when PRACH opportunities are shared between 2-step and 4-step RA types;

[0636] -msgA-SSB-PerRACH-OccasionAndCB-PreamblesPerSSB: limits the number of SSBs mapped to each PRACH opportunity of 2-step RA type and the number of contention-based random access preambles mapped to each SSB;

[0637] -msgA-PUSCH-ResourceGroupA: defines the MSGAPUSCH resources that the UE will use when performing MSG A transmission using random access preamble group A;

[0638] -msgA-PUSCH-ResourceGroupB: defines the MSGAPUSCH resources that the UE will use when performing MSG A transmission using random access preamble group B;

[0639] -msgA-PUSCH-resource-Index: identifies the index of the PUSCH resource used for MSGA in case of contention-free random access of 2-step RA type;

[0640] - If groupBconfigured is configured, random access preamble group B is configured for 4-step RA type.

[0641] - Among the contention-based random access preambles (as defined in TS 38.213 [6]) associated with an SSB, the first numberOfRA-PreamblesGroupA random access preambles belong to random access preamble group A. The remaining random access preambles associated with an SSB belong to random access preamble group B (if configured).

[0642] - If groupB-ConfiguredTwoStepRA is configured, random access preamble group B is configured for 2-step RA type.

[0643] - In a 2-step RA type contention-based random access preamble (such as TS

[0644] 38.213 [6]), the first msgA-numberOfRA-PreamblesGroupA random access preamble belongs to random access preamble group A. The remaining random access preambles associated with the SSB belong to random access preamble group B (if configured).

[0645] NOTE 3: If random access preamble group B is supported by the cell, random access preamble group B is included for each SSB.

[0646] - If random access preamble group B is configured for 4-step RA type, then:

[0647] -ra-Msg3SizeGroupA: threshold for determining the group of random access preambles of 4-step RA type;

[0648] -msg3-DeltaPreamble: Delta in TS 38.213 [6] PREAMBLE_Msg3 ;

[0649] -messagePowerOffsetGroupB: power offset for preamble selection;

[0650] -numberOfRA-PreamblesGroupA: defines the number of random access preambles in random access preamble group A used for each SSB.

[0651] - If random access preamble group B is configured for 2-step RA type, then:

[0652] -msgA-DeltaPreamble: Delta in TS 38.213 [6] MsgA_PUSCH ;

[0653] -msgA-messagePowerOffsetGroupB: the power offset for preamble selection configured as messagePowerOffsetGroupB contained in GroupB-ConfiguredTwoStepRA;

[0654] -msgA-numberOfRA-PreamblesGroupA: defines the number of random access preambles in random access preamble group A for each SSB configured as numberOfRA-PreamblesGroupA in GroupB-ConfiguredTwoStepRA;

[0655] -ra-MsgA-SizeGroupA: The threshold used to determine the group of random access preambles of the 2-step RA type.

[0656] - A set of random access preambles and / or PRACH opportunities (if any) used for SI request;

[0657] - a set of random access preambles and / or PRACH opportunities (if any) for beam failure recovery request; - a set of random access preambles and / or PRACH opportunities (if any) for synchronization reconfiguration;

[0658] -ra-ResponseWindow: The time window for monitoring RA responses (SpCell only);

[0659] -ra-ContentionResolutionTimer: Contention resolution timer (SpCell only);

[0660] -msgB-ResponseWindow: The time window for listening to RA responses of 2-step RA type (SpCell only). In addition, it is assumed that the following information of the relevant serving cell is available to the UE:

[0661] -If random access preamble group B is configured:

[0662] - If the serving cell for the random access procedure is configured with a supplementary uplink as specified in TS 38.331 [5] and a SUL carrier is selected for performing the random access procedure, then:

[0663] - P for the SUL carrier as specified in TS 38.101-1

[14] , TS 38.101-2

[15] and TS 38.101-3

[16] CMAX,f,c .

[0664] -otherwise:

[0665] - P for NUL carriers as specified in TS 38.101-1

[14] , TS 38.101-2

[15] and TS 38.101-3

[16] CMAX,f,c .

[0666] The following UE variables are used for the random access procedure:

[0667] -PREAMBLE_INDEX;

[0668] -PREAMBLE_TRANSMISSION_COUNTER;

[0669] -PREAMBLE_POWER_RAMPING_COUNTER;

[0670] -PREAMBLE_POWER_RAMPING_STEP;

[0671] -PREAMBLE_RECEIVED_TARGET_POWER;

[0672] -PREAMBLE_BACKOFF;

[0673] -PCMAX;

[0674] -SCALING_FACTOR_BI;

[0675] -TEMPORARY_C-RNTI;

[0676] -RA_TYPE;

[0677] -POWER_OFFSET_2STEP_RA;

[0678] -MSGA_PREAMBLE_POWER_RAMPING_STEP.

[0679] When a random access procedure is initiated on a serving cell, the MAC entity shall:

[0680] 1> Clear the Msg3 buffer;

[0681] 1> Clear the MSGA buffer;

[0682] 1> Set PREAMBLE_TRANSMISSION_COUNTER to 1;

[0683] 1> Set PREAMBLE_POWER_RAMPING_COUNTER to 1;

[0684] 1>Set PREAMBLE_BACKOFF to 0>ms;

[0685] 1> Set POWER_OFFSET_2STEP_RA to 0dB;

[0686] 1> If the carrier used for the random access procedure is explicitly transmitted, then:

[0687] 2> Select the transmitted carrier to perform the random access procedure;

[0688] 2> Set PCMAX to the P value of the transmitted carrier. CMAX,f,c .

[0689] 1> Otherwise, if the carrier for the random access procedure is not explicitly transmitted:

[0690] 1> if the serving cell for the random access procedure is configured with a supplementary uplink as specified in TS 38.331 [5]; and

[0691] 1> If the RSRP referenced by the downlink path loss is less than rsrp-ThresholdSSB-SUL, then:

[0692] 2> Select the SUL carrier for performing the random access procedure;

[0693] 2> Set PCMAX to the P of the SUL carrier CMAX,f,c .

[0694] 1> Otherwise:

[0695] 2> Select NUL carrier for performing random access procedure;

[0696] 2> Set PCMAX to the P of NUL carrier CMAX,f,c .

[0697] 1>Perform the BWP operation as specified in clause 5.15;

[0698] 1> if the random access procedure is initiated by a PDCCH command and if the ra-PreambleIndex explicitly provided by the PDCCH is not 0b000000; or

[0699] 1> if a random access procedure is initiated for an SI request (as specified in TS 38.331 [5]) and the random access resources for the SI request have been explicitly provided by RRC; or

[0700] 1> if a Random Access procedure is initiated for Beam Failure Resilience (as specified in clause 5.17) and if contention-free Random Access resources for Beam Failure Resilience requests of type 4-step RA have been explicitly provided by RRC for the BWP selected for the Random Access procedure; or

[0701] 1> If the random access procedure is initiated for synchronous reconfiguration and if contention-free random access resources for 4-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for the random access procedure, then:

[0702] 2> Set RA_TYPE to 4-stepRA.

[0703] 1> Otherwise, if the BWP selected for the random access procedure is configured with 2-step and 4-step RA type random access resources and the RSRP referenced by the downlink path loss is higher than msgA-RSRP-Threshold; or

[0704] 1> if the BWP selected for the random access procedure is configured with only 2-step RA type random access resources (i.e., 4-step RACH RA type resources are not configured); or

[0705] 1> If the random access procedure is initiated for synchronous reconfiguration and if contention-free random access resources for 2-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for the random access procedure, then:

[0706] 2> Set RA_TYPE to 2-stepRA.

[0707] 1> Otherwise:

[0708] 2> Set RA_TYPE to 4-stepRA.

[0709] 1> Perform initialization of variables specific to the random access type as specified in clause 5.1.1a;

[0710] 1> If RA_TYPE is set to 2-stepRA, then:

[0711] 2> Perform the random access resource selection procedure for 2-step RA type (see clause 5.1.2a).

[0712] 1> Otherwise:

[0713] 2> Perform random access resource selection procedure (see clause 5.1.2).

[0714] […]

[0715] 5.1.2 Random Access Resource Selection

[0716] If the selected RA_TYPE is set to 4-stepRA, the MAC entity shall:

[0717] 1> If a random access procedure is initiated for SpCell beam failure recovery (as specified in clause 5.17); and

[0718] 1> if beamFailureRecoveryTimer (clause 5.17) is running or not configured; and

[0719] 1> if contention-free random access resources for beam failure recovery requests associated with any of the SSB and / or CSI-RS have been explicitly provided by RRC; and

[0720] 1> If at least one of an SSB with an SS-RSRP higher than rsrp-ThresholdSSB among the SSBs in candidateBeamRSList or a CSI-RS with a CSI-RSRP higher than rsrp-ThresholdCSI-RS among the CSI-RSs in candidateBeamRSList is available, then:

[0721] 2> Select an SSB with an SS-RSRP higher than rsrp-ThresholdSSB among the SSBs in candidateBeamRSList or a CSI-RS with a CSI-RSRP higher than rsrp-ThresholdCSI-RS among the CSI-RSs in candidateBeamRSList;

[0722] 2> If CSI-RS is selected and there is no ra-PreambleIndex associated with the selected CSI-RS, then:

[0723] 3> Set PREAMBLE_INDEX to the ra-PreambleIndex corresponding to the SSB in candidateBeamRSList, which is quasi-co-located with the selected CSI-RS as specified in TS 38.214 [7].

[0724] 2> Otherwise:

[0725] 3> Set PREAMBLE_INDEX to the ra-PreambleIndex corresponding to the selected SSB or CSI-RS from a set of random access preambles for beam failure recovery request.

[0726] 1> Otherwise, if ra-PreambleIndex has been explicitly provided by PDCCH; and

[0727] 1> If ra-PreambleIndex is not 0b000000, then:

[0728] 2> Set PREAMBLE_INDEX to the transmitted ra-PreambleIndex;

[0729] 2> Select the SSB transmitted by PDCCH.

[0730] 1> Otherwise, if the contention-free random access resource associated with the SSB has been explicitly provided in rach-ConfigDedicated, and at least one SSB among the associated SSBs with an SS-RSRP higher than rsrp-ThresholdSSB is available, then:

[0731] 2> Select the SSB with SS-RSRP higher than rsrp-ThresholdSSB among the associated SSBs;

[0732] 2> Set PREAMBLE_INDEX to the ra-PreambleIndex corresponding to the selected SSB.

[0733] 1> Otherwise, if the contention-free random access resource associated with the CSI-RS has been explicitly provided in rach-ConfigDedicated, and at least one CSI-RS with a CSI-RSRP higher than rsrp-ThresholdCSI-RS among the associated CSI-RS is available, then:

[0734] 2> Select a CSI-RS with a CSI-RSRP higher than rsrp-ThresholdCSI-RS among the associated CSI-RS;

[0735] 2> Set PREAMBLE_INDEX to the ra-PreambleIndex corresponding to the selected CSI-RS.

[0736] 1> Otherwise, if a random access procedure is initiated for an SI request (as specified in TS 38.331 [5]); and

[0737] 1> If the random access resources for the SI request have been explicitly provided by RRC:

[0738] 2> If at least one of the SSBs with SS-RSRP higher than rsrp-ThresholdSSB is available, then:

[0739] 3> Select an SSB with SS-RSRP higher than rsrp-ThresholdSSB.

[0740] 2> Otherwise:

[0741] 3>Select Any SSB.

[0742] 2> Select the random access preamble corresponding to the selected SSB from the random access preambles determined according to ra-PreambleStartIndex as specified in TS 38.331 [5];

[0743] 2> Set PREAMBLE_INDEX to the selected random access preamble.

[0744] 1> Otherwise (i.e., for contention-based random access preamble selection):

[0745] 2> If at least one of the SSBs with SS-RSRP higher than rsrp-ThresholdSSB is available, then:

[0746] 3> Select an SSB with SS-RSRP higher than rsrp-ThresholdSSB.

[0747] 2> Otherwise:

[0748] 3>Select Any SSB.

[0749] 2> If RA_TYPE is switched from 2-stepRA to 4-stepRA:

[0750] 3> If a random access preamble group is selected during the current random access procedure, then:

[0751] 4> Select the same random access preamble group as the random access preamble group selected for the 2-step RA type.

[0752] 3> Otherwise:

[0753] 4> If random access preamble group B is configured; and

[0754] 4> If the transport block size of the MSGA payload configured in rach-ConfigDedicated corresponds to the transport block size of the MSGA payload associated with random access preamble group B, then:

[0755] 5> Select random access preamble group B.

[0756] 4> Otherwise:

[0757] 5> Select random access preamble group A.

[0758] 2> Otherwise, if the Msg3 buffer is empty:

[0759] 3> If random access preamble group B is configured:

[0760] 4> If the potential Msg3 size (e.g., UL data available for transmission plus MAC header and MAC CE if required) is greater than ra-Msg3SizeGroupA and the path loss is less than PCMAX-preambleReceivedTargetPower-msg3-DeltaPreamble-messagePowerOffsetGroupB (of the serving cell performing the random access procedure); or

[0761] 4> If a random access procedure is initiated for the CCCH logical channel and the CCCH SDU size plus the MAC subheader is greater than ra-Msg3SizeGroupA, then:

[0762] 5> Select random access preamble group B.

[0763] 4> Otherwise:

[0764] 5> Select random access preamble group A.

[0765] 3> Otherwise:

[0766] 4> Select random access preamble group A.

[0767] 2> Otherwise (that is, Msg3 is retransmitted):

[0768] 3> Select the same random access preamble group as the random access preamble transmission attempt used for the first transmission corresponding to Msg3.

[0769] 2> randomly select a random access preamble from the random access preambles associated with the selected SSB and the selected random access preamble group with equal probability;

[0770] 2> Set PREAMBLE_INDEX to the selected random access preamble.

[0771] 1> if a random access procedure is initiated for an SI request (as specified in TS 38.331 [5]); and

[0772] 1> If ra-AssociationPeriodIndex and si-RequestPeriod are configured, then:

[0773] 2> Determine the next available PRACH opportunity from the PRACH opportunity corresponding to the selected SSB in the association period given by ra-AssociationPeriodIndex in si-RequestPeriod permitted by the restrictions given by ra-ssb-OccasionMaskIndex (if configured) (the MAC entity shall randomly select the PRACH opportunity among consecutive PRACH opportunities with equal probability according to clause 8.1 of TS 38.213 [6] corresponding to the selected SSB).

[0774] 1> Otherwise, if SSB is selected as above, then:

[0775] 2> Determine the next available PRACH opportunity based on the PRACH opportunity corresponding to the selected SSB given by ra-ssb-OccasionMaskIndex (if configured) or permitted by the restrictions indicated by the PDCCH (the MAC entity shall randomly select the PRACH opportunity among the consecutive PRACH opportunities corresponding to the selected SSB with equal probability according to clause 8.1 of TS 38.213 [6]; the MAC entity may consider the possible occurrence of measurement gaps when determining the next available PRACH opportunity corresponding to the selected SSB).

[0776] 1> Otherwise, if CSI-RS is selected as above:

[0777] 2> If there is no contention-free random access resource associated with the selected CSI-RS, then:

[0778] 3> Determine the next available PRACH opportunity based on the PRACH opportunities corresponding to the SSB in candidateBeamRSList that is quasi-co-located with the selected CSI-RS as specified in TS 38.214 [7] as permitted by the restrictions given by ra-ssb-OccasionMaskIndex (if configured) (the MAC entity shall randomly select the PRACH opportunity among the consecutive PRACH opportunities corresponding to the SSB that is quasi-co-located with the selected CSI-RS with equal probability according to clause 8.1 of TS 38.213 [6]; the MAC entity may consider the possible occurrence of measurement gaps when determining the next available PRACH opportunity corresponding to the SSB that is quasi-co-located with the selected CSI-RS).

[0779] 2> Otherwise:

[0780] 3> Determine the next available PRACH opportunity based on the PRACH opportunity corresponding to the selected CSI-RS in the ra-OccasionList (the MAC entity will randomly select a PRACH opportunity from the PRACH opportunities corresponding to the selected CSI-RS that appear simultaneously but on different subcarriers with equal probability; the MAC entity may consider the possible occurrence of measurement gaps when determining the next available PRACH opportunity corresponding to the selected CSI-RS).

[0781] 1> Perform the random access preamble transmission procedure (see clause 5.1.3).

[0782] NOTE 1: When the UE determines whether there is an SSB with SS-RSRP higher than rsrp-ThresholdSSB or a CSI-RS with CSI-RSRP higher than rsrp-ThresholdCSI, the UE uses the latest unfiltered L1-RSRP measurement.

[0783] […]

[0784] 5.1.3 Random Access Preamble Transmission

[0785] For each random access preamble, the MAC entity shall:

[0786] 1> If PREAMBLE_TRANSMISSION_COUNTER is greater than one; and

[0787] 1> If the notification to suspend the power ramp counter has not been received from the lower layer; and

[0788] 1> if no LBT failure indication is received from lower layers for the last random access preamble transmission; and

[0789] 1> If the selected SSB or CSI-RS has not changed from the selection in the last random access preamble transmission, then:

[0790] 2>Increase PREAMBLE_POWER_RAMPING_COUNTER by 1.

[0791] 1> Select the value of DELTA_PREAMBLE according to clause 7.3;

[0792] 1>Set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower+DELTA_PREAMBLE+(PREAMBLE_POWER_RAMPING_COUNTER-1)×PREAMBLE_POWER_RAMPING_STEP+POWER_OFFSET_2STEP_RA;

[0793] 1> Calculate the RA-RNTI associated with the PRACH opportunity in which the random access preamble is transmitted, except for the contention-free random access preamble used for beam failure recovery request;

[0794] 1> Instructs the physical layer to transmit a random access preamble using the selected PRACH opportunity, the corresponding RA-RNTI (if available), PREAMBLE_INDEX and PREAMBLE_RECEIVED_TARGET_POWER.

[0795] 1> If an LBT failure indication is received from the lower layer for this random access preamble transmission:

[0796] 2> If lbt-FailureRecoveryConfig is configured, then:

[0797] 3> Perform random access resource selection procedure (see clause 5.1.2).

[0798] 2> Otherwise:

[0799] 3>Increase PREAMBLE_TRANSMISSION_COUNTER by 1;

[0800] 3>If PREAMBLE_TRANSMISSION_COUNTER=preambleTransMax+1:

[0801] 4> If the random access preamble is transmitted on the SpCell, then:

[0802] 5>Indicate random access problem to upper layer;

[0803] 5> If this random access procedure is triggered for an SI request, then:

[0804] 6> The random access procedure is considered to have not been completed successfully.

[0805] 4> Otherwise, if the random access preamble is transmitted on the SCell, then:

[0806] 5> The random access procedure is considered to have not been completed successfully.

[0807] 3> If the random access procedure is not completed, then:

[0808] 4> Perform random access resource selection procedure (see clause 5.1.2).

[0809] The RA-RNTI associated with the PRACH opportunity in which the random access preamble is transmitted is calculated as:

[0810] RA-RNTI=1+s_id+14×t_id+14×80×f_id+14×80×8×ul_carrier_id

[0811] where s_id is the index of the first OFDM symbol of the PRACH opportunity (0≤s_id<14), t_id is the index of the first time slot of the PRACH opportunity in the system frame (0≤t_id<80), where the subcarrier spacing determining t_id is based on the value of μ specified in clause 5.3.2 of TS38.211 [8], f_id is the index of the PRACH opportunity in the frequency domain (0≤f_id<8), and ul_carrier_id is the UL carrier used for random access preamble transmission (0 for NUL carrier and 1 for SUL carrier).

[0812] […]

[0813] 5.1.4 Random Access Response Reception

[0814] Once the random access preamble is transmitted, regardless of whether measurement gaps may occur, the MAC entity shall:

[0815] 1> If the contention-free random access preamble for beam failure recovery request is transmitted by the MAC entity, then:

[0816] 2> Starting the ra-ResponseWindow configured in BeamFailureRecoveryConfig at the first PDCCH opportunity as specified in TS 38.213 [6] from the end of the random access preamble transmission;

[0817] 2> When ra-ResponseWindow is running, listen to PDCCH transmission on the search space indicated by recoverySearchSpaceId of the SpCell identified by C-RNTI.

[0818] 1> Otherwise:

[0819] 2> Starting the ra-ResponseWindow configured in RACH-ConfigCommon at the first PDCCH opportunity as specified in TS 38.213 [6] from the end of the random access preamble transmission;

[0820] 2> When ra-ResponseWindow is running, monitor the PDCCH of SpCell for random access responses identified by RA-RNTI.

[0821] 1> If a notification is received from lower layers on the serving cell where the preamble is transmitted that a PDCCH transmission is received on the search space indicated by recoverySearchSpaceId; and

[0822] 1> if the PDCCH transmission is addressed to the C-RNTI; and

[0823] 1> If the contention-free random access preamble for beam failure recovery request is transmitted by the MAC entity, then:

[0824] 2> The random access procedure is considered to be completed successfully.

[0825] 1> Otherwise, if a valid (as specified in TS 38.213 [6]) downlink assignment has been received on the PDCCH for the RA-RNTI and the received TB was successfully decoded:

[0826] 2> If the random access response contains a MAC sub-PDU with a backoff indicator, then:

[0827] 3> Using Table 7.2-1, set PREAMBLE_BACKOFF to the value of the BI field of the MAC sub-PDU multiplied by SCALING_FACTOR_BI.

[0828] 2> Otherwise:

[0829] 3> Set PREAMBLE_BACKOFF to 0ms.

[0830] 2> If the Random Access Response contains a MAC sub-PDU with a Random Access Preamble identifier corresponding to the transmitted PREAMBLE_INDEX (see clause 5.1.3), then:

[0831] 3> This random access response is considered to be received successfully.

[0832] 2> If the random access response is considered to be received successfully:

[0833] 3> If the Random Access Response contains a MAC sub-PDU with only RAPID, then:

[0834] 4> The random access procedure is considered to be successfully completed;

[0835] 4>Indicate to the upper layer that confirmation of SI request has been received.

[0836] 3> Otherwise:

[0837] 4> Apply the following actions for the serving cell in which the random access preamble is transmitted:

[0838] 5> Process the received timing advance command (see clause 5.2);

[0839] 5> Indicates to the lower layer the preambleReceivedTargetPower and the power ramp applied to the latest random access preamble transmission (i.e. (PREAMBLE_POWER_RAMPING_COUNTER-1)×PREAMBLE_POWER_RAMPING_STEP);

[0840] 5> If the random access procedure for the SCell is performed on an uplink carrier in which pusch-Config is not configured, then:

[0841] 6> Ignore the received UL grant.

[0842] 5> Otherwise:

[0843] 6> Process the received UL grant value and indicate the value to the lower layers.

[0844] 4> If the MAC entity does not select a random access preamble among the contention-based random access preambles, then:

[0845] 5> The random access procedure is considered to be completed successfully.

[0846] 4> Otherwise:

[0847] 5> Set TEMPORARY_C-RNTI to the value received in the Random Access Response; 5> If this is the first successfully received Random Access Response within this Random Access procedure:

[0848] 6> If no transmission is performed for the CCCH logical channel, then:

[0849] 7> Indicate to the multiplexing and combining entity to include the C-RNTI MAC CE in subsequent uplink transmissions.

[0850] 6> If a random access procedure is initiated for SpCell beam failure recovery, then:

[0851] 7> Indicate to the multiplexing and combining entity to include the BFR MAC CE or the truncated BFR MAC CE in subsequent uplink transmissions.

[0852] 6> Get the MAC PDU for transmission from the multiplexing and combining entity and store it in the Msg3 buffer.

[0853] NOTE: If within a random access procedure, the uplink grant provided in a random access response for the same group of contention based random access preambles has a different size than the first uplink grant allocated during the random access procedure, the UE behavior is not restricted.

[0854] 1> if the ra-ResponseWindow configured in BeamFailureRecoveryConfig expires and if a PDCCH transmission on the search space indicated by recoverySearchSpaceId addressed to the C-RNTI has not been received on the serving cell in which the preamble was transmitted; or

[0855] 1> If the ra-ResponseWindow configured in RACH-ConfigCommon expires and if a Random Access Response containing a Random Access Preamble identifier matching the transmitted PREAMBLE_INDEX has not been received, then:

[0856] 2> The random access response reception is considered unsuccessful;

[0857] 2>Increase PREAMBLE_TRANSMISSION_COUNTER by 1;

[0858] 2>If PREAMBLE_TRANSMISSION_COUNTER=preambleTransMax+1:

[0859] 3> If the random access preamble is transmitted on the SpCell, then:

[0860] 4>Indicate random access problems to the upper layer;

[0861] 4> If this random access procedure is triggered for an SI request, then:

[0862] 5> The random access procedure is considered to have not been completed successfully.

[0863] 3> Otherwise, if the random access preamble is transmitted on the SCell, then:

[0864] 4> The random access procedure is considered to have not been completed successfully.

[0865] 2> If the random access procedure is not completed, then:

[0866] 3> Select a random backoff time based on a uniform distribution between 0 and PREAMBLE_BACKOFF;

[0867] 3> If the criteria for selecting a contention-free random access resource (as defined in clause 5.1.2) are met during the backoff time, then:

[0868] 4>Perform the random access resource selection procedure (see clause 5.1.2);

[0869] 3> Otherwise, if the random access procedure for the SCell is performed on an uplink carrier in which pusch-Config is not configured, then:

[0870] 4> Delay subsequent random access transmission until the random access procedure is triggered by a PDCCH command with the same ra-PreambleIndex, ra-ssb-OccasionMaskIndex and UL / SUL indicator TS 38.212 [9].

[0871] 3> Otherwise:

[0872] 4> Perform the random access resource selection procedure after the backoff time (see clause 5.1.2).

[0873] After successfully receiving a Random Access Response containing a Random Access Preamble identifier matching the transmitted PREAMBLE_INDEX, the MAC entity may stop the ra-ResponseWindow (and therefore stop listening for Random Access Responses).

[0874] HARQ operation is not applicable for random access response reception.

[0875] […]

[0876] 5.1.5 Contention Resolution

[0877] Once Msg3 is transmitted, the MAC entity shall:

[0878] 1> At each HARQ retransmission in the first symbol after the end of Msg3 transmission, start ra-ContentionResolutionTimer and restart ra-ContentionResolutionTimer;

[0879] 1> Regardless of whether measurement gaps may occur, monitor PDCCH while ra-ContentionResolutionTimer is running;

[0880] 1> If a notification of receiving a PDCCH transmission from SpCell is received from the lower layer:

[0881] 2> If C-RNTI MAC CE is included in Msg3:

[0882] 3> if a random access procedure is initiated for SpCell beam failure recovery (as specified in clause 5.17) and the PDCCH transmission is addressed to the C-RNTI; or

[0883] 3> If the random access procedure is initiated by a PDCCH command and the PDCCH transmission is addressed to the C-RNTI; or

[0884] 3> If the random access procedure is initiated by the MAC sublayer itself or by the RRC sublayer and the PDCCH transmission is addressed to the C-RNTI and contains an UL grant for a new transmission, then:

[0885] 4> Consider this contention resolution as a success;

[0886] 4>Stop ra-ContentionResolutionTimer;

[0887] 4> discard TEMPORARY_C-RNTI;

[0888] 4> This random access procedure is considered to be completed successfully.

[0889] 2> Otherwise, if the CCCH SDU is contained in Msg3 and the PDCCH transmission is addressed to its TEMPORARY_C-RNTI:

[0890] 3> If the MAC PDU is successfully decoded, then:

[0891] 4>Stop ra-ContentionResolutionTimer;

[0892] 4> If the MAC PDU contains the UE contention resolution identity MAC CE; and

[0893] 4> If the UE contention resolution identity in the MAC CE matches the CCCH SDU transmitted in Msg3, then:

[0894] 5> The contention resolution is considered successful and the disassembly and demultiplexing of MAC PDU is terminated;

[0895] 5> If this random access procedure is initiated for an SI request, then:

[0896] 6>Indicate to the upper layer that confirmation of SI request has been received.

[0897] 5> Otherwise:

[0898] 6> Set C-RNTI to the value of TEMPORARY_C-RNTI;

[0899] 5> discard TEMPORARY_C-RNTI;

[0900] 5> This random access procedure is considered to be completed successfully.

[0901] 4> Otherwise:

[0902] 5> discard TEMPORARY_C-RNTI;

[0903] 5> Consider this contention resolution unsuccessful and discard the successfully decoded MAC PDU.

[0904] 1> If ra-ContentionResolutionTimer expires, then:

[0905] 2> discard TEMPORARY_C-RNTI;

[0906] 2>Content resolution is considered unsuccessful.

[0907] 1> If contention resolution is deemed unsuccessful, then:

[0908] 2> Clear the HARQ buffer in the Msg3 buffer used to transmit MAC PDU;

[0909] 2>Increase PREAMBLE_TRANSMISSION_COUNTER by 1;

[0910] 2> If PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1, then:

[0911] 3>Indicate random access problems to upper layers.

[0912] 3> If this random access procedure is triggered for an SI request, then:

[0913] 4> The random access procedure is considered to have not been completed successfully.

[0914] 2> If the random access procedure is not completed:

[0915] 3> If RA_TYPE is set to 4-stepRA, then:

[0916] 4> Select a random backoff time based on a uniform distribution between 0 and PREAMBLE_BACKOFF;

[0917] 4> If the criteria for selecting a contention-free random access resource (as defined in clause 5.1.2) are met during the backoff time, then:

[0918] 5>Perform the random access resource selection procedure (see clause 5.1.2);

[0919] 4> Otherwise:

[0920] 5> Perform the random access resource selection procedure after the backoff time (see clause 5.1.2).

[0921] 3> Otherwise (i.e., RA_TYPE is set to 2-stepRA):

[0922] 4> If msgA-TransMax applies (see clause 5.1.1a) and PREAMBLE_TRANSMISSION_COUNTER = msgA-TransMax+1, then:

[0923] 5> Set RA_TYPE to 4-stepRA;

[0924] 5> Perform initialization of variables specific to the random access type as specified in clause 5.1.1a;

[0925] 5> Clear the HARQ buffer in the MSGA buffer used to transmit MAC PDU;

[0926] 5> discard the explicitly transmitted contention-free 2-step RA type random access resources (if any);

[0927] 5> Perform random access resource selection as specified in clause 5.1.2.

[0928] 4> Otherwise:

[0929] 5> Select a random backoff time based on a uniform distribution between 0 and PREAMBLE_BACKOFF;

[0930] 5> If the criteria for selecting a contention-free random access resource (as defined in clause 5.1.2a) are met during the backoff time, then:

[0931] 6> Perform the Random Access Resource Selection procedure for the 2-step RA type as specified in clause 5.1.2a.

[0932] 5> Otherwise:

[0933] 6> Perform random access resource selection for a 2-step RA type procedure after the backoff time (see clause 5.1.2a).

[0934] 5.1.6 Completion of random access procedure

[0935] After the random access procedure is completed, the MAC entity shall:

[0936] 1> discard any explicitly transmitted contention-free random access resources for 2-step RA type and 4-step RA type, except for 4-step RA type contention-free random access resources for beam failure recovery request (if any);

[0937] 1> Clear the HARQ buffer in the Msg3 buffer and MSGA buffer used to transmit MAC PDU.

[0938] Upon successful completion of the Random Access procedure initiated for a DAPS handover, the target MAC entity shall:

[0939] 1> Indicates to the upper layer the successful completion of the random access procedure.

[0940] 3GPP TR 38.836 introduces the following:

[0941] 4 UE to network relay based on sidelink

[0942] 4.1 Scenarios, assumptions and requirements

[0943] UE-to-network relay enables coverage extension and power saving for remote UEs. The coverage scenarios considered in this study are as follows:

[0944] -UE to network relay UE is in coverage and remote UE is out of coverage

[0945] -UE to network relay UE and remote UE are both within coverage

[0946] - For L3 UE to network relay, after the remote UE establishes a connection via the relay UE, the relay UE and the remote UE can be in the same cell or in different cells.

[0947] - For L2 UE to network relay, as a baseline support, after the remote UE is connected via the relay UE, the relay UE and the remote UE are controlled by the serving cell of the relay UE

[0948] For L2 UE to network relay, the following two cases are supported, namely:

[0949] - Before making a remote connection via the relay UE, the relay UE and the remote UE are in the same cell;

[0950] - Before making a remote connection via the relay UE, the relay UE and the remote UE are in different cells;

[0951] The situation considered is Figure 4 .Reflected in 1-1.

[0952] [3GPP TR 38.836 V0.2.0 entitled "Scenarios for UE to Network Relay" Figure 4 .1-1 reproduced as Fig.13 ]

[0953] Assume that NR Uu is on the Uu link from UE to network relay UE. Assume that NR side link is on PC5 between remote UE and UE to network relay UE.

[0954] Cross-RAT configuration / control of UE (remote UE or UE to network relay UE) is not considered, that is, eNB / ng-eNB does not control / configure NR remote UE and UE to network relay UE. For UE to network relay, the study focuses on unicast data services between remote UE and NW.

[0955] The UE (remote UE or UE-to-network relay UE) is configured / scheduled by the SN to perform NR sidelink communications which are outside the scope of this study.

[0956] For UE-to-network relay, relaying of unicast data between the remote UE and the network may occur after a PC5-RRC connection is established between the relay UE and the remote UE.

[0957] The Uu RRC states of the relay UE and the remote UE may change when connected via PC5. The relay UE and the remote UE may perform relay discovery in any RRC state. The remote UE may perform relay discovery outside of Uu coverage.

[0958] The relay UE must be in RRC_CONNECTED to perform relay of unicast data.

[0959] For L2 UE to network relay:

[0960] - The remote UE must be in RRC CONNECTED to perform transmission / reception of relay unicast data.

[0961] -As long as all PC5 connected remote UEs are in RRC_IDLE, the relay UE can be in RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED.

[0962] - The relay UE may be in RRC_INACTIVE or RRC_CONNECTED as long as all PC5 connected remote UEs are in RRC_INACTIVE.

[0963] For L3 UE to network relay, both the relay UE and the remote UE may be in RRC_INACTIVE state.

[0964] In this release, the requirement for service continuity is only for UE-to-network relays, not for UE-to-UE relays.

[0965] RAN2 studies the mobility scenarios of "between direct (Uu) path and indirect (via relay) path" for UE to network relay. RAN2 focuses on the mobility scenarios for the intra-gNB case in the study phase, and assumes that the inter-gNB case will also be supported. For the inter-gNB case, the potential different parts on the Uu interface compared to the intra-gNB case may be studied in detail in the SI phase or the WI phase. RAN2 de-prioritizes the work specific to the mobility scenarios of "between indirect (via first relay UE) and indirect (via second relay UE)" for path switching in the SI phase, which may be studied in the WI phase if needed.

[0966] RAN2 de-prioritizes the group mobility context in the SI phase, which may be addressed in the WI phase if needed.

[0967] […]

[0968] 4.5 Layer 2 Relay

[0969] 4.5.1 Architecture and Protocol Stack

[0970] 4.5.1.1 Protocol Stack

[0971] For the case where the PC5 interface does not support the adaptation layer Figure 4 .5.1.1-1 and Figure 4 .5.1.1-2 and for the case where the PC5 interface supports the adaptation layer Figure 4 .5.1.1-3 and Figure 4 .5.1.1-4 describes the protocol stack for the user plane and control plane for the L2 UE to network relay architecture.

[0972] For L2 UE to network relay, the adaptation layer is placed above the RLC sublayer for CP and UP at the Uu interface between the relay UE and the gNB. The Uu SDAP / PDCP and RRC are terminated between the remote UE and the gNB, while the RLC, MAC and PHY are terminated in each link (i.e., the link between the remote UE and the UE to network relay UE and the link between the UE to network relay UE and the gNB). Whether the adaptation layer is also supported at the PC5 interface between the remote UE and the relay UE depends on the WI stage (assuming that the downward selection is made first before studying the detailed PC5 adaptation layer functions too much).

[0973] [3GPP TR 38.836 V0.2.0 entitled "User plane protocol stack for L2 UE to network relay (without support for adaptation layer at PC5 interface)" Figure 4 .5.1.1-1 Reproduced as Fig.14 ]

[0974] [3GPP TR 38.836 V0.2.0 entitled "Control plane protocol stack for L2 UE to network relay (without support for adaptation layer at PC5 interface)" Figure 4 .5.1.1-2 Reproduced as Fig.15 ]

[0975] [3GPP TR 38.836 V0.2.0 entitled "User plane protocol stack for L2 UE to network relay (supporting adaptation layer at PC5 interface)" Figure 4 .5.1.1-3 reproduced as Fig.16 ]

[0976] [ Figure 4 .5.1.1-4: User plane protocol stack for L2 UE to network relay (supporting adaptation layer at PC5 interface) is reproduced as Fig.17 ]

[0977] 4.5.1.2 Adaptation layer functions

[0978] For L2 UE to network relay, for uplink

[0979] - The Uu Adaptation Layer at the relay UE supports UL bearer mapping between the ingress PC5 RLC channel for relay and the egress Uu RLC channel on the relay UE Uu path. For uplink relay services, different end-to-end RBs (SRBs, DRBs) of the same remote UE and / or different remote UEs may be subject to N:1 mapping and data multiplexing on the Uu RLC channel.

[0980] -Use of Uu Adaptation Layer to support Remote UE Identification for UL traffic (multiplexing data from multiple remote UEs). Identity information of remote UE Uu radio bearers and remote UEs is included in the Uu Adaptation Layer at UL so that the gNB can correlate received data packets for a specific PDCP entity associated with the correct remote UE Uu radio bearer of the remote UE.

[0981] For L2 UE to network relay, for downlink

[0982] - The Uu Adaptation Layer may be used to support DL bearer mapping at the gNB to map the end-to-end radio bearers (SRBs, DRBs) of the remote UE into the Uu RLC channels on the relay UE Uu path. The Uu Adaptation Layer may be used to support DL N:1 bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRBs, DRBs) of the remote UE and / or different remote UEs and one Uu RLC channel on the relay UE Uu path.

[0983] - The Uu Adaptation Layer needs to support Remote UE Identification for downlink traffic. The identity information of the Remote UE Uu Radio Bearer and the identity information of the Remote UE need to be placed in the Uu Adaptation Layer by the gNB at DL so that the relay UE can map the packets received from the Remote UE Uu Radio Bearer to its associated PC5 RLC channel.

[0984] […]

[0985] 4.5.5 Control Plane Programs

[0986] Editor's note: CP procedures related to service continuity are mentioned in 4.5.4.

[0987] 4.5.5.1 Connection Management

[0988] The remote UE needs to establish its own PDU session / DRB with the network before user plane data transfer.

[0989] Before the remote UE establishes a Uu RRC connection with the network via the relay UE, the PC5-RRC aspects of the Rel-16 NR V2X PC5 unicast link establishment procedure may be reused to set up a secure unicast link between the remote UE and the relay UE for L2 UE to network relay.

[0990] For both in-coverage and out-of-coverage cases, when the remote UE initiates the first RRC message for its connection establishment with the gNB, the PC5 L2 configuration for transmission between the remote UE and the UE-to-network relay UE may be based on the RLC / MAC configuration defined in the specification.

[0991] The establishment of Uu SRB1 / SRB2 and DRBs for the remote UE is subject to the conventional Uu configuration procedure for L2 UE to network relay.

[0992] The following high-level connection establishment procedure applies to L2 UE to network relay:

[0993] [3GPP TR 38.836 V0.2.0 entitled "Procedures for remote UE connection establishment" Figure 4 .5.5.1-1 Reproduced as Fig.18 ]

[0994] Step 1. The remote and relay UEs perform a discovery procedure and establish a PC5-RRC connection using the legacy Rel-16 procedure as a baseline.

[0995] Step 2. The remote UE sends a first RRC message (i.e., RRCSetupRequest) via the relay UE for its connection establishment with the gNB, using the preset L2 configuration on PC5. The gNB responds to the remote UE with an RRCSetup message. The RRCSetup delivery to the remote UE uses the preset configuration on PC5. If the relay UE has not been started with RRC_CONNECTED, it will need to perform its own connection establishment as part of this step. The details of the relay UE forwarding the RRCSetupRequest / RRCSetup message for the remote UE at this step can be discussed in the WI phase.

[0996] Step 3. gNB and relay UE perform relay channel setup procedure via Uu. Based on the configuration from gNB, relay / remote UE establishes RLC channel for relay of SRB1 towards remote UE through PC5. This step prepares relay channel for SRB1.

[0997] Step 4. The remote UE SRB1 message (e.g., RRCSetupComplete message) is sent to the gNB via the relay UE using the SRB1 relay channel on PC5. The remote UE then connects RRC via Uu.

[0998] Step 5. The remote UE and gNB follow conventional procedures to establish security and the security message is forwarded by the relay UE.

[0999] Step 6. The gNB sets up an additional RLC channel between the gNB and the relay UE for service relay. Based on the configuration from the gNB, the relay / remote UE sets up an additional RLC channel between the remote UE and the relay UE for service relay. The gNB sends RRCReconfiguration to the remote UE via the relay UE to set up the relay SRB2 / DRB. The remote UE sends RRCReconfigurationComplete to the gNB via the relay UE as a response.

[1000] In addition to the connection establishment procedure, for L2 UE to network relay,

[1001] -RRC reconfiguration and RRC connection release procedures can reuse the traditional RRC procedures, where the message content / configuration design depends on the WI phase.

[1002] -RRC connection re-establishment and RRC connection recovery procedures can reuse the conventional RRC procedures as a baseline by handling the relay specific parts by considering the above connection establishment procedures of L2 UE to network relay, where the message content / configuration design depends on the WI phase.

[1003] 3GPP TS 23.287 introduces the following:

[1004] 6.3.3 Unicast Mode V2X Communication via PC5 Reference Point

[1005] 6.3.3.1 Layer 2 link establishment over PC5 reference point

[1006] For unicast mode of V2X communication performed over the PC5 reference point, the UE is configured with the relevant information as described in clause 5.1.2.1.

[1007] Figure 6 .3.3.1-1 shows the Layer 2 link establishment procedure for unicast mode of V2X communication over the PC5 reference point.

[1008] [3GPP TS 23.287 V16.4.0 entitled "Layer 2 Link Establishment Procedure" Figure 6 .3.3.1-1 Reproduced as Fig.19 ]

[1009] 1. As specified in clause 5.6.1.4, the UE determines the destination Layer 2 ID for signaling reception for PC5 unicast link establishment. As specified in clause 5.1.2.1, the destination Layer 2 ID is configured with the UE.

[1010] 2. The V2X application layer in UE-1 provides application information for PC5 unicast communication. The application information includes the V2X service type and the application layer ID of the initiating UE. The application information may include the application layer ID of the target UE.

[1011] The V2X application layer in UE-1 may provide the V2X application requirements for this unicast communication. As specified in clause 5.4.1.4, UE-1 determines the PC5 QoS parameters and PFI.

[1012] If UE-1 decides to reuse the existing PC5 unicast link as specified in clause 5.2.1.4, the UE triggers the Layer 2 Link Modification procedure as specified in clause 6.3.3.4.

[1013] 3. UE-1 sends a direct communication request message to initiate the unicast layer 2 link establishment procedure. The direct communication request message contains:

[1014] - Source user information: the application layer ID of the originating UE (ie, the application layer ID of UE-1).

[1015] - If the V2X application layer provides the target UE’s application layer ID in step 2, the following information is included:

[1016] - Target user information: Application layer ID of the target UE (ie, the application layer ID of UE-2).

[1017] - V2X service information: Information about the type of V2X service for which Layer 2 link establishment is requested.

[1018] - Security information: information used to establish security.

[1019] NOTE 1: Security information and the necessary protection of source user information and destination user information are defined in TS 33.536

[26] .

[1020] As specified in clauses 5.6.1.1 and 5.6.1.4, the source layer 2ID and destination layer 2ID used to send the direct communication request message are determined. The destination layer 2ID can be a broadcast or unicast layer 2ID. When a unicast layer 2ID is used, the target user information shall be included in the direct communication request message.

[1021] UE-1 sends a direct communication request message via PC5 by broadcast or unicast using the source layer 2ID and the destination layer 2ID.

[1022] 4. Establish security for UE-1 as follows:

[1023] 4a. If the target user information is included in the direct communication request message, the target UE, ie, UE-2, responds by establishing security with UE-1.

[1024] 4b. If the target user information is not included in the direct communication request message, the UE interested in the notified V2X service type using the PC5 unicast link with UE-1 responds by establishing security with UE-1.

[1025] NOTE 2: Signalling for security procedures is defined in TS 33.536

[26] .

[1026] When security protection is enabled, UE-1 sends the following information to the target UE:

[1027] - If using IP communication:

[1028] -IP address configuration: For IP communication, this link requires an IP address configuration, and the IP address configuration indicates one of the following values:

[1029] - "IPv6 router", if the IPv6 address allocation mechanism is supported by the originating UE, i.e. acts as an IPv6 router; or

[1030] - "IPv6 address allocation not supported" if the IPv6 address allocation mechanism is not supported by the originating UE.

[1031] - Link-local IPv6 address: If UE-1 does not support the IPv6 IP address allocation mechanism, i.e., the IP address configuration indicates "does not support IPv6 address allocation", a link-local IPv6 address is formed locally based on Request For Comments (RFC) 4862

[21] .

[1032] -QoS Information: Information about the PC5 QoS flow to be added. For each PC5 QoS flow, PFI, corresponding PC5 QoS parameters (ie, PQI and conditional other parameters, such as MFBR / GFBR, etc.) and associated V2X service type.

[1033] The source Layer 2 ID for the security establishment procedure is determined as specified in clauses 5.6.1.1 and 5.6.1.4. The destination Layer 2 ID is set to the source Layer 2 ID of the received direct communication request message.

[1034] Upon receiving the Security Setup Procedure message, UE-1 obtains the Layer 2 ID of the peer UE for signaling and data traffic of this unicast link for future communications.

[1035] 5. One or more target UEs that have successfully established security with UE-1 send a direct communication acceptance message to UE-1:

[1036] 5a. (Layer 2 link establishment towards UE) If the direct communication request message contains target user information, then if the application layer ID for UE-2 matches, the target UE, i.e. UE-2, responds with a direct communication accept message.

[1037] 5b. (Layer 2 Link Establishment for V2X Services) If the Direct Communication Request message does not contain target user information, the UE interested in using one or more notified V2X services (in Figure 6 .UE-2 and UE-4 in 3.3.1-1) respond to the request by sending a direct communication accept message.

[1038] The direct communication acceptance message contains:

[1039] -Source user information: the application layer ID of the UE that sends the direct communication acceptance message.

[1040] -QoS Information: Information about the PC5 QoS flows requested by UE-1. For each PC5 QoS flow, PFI, corresponding PC5 QoS parameters (i.e., PQI and conditionally other parameters, such as MFBR / GFBR, etc.) and associated V2X service type.

[1041] - If using IP communication:

[1042] -IP address configuration: For IP communication, this link requires an IP address configuration, and the IP address configuration indicates one of the following values:

[1043] - "IPv6 router", if the IPv6 address allocation mechanism is supported by the target UE, i.e. act as an IPv6 router; or

[1044] - "IPv6 address allocation not supported" if the IPv6 address allocation mechanism is not supported by the target UE.

[1045] - Link-local IPv6 address: If the target UE does not support the IPv6 IP address allocation mechanism, i.e. the IP address configuration indicates "IPv6 address allocation is not supported", and UE-1 includes a link-local IPv6 address in the Direct Communication Request message, a link-local IPv6 address is formed locally based on RFC4862

[21] . The target UE shall include a non-conflicting link-local IPv6 address.

[1046] If both UEs (ie, the initiating UE and the target UE) are selected to use link-local IPv6 addresses, they shall deactivate dual address detection as defined in RFC 4862

[21] .

[1047] NOTE 3: When the initiating UE or the target UE indicates support for IPv6 routers, the corresponding address configuration procedure shall be performed after the layer 2 link is established and the link-local IPv6 address shall be ignored.

[1048] The V2X layer of the UE of the established PC5 unicast link passes the PC5 link identifier and PC5 unicast link related information allocated for the unicast link down to the AS layer. The PC5 unicast link related information includes layer 2 ID information (i.e., source layer 2 ID and destination layer 2 ID) and corresponding PC5 QoS parameters. This enables the AS layer to save the PC5 link identifier and PC5 unicast link related information.

[1049] 6. The V2X service data is transmitted via the established unicast link as follows:

[1050] The PC5 link identifier and PF are provided to the AS layer together with the V2X service data.

[1051] Additionally, layer 2 ID information (ie, source layer 2 ID and destination layer 2 ID) is optionally provided to the AS layer.

[1052] NOTE 4: It is up to the UE implementation to provide the Layer 2 ID information to the AS layer.

[1053] UE-1 sends V2X service data using a source Layer 2 ID (i.e., the Layer 2 ID of UE-1 for this unicast link) and a destination Layer 2 ID (i.e., the Layer 2 ID of the peer UE for this unicast link).

[1054] NOTE 5: The PC5 unicast link is bidirectional, so UE-1’s peer UE can send V2X service data to UE-1 via the unicast link with UE-1.

[1055] According to 3GPP TR 23.752, UE-to-network relay communication is studied for UE to access the network via indirect network communication. Basically, Rel-16 5G architecture design (e.g., flow-based quality of service (QoS) communication via PC5 / Uu interface) can be considered. In the scenario of UE-to-network relay communication, the remote UE will access the network (e.g., 5GC) via the relay UE, where the remote UE will be out of coverage and the relay UE will be within coverage. The remote UE will communicate with the relay UE via the PC5 interface (or called the side link interface) for accessing the network, and the relay UE will communicate with the base station (e.g., gNB) via the Uu interface for forwarding services between the remote UE and the network.

[1056] According to 3GPP TR 38.836, an adaptation layer may be introduced for supporting sidelink relay communications. For Layer 2 (L2) UE to network relay, an adaptation layer may be placed on the radio link channel (RLC) sublayer for both CP and UP at the Uu interface between the relay UE and the gNB. The Uu Service Data Adaptation Protocol (SDAP) / Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) terminate between the remote UE and the gNB, while the RLC, Media Access Control (MAC) and Physical Layer (PHY) terminate in each link (i.e., the link between the remote UE and the UE to network relay UE and the link between the UE to network relay UE and the gNB). It may be Fig. 20 Shown in.

[1057] On the other hand, according to 3GPP TR 38.836, the Uu adaptation layer will also support the use of Uu signal radio bearers (SRBs) (including, for example, Uu SRB0, Uu SRB1, Uu SRB2 and / or the like). However, it is not clear whether the PC5 adaptation layer will also support the use of Uu SRBs. It is speculated that the PC5 adaptation layer will also support the use of Uu SRBs.

[1058] Fig.21 An example of the association between the Uu SRB, PC5 RLC channel and Uu RLC channel according to one embodiment is shown. Fig.21 In the example, each Uu SRB can be associated with a PC5 RLC channel (i.e., Fig.21 1), and each PC5 RLC channel can be associated with one Uu RLC channel (ie, Fig.21 2). Therefore, each UuRLC channel will be associated with one Uu SRB (i.e., Fig.21 3). Through the mapping information, the gNB can know on which Uu RLC channel the RRC message received from the relay UE is sent based on which Uu SRB the RRC message is received on. Similarly, the relay UE can know on which PC5 RLC channel the RRC message received from the gNB is sent based on which Uu RLC channel the RRC message is received on. Similarly, the remote UE can know on which Uu SRB the RRC message received from the relay UE is sent based on which PC5 RLC channel the RRC message is received on. The association or mapping between the PC5 RLC channel, the Uu RLC channel and the Uu SRB may be predefined or preconfigured in the UE.

[1059] If each Uu RLC channel can be associated with a remote UE, the gNB and the relay UE can further know which Uu SRB of which remote UE the RRC message is sent on. Through the mapping information, based on the association between the remote UE and the Uu RLC channel and the association between the Uu SRB and the Uu RLC channel used to receive the RRC message, the gNB can know which Uu SRB the RRC message received from the relay UE is sent on and is associated with which remote UE. Similarly, based on the association between the remote UE and the Uu RLC channel and the association between the PC5 RLC channel and the Uu RLC channel used to receive the RRC message, the relay UE can know which PC5 RLC channel of which remote UE the RRC message received from the gNB will be sent on.

[1060] According to 3GPP TR 38.836, both remote UE and relay UE may be in RRC_INACTIVE state. If all remote UEs connected to or served by this relay UE are not in RRC_CONNECTED, the relay UE may enter RRC_INACTIVE (from RRC_CONNECTED). The relay UE entering RRC_INACTIVE may be based on the average value of receiving RRCRelease messages from the gNB.

[1061] In the event that the remote UE needs to enter RRC_CONNECTED, the remote UE may send a RRCResumeRequest message on the remote UE's Uu SRB0. The remote UE may send the RRCResumeRequest message to the relay UE on the PC5 RLC channel associated with the remote UE's Uu SRB0. After receiving a common control channel (CCCH) service data unit (SDU) (containing the RRCResumeRequest) or a RRCResumeRequest on the PC5 RLC channel corresponding to the remote UE's Uu SRB0, the relay UE may then initiate a random access (RA) procedure with the gNB. In the RA procedure, the relay UE may send the remote UE's RRCResumeRequest to the gNB in ​​Msg3 and receive the remote UE's RRCResume from the gNB in ​​Msg4. The relay UE may then send the remote UE's RRCResume to the remote UE on the PC5 RLC channel associated with the remote UE's Uu SRB1.

[1062] As introduced in 3GPP TS 38.331, the remote UE may receive RRCResume and then enter RRC_CONNECTED. The remote UE may then send RRCResumeComplete to the relay UE on the PC5 RLC channel associated with the remote UE's Uu SRB1. Since the remote UE enters RRC_CONNECTED, the relay UE may need to enter RRC_CONNECTED for relaying the remote UE's traffic. The gNB may send a page to the relay UE. In response to receiving the page for the relay UE, the relay UE may initiate an RRC connection recovery procedure with the gNB via a random access procedure. This concept may be described in 3GPP TS 38.331. Fig.23 Option 1 of , which shows an example of a flowchart for a relay UE to perform a RA procedure to enter RRC_CONNECTED in response to a remote UE entering RRC_CONNECTED according to one embodiment.

[1063] However, since the UE cannot perform two RA procedures simultaneously, it is possible that the UE will abort the currently ongoing RA procedure and subsequently initiate another RA procedure based on the UE implementation. If this is the case, it will be difficult for the gNB to trigger the relay UE to initiate the second RA procedure for the relay UE entering RRC_CONNECTED via paging, because the gNB may not know whether the first RA procedure for the remote UE entering RRC_CONNECTED has been successfully completed. Therefore, an alternative scheme for the relay UE to enter RRC_CONNECTED may be: when / if / after the relay UE receives a sidelink packet (containing the remote UE's RRC signaling / message, such as RRCResumeComplete for completing the resumption of the RRC connection between the remote UE and the gNB) from the remote UE on the PC5 RLC channel associated with the remote UE's Uu SRB1 / 2 (or the remote UE's Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED) or thereafter, the relay UE may perform or initiate the RRC connection resumption procedure with the gNB.

[1064] Alternatively, the relay UE may perform / initiate the RRC connection recovery procedure with the gNB when / if / when the relay UE sends data (including RRC signaling / messages of the remote UE, such as RRCResumeComplete for completing the recovery of the RRC connection between the remote UE and the gNB) to the gNB on or after the Uu RLC channel associated with the remote UE's Uu SRB1 / 2 (or the remote UE's Uu SRB used by the remote UE to transmit RRC signaling in RRC_CONNECTED). This alternative may be feasible because the RRC signaling sent from the UE to the gNB on Uu SRB1 / 2 implies that the UE is in RRC_CONNECTED. With this alternative, the relay UE may send the relay UE's RRCResumeRequest to the gNB on the relay UE's Uu SRB0. Transmitting the relay UE's RRCResumeReqeust or a CCCH SDU containing the relay UE's RRCResumeReqeust may trigger the relay UE to initiate the RA procedure with the gNB.

[1065] Fig. 22 FIG. 2 shows an exemplary flow chart of a UE performing a RA procedure for RRC state transition based on TS38.321 and TS38.331 according to an embodiment. Fig. 22As shown in , the relay UE may receive the relay UE's RRCResume (in Msg4) corresponding to the relay UE's RRCResumeRequest from the gNB, and may then transmit the relay UE's RRCResumeComplete corresponding to the relay UE's RRCResume to the gNB after successfully completing the RA procedure. After the relay UE enters RRC_CONNECTED, the relay UE may then transmit the remote UE's RRCResumeComplete to the gNB on the Uu RLC channel associated with the remote UE's Uu SRB1. The above concepts can be seen in Fig.23 Option 2 is shown.

[1066] It is also possible that the remote UE is in RRC_IDLE and the relay UE is in RRC_INACTIVE. Therefore, when / if / when the relay UE receives a sidelink packet (containing the remote UE's RRC signaling / message, such as RRCSetupComplete for completing the establishment of the RRC connection between the remote UE and the gNB) from the remote UE on the PC5 RLC channel associated with the remote UE's Uu SRB1 / 2 (or the remote UE's Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED) or thereafter, the relay UE may perform or initiate the RRC connection recovery procedure with the gNB.

[1067] Alternatively, when / if / when the relay UE sends data (including RRC signaling / messages of the remote UE, such as RRCSetupComplete for completing the establishment of the RRC connection between the remote UE and the gNB) to the gNB on or after the Uu RLC channel associated with the remote UE's Uu SRB1 / 2 (or the remote UE's Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED), the relay UE may perform / initiate the RRC connection recovery procedure with the gNB. In this alternative, the relay UE may send the relay UE's RRCResumeRequest to the gNB (on the relay UE's Uu SRB0). Transmitting the relay UE's RRCResumeReqeust or the CCCH SDU containing the relay UE's RRCResumeReqeust may trigger the relay UE to initiate the RA procedure with the gNB. Fig. 22As shown in , the relay UE may receive the relay UE's RRCResume (in Msg4) corresponding to the relay UE's RRCResumeRequest from the gNB (on the relay UE's Uu SRB1), and may then transmit the relay UE's RRCResumeComplete corresponding to the relay UE's RRCResume to the gNB (on the relay UE's Uu SRB1) (after successfully completing the RA procedure). After the relay UE enters RRC_CONNECTED, the relay UE may then transmit the remote UE's RRCSetupComplete to the gNB on the UuRLC channel associated with the remote UE's Uu SRB1.

[1068] It is also possible that both the relay UE and the remote UE are in RRC_IDLE. Therefore, when / if / when the relay UE receives a sidelink packet (containing the remote UE's RRC signaling / message, such as RRCSetupComplete for completing the establishment of the RRC connection between the remote UE and the gNB) from the remote UE on the PC5 RLC channel associated with the remote UE's Uu SRB1 / 2 (or the remote UE's Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED) or thereafter, the relay UE may perform / initiate the RRC connection establishment procedure with the gNB.

[1069] Alternatively, when / if / when the relay UE sends data (including RRC signaling / messages of the remote UE, such as RRCSetupComplete for completing the establishment of the RRC connection between the remote UE and the gNB) to the gNB on or after the Uu RLC channel associated with the remote UE's Uu SRB1 / 2 (or the remote UE's Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED), the relay UE may perform / initiate the RRC connection establishment procedure with the gNB. In this alternative, the relay UE may send the relay UE's RRCSetupRequest to the gNB (on the relay UE's Uu SRB0). Transmitting the relay UE's RRCSetupRequest or the CCCH SDU containing the relay UE's RRCSetupRequest may trigger the relay UE to initiate the RA procedure with the gNB. Fig. 22As shown in , the relay UE may receive the relay UE's RRCSetup (in Msg4) corresponding to the relay UE's RRCSetupRequest from the gNB (on the relay UE's Uu SRB0), and may then transmit the relay UE's RRCSetupComplete corresponding to the relay UE's RRCSetup to the gNB (on the relay UE's Uu SRB1) (after successfully completing the RA procedure). After the relay UE enters RRC_CONNECTED, the relay UE may then transmit the remote UE's RRCSetupComplete to the gNB on the UuRLC channel associated with the remote UE's Uu SRB1.

[1070] Fig.24 2400 is a flow chart illustrating a method for a relay UE. In step 2405, the relay UE connects to or serves a remote UE for relay communication with a network node. In step 2410, the relay UE receives a message from the remote UE on a PC5 RLC channel, wherein the PC5 RLC channel is associated with a Uu SRB1 of the remote UE or a Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED. In step 2415, in response to receiving the message on the PC5 RLC channel or when data is available for transmission from the relay UE to the network node on a Uu RLC channel associated with a Uu SRB1 of the remote UE or a Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED, the relay UE and the network node initiate or perform an RRC connection recovery procedure.

[1071] In one embodiment, in the RRC connection recovery procedure, the relay UE may transmit a first RRC message (e.g., RRCResumeRequest) to the network node, wherein the first RRC message is used to request the recovery of the RRC connection between the relay UE and the network node. In addition, in the RRC connection recovery procedure, the relay UE may receive a second RRC message (e.g., RRCResume) from the network node, wherein the second RRC message is used to recover the RRC connection between the relay UE and the network node. In addition, in the RRC connection recovery procedure, the relay UE may transmit a third RRC message (e.g., RRCResumeComplete) to the network node, wherein the third RRC message is used to complete the recovery of the RRC connection between the relay UE and the network node.

[1072] In one embodiment, when transmitting the message to the relay UE, the remote UE may be in RRC_CONNECTED.When receiving the message from the remote UE, the relay UE may be in RRC_INACTIVE, and when transmitting the third RRC message to the network node, the relay UE may be in RRC_CONNECTED.

[1073] In one embodiment, the network node may be a base station (e.g., a gNB).

[1074] SND Note - Please note that the content in the following paragraphs is from dependent claims 2 to 3, 7 to 9, and 14 to 15 on pages 50 to 51 of the amended disclosure.

[1075] In one embodiment, the relay UE may receive a first PC5-S message from the remote UE for requesting to establish a PC5-S connection. The first PC5-S message may be a direct communication request message. In addition, the relay UE may transmit a second PC5-S message for accepting the establishment of the PC5-S connection to the remote UE. The second PC5-S message may be a direct communication acceptance message.

[1076] In one embodiment, the message may be an RRC message for completing establishment of an RRC connection between a remote UE and a network node (eg, RRCSetupComplete), or an RRC message for completing restoration of an RRC connection between a remote UE and a network node (eg, RRCResumeComplete).

[1077] In one embodiment, the relay UE may transmit the message to the network node on the Uu RLC channel. The data may include the message.

[1078] Return to reference Figure 3 and 4In one exemplary embodiment of a method for a relay UE, the relay UE 300 includes a program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the relay UE (i) to connect to or serve a remote UE for relay communication with a network node, (ii) to receive a message from the remote UE on a PC5 RLC channel, wherein the PC5 RLC channel is associated with a Uu SRB1 of the remote UE or a Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED, or (iii) in response to receiving a message on the PC5 RLC channel or when data is available for transmission from the relay UE to the network node on a Uu RLC channel associated with a Uu SRB1 of the remote UE or a Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED, and the network node to initiate or perform an RRC connection recovery procedure. In addition, the CPU 308 can execute the program code 312 to perform all of the above actions and steps or other actions and steps described herein.

[1079] Fig.25 2500 is a flow chart illustrating a method for a relay UE. In step 2505, the relay UE connects to or serves a remote UE for relay communication with a network node. In step 2510, the relay UE receives a message from the remote UE on a PC5 RLC channel, wherein the PC5 RLC channel is associated with the Uu SRB1 of the remote UE or a Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED. In step 2515, in response to receiving the message on the PC5 RLC channel or when data is available for transmission from the relay UE to the network node on a Uu RLC channel associated with the Uu SRB1 of the remote UE or a Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED, the relay UE and the network node initiate or perform an RRC connection establishment procedure.

[1080] In one embodiment, in the RRC connection establishment procedure, the relay UE may transmit a first RRC message (e.g., RRCSetupRequest) to the network node, wherein the first RRC message is used to request the establishment of an RRC connection between the relay UE and the network node. In addition, in the RRC connection establishment procedure, the relay UE may receive a second RRC message (e.g., RRCSetup) from the network node, wherein the second RRC message is used to establish the RRC connection. In addition, in the RRC connection establishment procedure, the relay UE may transmit a third RRC message (e.g., RRCSetupComplete) to the network node, wherein the third RRC message is used to complete the establishment of the RRC connection.

[1081] In one embodiment, when the message is transmitted to the relay UE, the remote UE may be in RRC_CONNECTED. In addition, when the message is received from the remote UE, the relay UE may be in RRC_IDLE. In addition, when the third RRC message is transmitted to the network node, the relay UE may be in RRC_CONNECTED.

[1082] In one embodiment, the network node may be a base station (e.g., a gNB).

[1083] In one embodiment, the relay UE may receive a first PC5-S message from the remote UE for requesting to establish a PC5-S connection. The first PC5-S message may be a direct communication request message. The relay UE may transmit a second PC5-S message for accepting the establishment of the PC5-S connection to the remote UE. The second PC5-S message may be a direct communication acceptance message.

[1084] In one embodiment, the message may be an RRC message (eg, RRCSetupComplete) used to complete establishment of an RRC connection between the remote UE and the network node.

[1085] In one embodiment, the relay UE may transmit the message to the network node on the Uu RLC channel. The data may include the message.

[1086] Return to reference Figure 3 and 4 In one exemplary embodiment of a method for a relay UE, the relay UE 300 includes a program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the relay UE (i) to connect with a remote UE or to serve a remote UE for relay communication with a network node, (ii) to receive a message from the remote UE on a PC5 RLC channel, wherein the PC5 RLC channel is associated with a Uu SRB1 of the remote UE or a Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED, and (iii) in response to receiving a message on the PC5 RLC channel or when data is available for transmission from the relay UE to the network node on a Uu RLC channel associated with a Uu SRB1 of the remote UE or a Uu SRB used by the remote UE to transmit RRC signaling under RRC_CONNECTED, initiate or perform an RRC connection establishment procedure with the network node. In addition, the CPU 308 can execute the program code 312 to perform all of the above actions and steps or other actions and steps described herein.

[1087] Various aspects of the present disclosure have been described above. It should be understood that the teachings herein can be embodied in a wide variety of forms, and any specific structure, function, or both disclosed herein are only representative. Based on the teachings herein, it should be understood by those skilled in the art 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 described herein can be used to implement a device or practice a method. In addition, other structures, functions, or structures and functions different from the aspects described in addition to one or more aspects described herein can be used to implement such devices or practice such methods. As an example of some of the above concepts, in some aspects, parallel channels can be established based on pulse repetition frequencies. In some aspects, parallel channels can be established based on pulse positions or offsets. In some aspects, parallel channels can be established based on time hopping sequences. In some aspects, parallel channels can be established based on pulse repetition frequencies, pulse positions or offsets, and time hopping sequences.

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

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

[1090] In addition, the various illustrative logical blocks, modules, and circuits described in conjunction with the aspects disclosed herein may be implemented within or performed by an integrated circuit ("IC"), an access terminal, or an 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 in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

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

[1092] The steps of the method or algorithm described in conjunction with the various aspects disclosed herein may be directly embodied in hardware, software modules executed by a processor, or a combination of the two. Software modules (e.g., including executable instructions and related data) and other data may reside in a data memory, such as a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or any other form of computer-readable storage medium known in the art. Sample storage media may be coupled to a machine such as a computer / processor (which may be referred to herein as a "processor" for convenience) so that the processor can read information (e.g., code) from the storage medium and write information to the storage medium. Sample storage media may be integrated with the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user device. In an alternative, the processor and storage medium may reside in a user device as discrete components. In addition, in some aspects, any suitable computer program product may include a computer-readable medium, which includes codes related to one or more of the various aspects of the present disclosure. In some aspects, a computer program product may include packaging materials.

[1093] Although the present invention has been described in conjunction with various aspects, it will be appreciated that the present invention is capable of further modifications. This application is intended to cover any changes, uses or adaptations of the present invention that generally follow the principles of the present invention and include such deviations from the present disclosure that are within the scope of known and customary practice in the technical field to which the present invention relates.

Claims

1. A method for relaying user equipment, characterized in that: include: connecting to or serving a remote user equipment for relaying communications with a network node; receiving a message from the remote user equipment on a PC5 radio link control channel, wherein the message comprises a completion message for the remote user equipment in response to receipt of a radio resource control message from the network node, wherein the PC5 radio link control channel is associated with a Uu SRB1 of the remote user equipment or a Uu signaling radio bearer used by the remote user equipment to transmit radio resource control signaling under RRC_CONNECTED; as well as In response to receiving the message on the PC5 radio link control channel, the network node initiates or performs a radio resource control connection recovery procedure.

2. The method according to claim 1, characterized in that Further including: transmitting a first radio resource control message to the network node in the radio resource control connection recovery procedure, wherein the first radio resource control message is used to request recovery of the radio resource control connection between the relay user equipment and the network node; receiving a second radio resource control message from the network node in the radio resource control connection recovery procedure, wherein the second radio resource control message is used to recover the radio resource control connection between the relay user equipment and the network node; and A third radio resource control message is transmitted to the network node in the radio resource control connection recovery procedure, wherein the third radio resource control message is used to complete recovery of the radio resource control connection between the relay user equipment and the network node.

3. The method according to claim 1, characterized in that When the message is transmitted to the relay user equipment, the remote user equipment is in RRC_CONNECTED.

4. The method according to claim 2, characterized in that: The relay user equipment is in RRC_INACTIVE when receiving the message from the remote user equipment, and is in RRC_CONNECTED when transmitting the third radio resource control message to the network node.

5. The method according to claim 1, characterized in that The network node is a base station.

6. A relay user equipment, characterized in that: include: Control circuit; a processor installed in the control circuit; as well as a memory installed in the control circuit and operatively coupled to the processor; wherein the processor is configured to execute program code stored in the memory to: connecting to or serving a remote user equipment for relaying communications with a network node; receiving a message from the remote user equipment on a PC5 radio link control channel, wherein the message comprises a completion message for the remote user equipment in response to receipt of a radio resource control message from the network node, wherein the PC5 radio link control channel is associated with a UuSRB1 of the remote user equipment or a Uu signaling radio bearer used by the remote user equipment to transmit radio resource control signaling under RRC_CONNECTED; as well as In response to receiving the message on the PC5 radio link control channel, the network node initiates or performs a radio resource control connection recovery procedure.

7. The relay user equipment according to claim 6, characterized in that: The processor is further configured to execute program code stored in the memory to: transmitting a first radio resource control message to the network node in the radio resource control connection recovery procedure, wherein the first radio resource control message is used to request recovery of the radio resource control connection between the relay user equipment and the network node; receiving a second radio resource control message from the network node in the radio resource control connection recovery procedure, wherein the second radio resource control message is used to recover the radio resource control connection between the relay user equipment and the network node; and A third radio resource control message is transmitted to the network node in the radio resource control connection recovery procedure, wherein the third radio resource control message is used to complete recovery of the radio resource control connection between the relay user equipment and the network node.

8. The relay user equipment according to claim 6, characterized in that: When the message is transmitted to the relay user equipment, the remote user equipment is in RRC_CONNECTED.

9. The relay user equipment according to claim 7, characterized in that: The relay user equipment is in RRC_INACTIVE when receiving the message from the remote user equipment, and is in RRC_CONNECTED when transmitting the third radio resource control message to the network node.

10. The relay user equipment according to claim 6, characterized in that: The network node is a base station.

11. A method for relaying user equipment, characterized in that: include: connecting to or serving a remote user equipment for relaying communications with a network node; receiving a message from the remote user equipment on a PC5 radio link control channel, wherein the message comprises a completion message for the remote user equipment in response to receipt of a radio resource control message from the network node, wherein the PC5 radio link control channel is associated with a Uu SRB1 of the remote user equipment or a Uu signaling radio bearer used by the remote user equipment to transmit radio resource control signaling under RRC_CONNECTED; as well as In response to receiving the message on the PC5 radio link control channel, the network node initiates or performs a radio resource control connection establishment procedure.

12. The method according to claim 11, characterized in that Further including: transmitting a first radio resource control message to the network node in the radio resource control connection establishment procedure, wherein the first radio resource control message is used to request establishment of a radio resource control connection between the relay user equipment and the network node; receiving a second radio resource control message from the network node in the radio resource control connection establishment procedure, wherein the second radio resource control message is used to establish the radio resource control connection; and A third radio resource control message is transmitted to the network node in the radio resource control connection establishment procedure, wherein the third radio resource control message is used to complete the establishment of the radio resource control connection.

13. The method according to claim 11, characterized in that When the message is transmitted to the relay user equipment, the remote user equipment is in RRC_CONNECTED.

14. The method according to claim 12, characterized in that The relay user equipment is in RRC_IDLE when receiving the message from the remote user equipment, and is in RRC_CONNECTED when transmitting the third radio resource control message to the network node.

15. The method according to claim 11, characterized in that The network node is a base station.

16. A relay user equipment, characterized in that: include: Control circuit; a processor installed in the control circuit; as well as a memory installed in the control circuit and operatively coupled to the processor; wherein the processor is configured to execute program code stored in the memory to: connecting to or serving a remote user equipment for relaying communications with a network node; receiving a message from the remote user equipment on a PC5 radio link control channel, wherein the message comprises a completion message for the remote user equipment in response to receipt of a radio resource control message from the network node, wherein the PC5 radio link control channel is associated with a UuSRB1 of the remote user equipment or a Uu signaling radio bearer used by the remote user equipment to transmit radio resource control signaling under RRC_CONNECTED; as well as In response to receiving the message on the PC5 radio link control channel, the network node initiates or performs a radio resource control connection establishment procedure.

17. The relay user equipment according to claim 16, characterized in that: The processor is further configured to execute program code stored in the memory to: transmitting a first radio resource control message to the network node in the radio resource control connection establishment procedure, wherein the first radio resource control message is used to request establishment of a radio resource control connection between the relay user equipment and the network node; receiving a second radio resource control message from the network node in the radio resource control connection establishment procedure, wherein the second radio resource control message is used to establish the radio resource control connection; and A third radio resource control message is transmitted to the network node in the radio resource control connection establishment procedure, wherein the third radio resource control message is used to complete the establishment of the radio resource control connection.

18. The relay user equipment according to claim 16, characterized in that: When the message is transmitted to the relay user equipment, the remote user equipment is in RRC_CONNECTED.

19. The relay user equipment according to claim 17, characterized in that: The relay user equipment is in RRC_IDLE when receiving the message from the remote user equipment, and is in RRC_CONNECTED when transmitting the third radio resource control message to the network node.

20. The relay user equipment according to claim 16, characterized in that: The network node is a base station.

Images