Method and apparatus for transmitting / receiving wireless signal in wireless communication system

Abstract

According to an embodiment of the present disclosure, a network may receive measurement information from a first UE (User Equipment) configured with at least one of a direct radio path directly connected to a first network and an indirect radio path indirectly connected to the first network through a relay UE, determine a handover to a second network for the first UE based on the measurement information, and transmitting a handover request message to the second network, the handover request message comprising information about at least one relay UE related to an indirect radio path between the second network and the first UE.

Description

Technical Field

[0001] The present disclosure relates to a wireless communication system, and more particularly, to a method and apparatus for transmitting / receiving a wireless signal. Background Art

[0002] Wireless communication systems have been widely deployed to provide various types of communication services, such as voice or data. In general, wireless communication systems are multiple access systems that support communication for multiple users by sharing available system resources (bandwidth, transmit power, etc.). Examples of multiple access systems include code division multiple access (CDMA) systems, frequency division multiple access (FDMA) systems, time division multiple access (TDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single carrier frequency division multiple access (SC-FDMA) systems, and multi-carrier frequency division multiple access (MC-FDMA) systems.

[0003] Sidelink (SL) refers to a communication scheme in which a direct link is established between a user equipment (UE) and the UEs and the UEs directly exchange voice or data without intervention of a base station (BS). SL is considered a solution to alleviate the rapidly growing data traffic constraints of the BS.

[0004] Vehicle-to-everything (V2X) is a communication technology in which a vehicle exchanges information with another vehicle, pedestrians, and infrastructure through wired / wireless communications. V2X can be divided into four types: vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), and vehicle-to-pedestrian (V2P). V2X communication can be provided via a PC5 interface and / or a Uu interface.

[0005] As more and more communication devices require greater communication capacity, enhanced mobile broadband communication is needed relative to existing RATs. Therefore, communication systems that take into account services or UEs that are sensitive to reliability and latency are being discussed. The next generation RAT that takes into account eMBB, MTC, and URLLC is called new RAT or NR. In NR, V2X communication can also be supported.

[0006] Figure 1 The diagram illustrates, by comparison, V2X communication based on pre-NR-RAT and V2X communication based on NR.

[0007] For V2X communication, the technology of providing safety services based on V2X messages such as Basic Safety Message (BSM), Collaborative Awareness Message (CAM) and Decentralized Environment Notification Message (DENM) is mainly discussed in the pre-NR RAT. V2X messages may include location information, dynamic information and attribute information. For example, a UE may send a CAM of a periodic message type and / or a DENM of an event-triggered type to another UE.

[0008] For example, CAM may include basic vehicle information, including dynamic status information such as direction and speed, vehicle static data such as size, external lighting status, path details, etc. For example, UE may broadcast CAM, and the latency of CAM may be less than 100ms. For example, when an unexpected event such as vehicle damage or accident occurs, UE may generate DENM and send DENM to another UE. For example, all vehicles within the transmission range of UE may receive CAM and / or DENM. In this case, DENM may have a higher priority than CAM.

[0009] Regarding V2X communication, various V2X scenarios are proposed in NR. For example, V2X scenarios include vehicle platooning, advanced driving, extended sensors, and remote driving.

[0010] For example, vehicles may be dynamically grouped and driven together based on a vehicle platoon. For example, to perform a platooning operation based on a vehicle platoon, vehicles in a group may receive periodic data from a leading vehicle. For example, vehicles in a group may widen or narrow their gaps based on the periodic data.

[0011] For example, based on advanced driving, the vehicles can be semi-autonomous or fully autonomous. For example, each vehicle can adjust trajectory or maneuver based on data obtained from nearby vehicles and / or nearby logical entities. For example, each vehicle can also share driving intent with nearby vehicles.

[0012] For example, based on the extended sensors, raw or processed data or real-time video data obtained by local sensors can be exchanged between vehicles, logical entities, pedestrian terminals and / or V2X application servers. Therefore, the vehicle can perceive a high-level environment relative to the environment that can be perceived by the vehicle's sensors.

[0013] For example, based on remote driving, remote drivers or V2X applications can operate or control remote vehicles on behalf of people who are unable to drive or are in dangerous environments. For example, cloud-based driving can be used to operate or control remote vehicles when the path can be predicted as in public transportation. For example, access to a cloud-based backend service platform can also be used for remote driving.

[0014] In NR-based V2X communications, schemes for specifying service requirements for various V2X scenarios including vehicle platooning, advanced driving, extended sensors, and remote driving are discussed. Summary of the invention

[0015] Technical issues

[0016] An object of the present disclosure is to provide a method and apparatus for accurately and efficiently performing a wireless signal transmission / reception process.

[0017] Those skilled in the art will appreciate that the objectives that can be achieved using the present disclosure are not limited to the objectives that have been specifically described above, and the above objectives and other objectives that can be achieved by the present disclosure will be more clearly understood from the following detailed description.

[0018] Technical Solution

[0019] In an aspect of the present disclosure, a method may include the steps of receiving measurement information from a first UE (user equipment) configured with at least one of a direct radio path directly connected to a first network and an indirect radio path indirectly connected to the first network through a relay UE, determining a handover to a second network for the first UE based on the measurement information, and sending a handover request message to the second network, the handover request message including information about at least one relay UE related to the indirect radio path between the second network and the first UE.

[0020] Preferably, the method further comprises the step of: receiving a HANDOVER COMMAND message from the second network.

[0021] Preferably, the HANDOVER COMMAND message includes information on one relay UE selected from among the at least one relay UE.

[0022] Preferably, the handover request message is used to switch a direct radio path or an indirect radio path between the first UE and the first network to an indirect radio path between the second network and the first UE.

[0023] Preferably, the handover request message is an XnAP (Xn Application Protocol) HANDOVER REQUEST message.

[0024] Preferably, the handover request message further includes information indicating a serving cell associated with the at least one relay UE.

[0025] Preferably, the information on the at least one relay UE is at least one identifier (ID) for the at least one relay UE.

[0026] Preferably, the measurement information includes at least one of the quality of the relay UE, the quality of the neighboring relay UEs, the quality of the serving cell of the relay UE, the quality of the neighboring cell of the first UE, and the quality of the serving cell of the first UE.

[0027] Preferably, the quality is RSRP (reference signal received power) or RSRQ (reference signal received quality).

[0028] In another aspect of the present disclosure, there is provided a computer-readable storage medium having stored thereon a program for executing the above method.

[0029] In another aspect of the present disclosure, an apparatus configured to perform the method is provided.

[0030] In another aspect of the present disclosure, a second network configured to control a UE configured to perform the method is provided.

[0031] Beneficial Effects

[0032] According to the embodiments of the present disclosure, a wireless signal transmission / reception process can be performed accurately and efficiently.

[0033] According to an embodiment of the present disclosure, through the proposed method, it becomes clear that in inter-gNB handover for multipath, the handover method for multipath and information about the target relay UE for an indirect path are determined by the source gNB.

[0034] Those skilled in the art will understand that the effects that can be achieved by the present disclosure are not limited to the contents specifically described above, and other advantages of the present disclosure will be more clearly understood from the following detailed description in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 is a diagram illustrating, in contrast, vehicle-to-everything (V2X) communication based on a former new radio access technology (NR) RAT and V2X communication based on NR.

[0036] Figure 2 The structure of an LTE system to which the embodiments can be applied is illustrated.

[0037] Figure 3 The structure of an NR system to which an embodiment can be applied is illustrated.

[0038] Figure 4 The structure of an NR radio frame to which an embodiment can be applied is illustrated.

[0039] Figure 5 The time slot structure of the NR frame to which the implementation scheme can be applied is illustrated.

[0040] Figure 6 A radio protocol architecture for SL communications is illustrated.

[0041] Figure 7 A UE performing V2X or SL communication is illustrated.

[0042] Figure 8 Resource units used for V2X or SL communication are illustrated.

[0043] Fig. 9 The inter-UE coordination information MAC CE is illustrated.

[0044] Fig.10 An inter-UE coordination request MAC CE is illustrated.

[0045] Fig.11 (a) User plane protocol stack and (b) control plane protocol stack for L2 UE to network relay are illustrated.

[0046] Fig.12 A protocol stack for UE-to-network relay discovery messages is illustrated.

[0047] Fig.13 The procedure for L2 U2N remote UE connection establishment is illustrated.

[0048] Fig.14 The procedure for U2N remote UE handover to direct Uu cell is illustrated.

[0049] Fig.15 The procedure for U2N remote UE switching to an indirect path is illustrated.

[0050] Fig.16 and Fig.17 is a diagram for explaining a method of performing handover for direct-indirect path switching or indirect-indirect path switching for a remote UE.

[0051] Fig.18 A diagram for explaining a method in which a first network performs handover for a first UE.

[0052] Fig.19 A communication system applied to the present disclosure is illustrated.

[0053] Fig. 20 A wireless device suitable for use with the present disclosure is illustrated.

[0054] Fig.21 Another example of a wireless device to which the present disclosure is applied is illustrated.

[0055] Fig. 22 A vehicle or an autonomous driving vehicle to which the present disclosure is applied is illustrated. DETAILED DESCRIPTION

[0056] A wireless communication system is a multiple access system that supports communication for multiple users by sharing available system resources (bandwidth, transmit power, etc.). Examples of multiple access systems include code division multiple access (CDMA) systems, frequency division multiple access (FDMA) systems, time division multiple access (TDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single carrier frequency division multiple access (SC-FDMA) systems, and multi-carrier frequency division multiple access (MC-FDMA) systems.

[0057] Details of the background, terminology, abbreviations etc. used herein can be found in the following documents.

[0058] 3GPP LTE

[0059] -3GPP TS 36.211: Physical channels and modulation

[0060] -3GPP TS 36.212: Multiplexing and channel coding

[0061] -3GPP TS 36.213: Physical layer procedures

[0062] -3GPP TS 36.214: Physical layer; Measurement

[0063] -3GPP TS 36.300: Overall description

[0064] -3GPP TS 36.304: User Equipment (UE) procedures in idle mode

[0065] -3GPP TS 36.314: Layer 2 - Measurement

[0066] -3GPP TS 36.321: Medium Access Control (MAC) Protocol

[0067] -3GPP TS 36.322: Radio Link Control (RLC) protocol

[0068] -3GPP TS 36.323: Packet Data Convergence Protocol (PDCP)

[0069] -3GPP TS 36.331: Radio Resource Control (RRC) protocol

[0070] 3GPP NR

[0071] -3GPP TS 38.211: Physical channels and modulation

[0072] -3GPP TS 38.212: Multiplexing and channel coding

[0073] -3GPP TS 38.213: Physical layer procedures for control

[0074] -3GPP TS 38.214: Physical layer procedures for data

[0075] -3GPP TS 38.215: Physical layer measurements

[0076] -3GPP TS 38.300: Overall description

[0077] -3GPP TS 38.304: User Equipment (UE) procedures in idle mode and RRC inactive state

[0078] -3GPP TS 38.321: Medium Access Control (MAC) Protocol

[0079] -3GPP TS 38.322: Radio Link Control (RLC) protocol

[0080] -3GPP TS 38.323: Packet Data Convergence Protocol (PDCP)

[0081] -3GPP TS 38.331: Radio Resource Control (RRC) protocol

[0082] -3GPP TS 37.324: Service Data Adaptation Protocol (SDAP)

[0083] -3GPP TS 37.340: Multi-connectivity; general description

[0084] Sidelink (SL) refers to a communication scheme in which a direct link is established between a user equipment (UE) and the UEs and the UEs directly exchange voice or data without intervention of a base station (BS). SL is considered a solution to alleviate the rapidly growing data traffic constraints of the BS.

[0085] Vehicle-to-everything (V2X) is a communication technology in which a vehicle exchanges information with another vehicle, pedestrians, and infrastructure through wired / wireless communications. V2X can be divided into four types: vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), and vehicle-to-pedestrian (V2P). V2X communication can be provided via a PC5 interface and / or a Uu interface.

[0086] As more and more communication devices require greater communication capacity, enhanced mobile broadband communication is needed relative to existing RATs. Therefore, communication systems that take into account services or UEs that are sensitive to reliability and latency are being discussed. The next generation RAT that takes into account eMBB, MTC, and URLLC is called new RAT or NR. In NR, V2X communication can also be supported.

[0087] The technology described herein can be used for various wireless access systems such as code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA), etc. CDMA can be implemented as a radio technology such as Universal Terrestrial Radio Access (UTRA) or CDMA2000. TDMA can be implemented as a radio technology such as Global System for Mobile Communications (GSM) / General Packet Radio Service (GPRS) / Enhanced Data Rate for GSM Evolution (EDGE). OFDMA can be implemented as a radio technology such as IEEE 802.11 (Wi-Fi), IEEE802.16 (WiMAX), IEEE 802.20, Evolved UTRA (E-UTRA), etc. IEEE802.16m is an evolution of IEEE 802.16e, providing backward compatibility with IRRR 802.16e-based systems. UTRA is part of Universal Mobile Telecommunications System (UMTS). 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) is a part of Evolved UMTS (E-UMTS) using Evolved UTRA (E-UTRA). 3GPP LTE adopts OFDMA for downlink (DL) and SC-FDMA for uplink (UL). LTE Advanced (LTE-A) is an evolution of 3GPP LTE. 3GPP NR (New Radio or New Radio Access Technology) is an evolved version of 3GPP LTE / LTE-A / LTE-A pro.

[0088] The successor to LTE-A, the fifth generation (5G) new radio access technology (NR), is a new clean-state mobile communication system characterized by high performance, low latency and high availability. 5G NR can use all available spectrum resources, including low frequency bands below 1 GHz, mid-frequency bands between 1 GHz and 10 GHz, and high frequency (millimeter) bands of 24 GHz or above.

[0089] Although the following description is mainly given in the context of LTE-A or 5G NR for the sake of clarity, the technical ideas of the embodiments of the present disclosure are not limited thereto.

[0090] Figure 2 The structure of the LTE system according to the embodiment of the present disclosure is illustrated. This may also be referred to as an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) or an LTE / LTE-A system.

[0091] Reference Figure 2, E-UTRAN includes an evolved Node B (eNB) 20 that provides a control plane and a user plane to UE 10. UE 10 may be fixed or mobile, and may also be referred to as a mobile station (MS), a user terminal (UT), a subscriber station (SS), a mobile terminal (MT), or a wireless device. eNB 20 is a fixed station that communicates with UE 10, and may also be referred to as a base station (BS), a base transceiver system (BTS), or an access point.

[0092] The eNBs 20 may be connected to each other via an X2 interface. The eNBs 20 are connected to an Evolved Packet Core (EPC) 39 via an S1 interface. More specifically, the eNBs 20 are connected to a Mobility Management Entity (MME) via an S1-MME interface, and to a Serving Gateway (S-GW) via an S1-U interface.

[0093] The EPC 30 includes an MME, an S-GW, and a packet data network gateway (P-GW). The MME has access information or capability information about the UE, which is mainly used for mobility management of the UE. The S-GW is a gateway with the E-UTRAN as an endpoint, and the P-GW is a gateway with a packet data network (PDN) as an endpoint.

[0094] Based on the lowest three layers of the open system interconnection (OSI) reference model known in communication systems, the radio protocol stack between the UE and the network can be divided into layer 1 (L1), layer 2 (L2), and layer 3 (L3). These layers are defined in pairs between the UE and the evolved UTRAN (E-UTRAN) for data transmission via the Uu interface. The physical (PHY) layer at L1 provides information transfer services on physical channels. The radio resource control (RRC) layer at L3 is used to control radio resources between the UE and the network. For this purpose, the RRC layer exchanges RRC messages between the UE and the eNB.

[0095] Figure 3 The structure of the NR system according to an embodiment of the present disclosure is illustrated.

[0096] Reference Figure 3 , the next generation radio access network (NG-RAN) may include next generation Node Bs (gNBs) and / or eNBs that provide user plane and control plane protocol terminations to the UE. Figure 4 In the figure, for example, NG-RAN is shown as including only gNB. gNB and eNB are connected to each other via Xn interface. gNB and eNB are connected to 5G core network (5GC) via NG interface. More specifically, gNB and eNB are connected to access and mobility management function (AMF) via NG-C interface, and to user plane function (UPF) via NG-U interface.

[0097] Figure 4 The radio frame structure in NR to which the embodiments of the present disclosure are applicable is illustrated.

[0098] Reference Figure 4 , a radio frame can be used for UL transmission and DL transmission in NR. The length of a radio frame is 10ms and can be defined by two 5ms half frames. HF may include five 1ms subframes. A subframe may be divided into one or more slots, and the number of slots in a SF may be determined according to a subcarrier spacing (SCS). Each slot may include 12 or 14 OFDM (A) symbols depending on a cyclic prefix (CP).

[0099] In the case of normal CP (NCP), each time slot may include 14 symbols, and in the case of extended CP (ECP), each time slot may include 12 symbols. Herein, a symbol may be an OFDM symbol (or CP-OFDM symbol) or an SC-FDMA symbol (or DFT-s-OFDM symbol).

[0100] Table 1 below lists the number of symbols N per time slot according to the SCS configuration μ in the NCP case slot symb , the number of time slots per frame N frame,u slot And the number of time slots N in each subframe subframe,u slot .

[0101] [Table 1]

[0102] <![CDATA[SCS(15*2 u )]]> <![CDATA[N slot symb ]]> <![CDATA[N frame,u slot ]]> <![CDATA[N subframe,u slot ]]> 15kHz(u=0) 14 10 1 30kHz(u=1) 14 20 2 60kHz(u=2) 14 40 4 120kHz(u=3) 14 80 8 240kHz(u=4) 14 160 16

[0103] The following Table 2 lists the number of symbols per time slot, the number of time slots per frame, and the number of time slots per subframe according to SCS in the ECP case.

[0104] [Table 2]

[0105] SCS(15*2^u) <![CDATA[N slot symb ]]> <![CDATA[N frame,u slot ]]> <![CDATA[N subframe,u slot ]]> 60kHz(u=2) 12 40 4

[0106] In the NR system, different OFDM(A) parameter sets (e.g., SCS, CP length, etc.) may be configured for multiple cells aggregated for one UE. Therefore, the (absolute time) duration of a time resource (e.g., a subframe, a time slot, or a TTI) (collectively referred to as a time unit (TU) for convenience) including the same number of symbols may be configured to be different for the aggregated cells.

[0107] In NR, various parameter sets or SCS can be supported to support various 5G services. For example, with 15kHz SCS, wide areas in traditional cellular bands can be supported, while with 30kHz / 60kHz SCS, dense urban areas, lower latency and wide carrier bandwidth can be supported. With 60kHz or higher SCS, bandwidths greater than 24.25GHz can be supported to overcome phase noise.

[0108] The NR frequency band may be defined by two types of frequency ranges FR1 and FR2. The values ​​in each frequency range may vary. For example, two types of frequency ranges may be given in Table 3. In the NR system, FR1 may be a "range below 6 GHz" and FR2 may be a "range above 6 GHz" known as millimeter wave (mmW).

[0109] [Table 3]

[0110] Frequency range name Corresponding frequency range Subcarrier Spacing (SCS) FR1 450MHz-6000MHz 15,30,60kHz FR2 24250MHz-52600MHz 60,120,240kHz

[0111] As mentioned above, in the NR system, the values ​​in the frequency range can be changed. For example, as listed in Table 4, the range of FR1 can be from 410 MHz to 7125 MHz. That is, FR1 can include frequency bands of 6 GHz (or 5850, 5900, and 5925 MHz) or above. For example, frequency bands of 6 GHz (or 5850, 5900, and 5925 MHz) or above can include unlicensed frequency bands. Unlicensed frequency bands can be used for various purposes, for example, vehicle communications (e.g., autonomous driving).

[0112] [Table 4]

[0113] Frequency range name Corresponding frequency range Subcarrier Spacing (SCS) FR1 410MHz-7125MHz 15,30,60kHz FR2 24250MHz-52600MHz 60,120,240kHz

[0114] Figure 5 The time slot structure in the NR frame according to an embodiment of the present disclosure is illustrated.

[0115] Reference Figure 5 , a time slot includes multiple symbols in the time domain. For example, a time slot may include 14 symbols in the NCP case and 12 symbols in the ECP case. Alternatively, a time slot may include 7 symbols in the NCP case and 6 symbols in the ECP case.

[0116] A carrier includes multiple subcarriers in the frequency domain. An RB can be defined by multiple (e.g., 12) consecutive subcarriers in the frequency domain. A bandwidth part (BWP) can be defined by multiple consecutive (physical) RBs ((P)RBs) in the frequency domain and corresponds to a parameter set (e.g., SCS, CP length, etc.). A carrier can include up to N (e.g., 5) BWPs. Data communication can be performed in an activated BWP. Each element can be referred to as a resource element (RE) in a resource grid, and a complex symbol can be mapped to an RE.

[0117] The radio interface between UEs or the radio interface between UE and the network may include L1, L2 and L3. In various embodiments of the present disclosure, L1 may refer to a PHY layer. For example, L2 may refer to at least one of a MAC layer, an RLC layer, a PDCH layer or an SDAP layer. For example, L3 may refer to an RRC layer.

[0118] Now, a description will be given of V2X or Side Link (SL) communication.

[0119] Figure 6 The radio protocol architecture for SL communication is illustrated. Specifically, Figure 6 (a) shows the user plane protocol stack of NR, and Figure 6 (b) shows the control plane protocol stack of NR.

[0120] Next, the side link synchronization signal (SLSS) and the synchronization information will be described.

[0121] The SLSS as a SL specific sequence may include a primary side link synchronization signal (PSSS) and a secondary side link synchronization signal (SSSS). The PSSS may be referred to as a side link primary synchronization signal (S-PSS), and the SSSS may be referred to as a side link secondary synchronization signal (S-SSS). For example, an M sequence of length 127 may be used for the S-PSS, and a Gold sequence of length 127 may be used for the S-SSS. For example, the UE may detect an initial signal and acquire synchronization by using the S-PSS. For example, the UE may acquire fine synchronization and detect a synchronization signal ID by using the S-PSS and the S-SSS.

[0122] The physical side link broadcast channel (PSBCH) may be a (broadcast) channel that carries basic (system) information that the UE needs to know first before sending and receiving SL signals. For example, the basic information may include information related to SLSS, duplex mode (DM) information, time division duplex (TDD) UL / DL (UL / DL) configuration information, resource pool related information, information about the type of application related to SLSS, subframe offset information, broadcast information, etc. For example, the payload size of the PSBCH may be 56 bits, including a 24-bit cyclic redundancy check (CRC) for evaluating PSBCH performance in NR V2X.

[0123] The S-PSS, S-SSS, and PSBCH may be included in a block format that supports periodic transmission (e.g., SL synchronization signal (SLSS) / PSBCH block, hereinafter referred to as a sidelink synchronization signal block (S-SSB)). The S-SSB may have the same parameter set (i.e., SCS and CP length) as the physical sidelink control channel (PSCCH) / physical sidelink shared channel (PSSCH) in the carrier, and the transmission bandwidth of the S-SSB may be within a (pre-) configured SL BWP. For example, the bandwidth of the S-SSB may be 11 RBs. For example, the PSBCH may span 11 RBs. The frequency position of the S-SSB may be (pre-) set. Therefore, the UE does not need to perform frequency hypothesis detection to discover the S-SSB in the carrier.

[0124] In the NR SL system, multiple parameter sets including different SCS and / or CP lengths may be supported. As the SCS increases, the length of the time resources used for the S-SSB transmission of the UE may be shortened. Therefore, in order to ensure the coverage of the S-SSB, the transmitting UE may send one or more S-SSBs to the receiving terminal within an S-SSB transmission period according to the SCS. For example, the number of S-SSBs sent by the transmitting terminal to the receiving terminal within an S-SSB transmission period may be pre-configured or configured for the transmitting UE. For example, the S-SSB transmission period may be 160ms. For example, for all SCSs, an S-SSB transmission period of 160ms may be supported.

[0125] For example, when the SCS in FR1 is 15kHz, the transmitting UE can send one or two S-SSBs to the receiving UE in one S-SSB transmission period. For example, when the SCS in FR1 is 30kHz, the transmitting UE can send one or two S-SSBs to the receiving UE in one S-SSB transmission period. For example, when the SCS in FR1 is 60kHz, the transmitting UE can send one, two, or four S-SSBs to the receiving UE in one S-SSB transmission period.

[0126] For example, when the SCS in FR2 is 60kHz, the transmitting UE can send 1, 2, 4, 8, 16 or 32 S-SSBs to the receiving UE in one S-SSB transmission period. For example, when the SCS in FR2 is 120kHz, the transmitting UE can send 1, 2, 4, 8, 16, 32 or 64 S-SSBs to the receiving UE in one S-SSB transmission period.

[0127] When the SCS is 60kHz, two types of CP can be supported. In addition, the structure of the S-SSB sent by the transmitting UE to the receiving UE may be different according to the CP type. For example, the CP type may be NCP or ECP. Specifically, for example, when the CP type is NCP, the number of symbols to which the PSBCH in the S-SSB sent by the transmitting UE is mapped may be 9 or 8. On the other hand, for example, when the CP type is ECP, the number of symbols to which the PSBCH in the S-SSB sent by the transmitting UE is mapped may be 7 or 6. For example, the PSBCH may be mapped to the first symbol of the S-SSB sent by the transmitting UE. For example, after receiving the S-SSB, the receiving UE may perform an automatic gain control (AGC) operation in the first symbol period of the S-SSB.

[0128] Figure 7 A UE performing V2X or SL communication is illustrated.

[0129] Reference Figure 7 , the term "UE" in V2X or SL communication may mainly refer to a user's terminal. However, when a network device such as a BS transmits and receives signals according to a UE-UE communication scheme, the BS may also be regarded as a type of UE. For example, a first UE (UE 1) may be a first device 100, and a second UE (UE 2) may be a second device 200.

[0130] For example, UE 1 may select a resource unit corresponding to a specific resource in a resource pool as a group of resources. Then, UE 1 may send an SL signal in the resource unit. For example, UE 2 as a receiving UE may be configured with a resource pool in which UE 1 may send a signal, and detect a signal from UE 1 in the resource pool.

[0131] When UE1 is within the coverage of the BS, the BS may indicate the resource pool to UE1. On the contrary, when UE1 is out of the coverage of the BS, another UE may indicate the resource pool to UE1, or UE1 may use a predetermined resource pool.

[0132] Generally, a resource pool may include a plurality of resource units, and each UE may select one or more resource units and transmit a SL signal in the selected resource units.

[0133] Figure 8 Resource units used for V2X or SL communication are illustrated.

[0134] Reference Figure 8 , the total frequency resources of the resource pool can be divided into NF frequency resources, and the total time resources of the resource pool can be divided into NT time resources. Therefore, a total of NF×NT resource units can be defined in the resource pool. Figure 8 An example is illustrated in which the resource pool is repeated with a period of NT subframes.

[0135] like Figure 8 As illustrated in FIG, a resource unit (e.g., unit #0) may appear periodically repeatedly. Alternatively, in order to achieve a diversity effect in the time domain or frequency domain, the index of the physical resource unit to which a logical resource unit is mapped may change in a predetermined pattern over time. In the resource unit structure, a resource pool may refer to a collection of resource units that a UE can use to send SL signals.

[0136] Resource pools can be classified into several types. For example, each resource pool is classified according to the content of the SL signal transmitted in the resource pool as follows.

[0137] (1) Scheduling Assignment (SA) may include information about the location of resources used by the transmitting UE to transmit the SL data channel, the modulation and coding scheme (MCS) or multiple-input multiple-output (MIMO) transmission scheme required for data channel demodulation, timing advance (TA), etc. SA may be multiplexed with SL data in the same resource unit for transmission. In this case, the SA resource pool may refer to a resource pool in which SA is multiplexed with SL data for transmission. SA may be referred to as an SL control channel.

[0138] (2) The SL data channel (PSSCH) can be a resource pool used by a transmitting UE to send user data. When SA and SL data are multiplexed in the same resource unit for transmission, only the SL data channel other than the SA information can be sent in the resource pool used for the SL data channel. In other words, the RE used to send SA information in an individual resource unit in the SA resource pool can still be used to send SL data in the resource pool of the SL data channel. For example, the transmitting UE can send the PSSCH by mapping the PSSCH to consecutive PRBs.

[0139] (3) The discovery channel may be a resource pool used by a transmitting UE to transmit information such as its ID. The transmitting UE may enable neighboring UEs to discover itself on the discovery channel.

[0140] Even when the SL signal has the same content as described above, different resource pools may be used according to the transmission / reception properties of the SL signal. For example, although the SL data channel or discovery message is the same, different resource pools may be used for the SL signal according to the transmission timing determination scheme of the SL signal (for example, whether the SL signal is transmitted at the reception time of the synchronization reference signal (RS) or at the time obtained by applying a predetermined TA to the reception time), the resource allocation scheme of the SL signal (for example, whether the BS allocates transmission resources of individual signals to individual transmitting UEs or whether the individual transmitting UE selects its own individual signal transmission resources in the resource pool), the signal format of the SL signal (for example, the number of symbols occupied by each SL signal in a subframe or the number of subframes used to transmit one SL signal), the strength of the signal from the BS, the transmission power of the SL UE, etc.

[0141] SL DRX (Side Link Discontinuous Reception)

[0142] The sidelink supports SL DRX for unicast, multicast and broadcast. Similar parameters (on duration, inactivity timer, retransmission timer, period) as for Uu are defined for SL to determine the SL active time for SL DRX. During the SL active time, the UE performs SCI monitoring for data reception (i.e., second stage SCI on PSCCH and PSSCH). The UE can skip monitoring of SCI for data reception during the SL DRX inactive time.

[0143] The actual parameters supported for each broadcast type (unicast, multicast, broadcast) are specified in the following subsections.

[0144] The SL active time of the RX UE includes the time when any of its applicable SL on-duration timers, SL inactivity timers, or SL retransmission timers (for any of unicast, groupcast, or broadcast) are running. In addition, the time slots associated with periodic transmissions announced by the TX UE and the time when the UE is expecting a CSI report (for unicast) after a CSI request are also considered as the SL active time of the RX UE.

[0145] The TX UE maintains a set of timers corresponding to the SL DRX timers in the RX UE for each pair of source / destination L2 IDs for unicast or destination L2 IDs for groupcast / broadcast. When data is available for transmission to one or more RX UEs configured with SL DRX, the TX UE selects resources taking into account the activity time of the RX UE determined by the timers maintained at the TX UE.

[0146] For unicast, SL DRX is configured per pair of source L2 ID and destination L2 ID.

[0147] The UE maintains a set of SL DRX timers for each direction for each pair of source L2 ID and destination L2 ID. The SL DRX configuration for a pair of source / destination L2 IDs in one direction can be negotiated between UEs in the AS layer. For the SL DRX configuration for each direction, where one UE is the TX UE and the other is the RX UE:

[0148] - The RX UE may send assistance information including its desired On-Duration timer, SL DRX start offset and SL DRX cycle to the TX UE, and the Mode 2 TX UE may use it to determine the SL DRX configuration of the RX UE.

[0149] - Regardless of whether auxiliary information is provided, the TX UE in RRC_IDLE / RRC_INACTIVE / OOC or in RRC_CONNECTED and using Mode 2 resource allocation determines the SL DRX configuration of the RX UE. For a TX UE in RRC_CONNECTED and using Mode 1 resource allocation, the SL DRX configuration of the RX UE is determined by the serving gNB of the TX UE.

[0150] - The TX UE sends to the RX UE the SL DRX configuration to be used by the RX UE.

[0151] -RX UE can accept or reject the SL DRX configuration.

[0152] The default SL DRX configuration for multicast / broadcast may be used for DCR messages.

[0153] When the TX UE is in RRC_CONNECTED, the TX UE may report the received assistance information to its serving gNB and send the SL DRX configuration to the RX UE after receiving the SL DRX configuration in dedicated RRC signaling from the gNB. When the RX UE is in RRC_CONNECTED, the RX UE may report the received SL DRX configuration to its serving gNB, e.g., for alignment of Uu and SLDRX configurations.

[0154] SL on-duration timer, SL inactivity timer, SL HARQ RTT timer and SL HARQ retransmission timer are supported in unicast. At the RX UE, the SL HARQ RTT timer and SL HARQ retransmission timer are maintained per SL process. In addition to the (pre)configured values ​​for each of these timers, the SL HARQ RTT timer value may be derived from the retransmission resource timing when the SCI indicates more than one transmission resource.

[0155] The SL DRX MAC CE is introduced only for SL DRX operation in unicast.

[0156] For multicast / broadcast, SL DRX is configured jointly among multiple UEs based on QoS profile and destination L2 ID. For each multicast / broadcast, multiple SL DRX configurations can be supported.

[0157] For multicast, SL on duration timer, SL inactivity timer, SL HARQ RTT and SL retransmission timer are supported. For broadcast, only SL on duration timer is supported. SL DRX period, SL on duration and SL inactivity timer are configured per QoS profile (for multicast only). The start offset and slot offset of the SL DRX period are determined based on the destination L2 ID. SL HARQ RTT timer (for multicast only) and SL HARQ retransmission timer (for multicast only) are not configured per QoS profile or per destination L2 ID. For multicast, the RX UE maintains the SL inactivity timer for each destination L2 ID, and if multiple SL inactivity timer values ​​associated with different QoS profiles are configured for the L2 ID, the largest SL inactivity timer value is selected. For multicast and broadcast, when multiple QoS profiles are configured for each destination L2 ID, the RX UE maintains a single SL DRX period (selected as the minimum SL DRX period of any QoS profile for the L2 ID) and a single SL on duration (selected as the maximum SL on duration of any QoS profile for the L2 ID) for the L2 ID.

[0158] For multicast, at the RX UE, the SL HARQ RTT timer and SL retransmission timer are maintained per SL process. The SL HARQ RTT timer may be set to different values ​​to support both HARQ enabled transmission and HARQ disabled transmission.

[0159] For QoS profiles that are not mapped to any non-default SL DRX configuration, the default SL DRX configuration that is common between multicast and broadcast can be used.

[0160] TX UE and RX UE in coverage of RRC_IDLE / RRC_INACTIVE obtain their SL DRX configuration from SIB. UE (TX or RX) in RRC_CONNECTED can obtain SL DRX configuration from SIB or from dedicated RRC signaling during handover. For out-of-coverage cases, SL DRX configuration is obtained from pre-configuration.

[0161] For multicast, the TX UE, upon receiving new data with the same destination L2 ID, restarts its timer corresponding to the SL inactivity timer for that destination L2 ID (for determining the allowable transmission time).

[0162] TX profiles are introduced to ensure compatibility of multicast and broadcast transmissions between UEs that support / do not support SL DRX functionality. TX profiles are provided by upper layers to the AS layer and identify one or more sidelink functional groups. The TX UE assumes SL DRX for the RX UE only when the associated TX profile corresponds to support for SL DRX. If all destination L2 IDs of concern have an associated TX profile corresponding to support for SL DRX, the RX UE determines to use SL DRX.

[0163] For unicast, multicast and broadcast, alignment of Uu DRX and SL DRX of UE in RRC_CONNECTED is supported. Alignment of Uu DRX and SL DRX at the same UE is supported. In addition, for Mode 1 scheduling, alignment of Uu DRX of TX UE and SL DRX of RX UE is supported.

[0164] The alignment may include full or partial overlap in time between Uu DRX and SL DRX. For SL RX UE in RRC_CONNECTED, the alignment is implemented by the gNB.

[0165] The MAC entity can be configured with SL DRX functionality through RRC, which controls the SCI (i.e., first stage SCI and second stage SCI) monitoring activities of the UE for unicast, groupcast, and broadcast. When using SL DRX operation, the MAC entity shall also monitor the SCI (i.e., first stage SCI and second stage SCI) according to the requirements found in other clauses of this specification.

[0166] RRC controls the sidelink DRX operation by configuring the following parameters:

[0167] -sl-drx-onDurationTimer: duration when SL DRX cycle starts;

[0168] -sl-drx-SlotOffset: Delay before starting sl-drx-onDurationTimer;

[0169] -sl-drx-InactivityTimer (except for broadcast transmission): duration after the first timeslot of SCI (i.e., first phase SCI and second phase SCI) reception (where the SCI indicates a new SL transmission for the MAC entity);

[0170] -sl-drx-RetransmissionTimer (per-side link process except broadcast transmission): maximum duration until SL retransmission is received;

[0171] -sl-drx-StartOffset: The time slot where the SL DRX cycle starts;

[0172] -sl-drx-Cycle: sidelink DRX cycle;

[0173] -sl-drx-HARQ-RTT-Timer (per sidelink process except broadcast transmission): Minimum duration before SL HARQ retransmission expected by the MAC entity.

[0174] When SL DRX is configured, active time includes the following times:

[0175] -sl-drx-onDurationTimer or sl-drx-InactivityTimer is running; or

[0176] -sl-drx-RetransmissionTimer is running; or

[0177] - the period of sl-LatencyBoundCSI-Report configured by RRC in case no SL-CSI Report MAC CE is received; or

[0178] - in case of reception of a SL-CSI reporting MAC CE, the time between sending the SL-CSI reporting request and receiving the SL-CSI reporting MAC CE; or

[0179] -Time slot associated with periodic transmission announced by the UE sending SL-SCH data.

[0180] When one or more SL DRXs are configured, the MAC entity shall:

[0181] 1> If multiple SL DRX cycles are mapped with multiple SL-QoS-profiles of the destination layer-2 ID and the broadcast type of interest is associated with multicast and broadcast:

[0182] 2> Select an sl-drx-Cycle whose length is the shortest of the multiple SL DRX cycles mapped to the multiple SL-QoS-Profiles associated with the destination layer-2ID:

[0183] 2> Select a sl-drx-onDurationTimer whose length is the longest one among multiple SL DRX on-duration timers mapped to multiple SL-QoS-Profiles associated with the destination layer-2 ID.

[0184] 1> If sl-drx-HARQ-RTT-Timer expires:

[0185] 2> If the data of the corresponding sidelink process is not successfully decoded, or if HARQ feedback (i.e., negative acknowledgement) is not sent for unicast due to UL / SL prioritization:

[0186] 3> Start the sl-drx-RetransmissionTimer for the corresponding side link process in the first time slot after the expiration of the sl-drx-HARQ-RTT-Timer.

[0187] When the broadcast type is multicast or broadcast as indicated by the upper layer, sl-drx-StartOffset and sl-drx-SlotOffset are derived according to the following formula:

[0188] sl-drx-StartOffset (ms) = destination layer-2 ID modulo sl-drx-Cycle (ms).

[0189] sl-drx-SlotOffset (ms) = destination layer-2 ID modulo sl-drx-onDurationTimer (ms).

[0190] 1> If SL DRX cycle is used, and [(DFNX10) + subframe number] modulo (sl-drx-Cycle) = sl-drx-StartOffset:

[0191] 2> Start sl-drx-onDurationTimer after sl-drx-SlotOffset from the start of the subframe.

[0192] 1> If SL DRX is in active time:

[0193] 2> Monitor SCI (ie, first stage SCI and second stage SCI) in the SL DRX.

[0194] 2> If SCI indicates a new SL transfer:

[0195] 3> If the source layer-1 ID of the SCI is equal to the 8 LSBs of the expected destination layer-2 ID and the destination layer-1 ID of the SCI is equal to the 8 LSBs of the expected source layer-2 ID, and the broadcast type indicator in the SCI is set to unicast:

[0196] 4> After the first timeslot of SCI reception, start or restart the sl-drx-InactivityTimer for the corresponding source layer-2ID and destination layer-2ID.

[0197] 3> If the destination layer-1 ID of the SCI (i.e., second stage SCI) is equal to the 8 LSBs of the expected destination layer-1 ID, and the broadcast type indicator in the SCI is set to multicast:

[0198] 4> select a sl-drx-InactivityTimer whose length is the largest of the multiple SL DRX inactivity timers mapped to the multiple SL-QoS-Profiles of the destination layer-2 ID associated with the destination layer-1 ID of the SCI; and

[0199] 4> After the first timeslot of SCI reception, start or restart the sl-drx-InactivityTimer for the corresponding destination layer-2ID.

[0200] 2> If SCI indicates SL transfer:

[0201] 3> If PSFCH resources are not configured for SL grant associated with SCI:

[0202] 4>Start the sl-drx-HARQ-RTT-Timer for the corresponding side link process in the time slot after the PSSCH transmission (i.e., the currently received PSSCH) ends.

[0203] 3> If PSFCH resources are configured for SL grant associated with SCI:

[0204] 4> if HARQ feedback is enabled via SCI and the broadcast type indicator in the SCI is set to unicast; or 4> if HARQ feedback is enabled via SCI and the broadcast type indicator in the SCI is set to multicast, and positive-negative acknowledgement is selected;

[0205] 5> start the sl-drx-HARQ-RTT-Timer for the corresponding sidelink process in the first time slot after the corresponding PSFCH transmission carrying SL HARQ feedback ends; or

[0206] 5> When SL HARQ feedback is not sent due to UL / SL prioritization, the sl-drx-HARQ-RTT-Timer for the corresponding sidelink process is started in the first time slot after the corresponding PSFCH resource for SL HARQ feedback ends;

[0207] 4> If HARQ feedback is enabled via SCI and the broadcast type indicator in the SCI is set to multicast, and negative acknowledgement only is selected;

[0208] 5> start the sl-drx-HARQ-RTT-Timer for the corresponding sidelink process in the first time slot after the corresponding PSFCH transmission carrying SL HARQ feedback ends; or

[0209] 5> when SL HARQ feedback is not sent due to UL / SL prioritization, start the sl-drx-HARQ-RTT-Timer for the corresponding sidelink process in the first time slot after the end of the corresponding PSFCH resource used for SL HARQ feedback; or

[0210] 5> When the SL HARQ feedback is a positive confirmation, the sl-drx-HARQ-RTT-Timer for the corresponding side link process is started in the first time slot after the corresponding PSFCH resource used for the SL HARQ feedback ends.

[0211] 4> If HARQ feedback is disabled by SCI and resources for one or more retransmission opportunities are not scheduled in SCI:

[0212] 5> Start the sl-drx-HARQ-RTT-Timer for the corresponding side link process in the time slot after the PSFCH resource ends.

[0213] 4> If HARQ feedback is disabled by SCI and resources for one or more retransmission opportunities are scheduled in SCI:

[0214] 5>Start the sl-drx-HARQ-RTT-Timer for the corresponding side link process in the time slot after the PSSCH transmission (i.e., the currently received PSSCH) ends.

[0215] NOTE: When the SCI indicates the next retransmission resource, the sl-drx-HARQ-RTT-Timer is derived from the retransmission resource timing (i.e., the next immediately following retransmission resource indicated in the SCI). When the SCI does not indicate the next retransmission resource, the UE uses the configured sl-drx-HARQ-RTT-Timer.

[0216] 3> Stop the sl-drx-RetransmissionTimer for the corresponding side link process.

[0217] 1> If a SL DRX Command MAC CE is received for a source layer-2ID and destination layer-2ID pair for unicast:

[0218] 2> Stop sl-drx-onDurationTimer for the source layer-2ID and destination layer-2ID pair for unicast;

[0219] 2> Stop the sl-drx-InactivityTimer for the source layer-2ID and destination layer-2ID pair for unicast.

[0220] Inter-UE Coordination (IUC)

[0221] SL UEs can support inter-UE coordination (IUC) in Mode 2, whereby UE-A sends information about resources to UE-B, which then uses this information for resource (re)selection. The following inter-UE coordination schemes are supported:

[0222] - IUC scheme 1, where the coordination information sent from UE-A to UE-B is the preferred and / or non-preferred resources for UE-B's transmission, and

[0223] - IUC scheme 2, where the coordination information sent from UE-A to UE-B is that there is an expected / potential resource conflict on the resources indicated by UE-B's SCI.

[0224] In scheme 1, IUC may be triggered by an explicit request from UE-B or by a condition at UE-A. UE-A determines a set of resources reserved by other UEs or a time slot in which UE-A does not expect to perform SL reception from UE-B due to half-duplex operation when UE-A is the intended receiver of UE-B. UE-A uses these resources as a set of non-preferred resources or excludes these resources to determine a set of preferred resources, and sends preferred / non-preferred resources to UE-B. UE-B's resources for resource (re)selection may be based on both the sensing results of UE-B (if available) and the coordination information received from UE-A, or it may be based only on the coordination information received from UE-A. For scheme 1, MAC CE and the second stage SCI, or only MAC CE, may be used to send IUC. Explicit requests and reports for IUC in unicast are supported.

[0225] In scheme 2, UE-A determines expected / potential resource conflicts within the resources indicated by the SCI of UE-B as resources reserved by other UEs and identified by UE-A as fully / partially overlapping with the resources indicated by the SCI of UE-B, or as time slots where UE-A is the intended receiver of UE-B and does not expect to perform SL reception on those time slots due to half-duplex operation. UE-B uses the conflicting resources to determine the resources to be reselected, and excludes the conflicting resources from the reselected resources. For scheme 2, PSFCH is used to transmit IUC.

[0226] The Sidelink Inter-UE Coordination Request (SL-IUC Req) transmission procedure is used to trigger the peer UE to send sidelink inter-UE coordination information.

[0227] The Sidelink Inter-UE Coordination Information (SL-IUC Info) reporting procedure is used to provide inter-UE coordination information to peer UEs.

[0228] -sl-LatencyBoundIUC-Report, which is maintained for each PC5-RRC connection.

[0229] The MAC entity maintains a sl-IUC-ReportTimer for each pair of source layer-2 ID and destination layer-2 ID corresponding to the PC5-RRC connection. The sl-IUC-ReportTimer is used for the SL-IUC information reporting UE to comply with the latency requirement signaled by the UE from the IUC-Information trigger. The value of the sl-IUC-ReportTimer is the same as the latency requirement of the SL-IUC information in the sl-LatencyBoundIUC-Report configured via RRC.

[0230] The MAC entity shall, for each pair of source Layer-2 ID and destination Layer-2 ID corresponding to a PC5-RRC connection that has been established by upper layers:

[0231] 1> If the SL-IUC information report has been triggered by the SL-IUC request MAC CE (and / or SCI) and has not been cancelled:

[0232] 2> If the sl-IUC-ReportTimer for the triggered SL-IUC information report is not running:

[0233] 3>Start sl-IUC-ReportTimer.

[0234] 2> If the sl-IUC-ReportTimer for the triggered SL-IUC information report expires:

[0235] 3>Cancel the triggered SL-IUC information report.

[0236] 2> Otherwise, if the MAC entity has SL resources allocated for new transmissions and due to logical channel prioritization, the SL-SCH resources can accommodate the SL-IUC information MAC CE and its subheader:

[0237] 3> Indicates the multiplexing and assembly process to generate the sidelink inter-UE coordination information MAC CE as defined in clause 6.1.3.35;

[0238] 3> Stop the sl-IUC-ReportTimer for the triggered SL-IUC information report;

[0239] 3>Cancel the triggered SL-IUC information report.

[0240] Fig. 9 The inter-UE coordination information MAC CE is illustrated.

[0241] The inter-UE coordination information MAC CE is identified by a MAC subheader with LCID specified in Table 5.

[0242] [Table 5]

[0243]

[0244] The priority of the Inter-UE Coordination Information MAC CE is fixed to '1'. It has a variable size with the following fields:

[0245] -RT: This field indicates the resource set type, i.e., preferred resource set or non-preferred resource set, as the code point value of the SCI format 2-CresourceSetType field.

[0246] -RSL: This field indicates the location of the reference slot as the code point value of the referenceSlotLocation field of SCI format 2-C. The length of this field is 17 bits. If the length of the referenceSlotLocation field in SCI format 2-C is shorter than 17 bits, this field contains the referenceSlotLocation field using the LSB bit;

[0247] -LSIi: This field indicates the lowest subchannel index of the first resource position of each TRIV as the code point value of the Lowest Index field of SCI format 2-C. LSI0 indicates the lowest subchannel index of the first resource position of the TRIV within the first resource combination, LSI1 indicates the lowest subchannel index of the first resource position of the TRIV within the second resource combination, and so on. The length of this field is 5 bits. If the length of the Lowest Index field in SCI format 2-C is shorter than 5 bits, this field contains the Lowest Index field using the LSB bit;

[0248] -RCi: This field indicates the resource combination as the code point value of the resourceCombination field of SCI format 2-C. RC0 indicates the first resource combination, RC1 indicates the second resource combination, and so on. [The maximum number of resource combinations included is 8]. The length of this field is 26 bits. If the length of the resourceCombination field in SCI format 2-C is shorter than 26 bits, this field contains the resourceCombination field using the LSB bit;

[0249] -First Resource Location i-1: This field indicates the first resource location as the code point value of the firstResourceLocation field of SCI format 2-C. First Resource Location 0 indicates the first resource location of the second resource combination, first Resource Location 1 indicates the first resource location of the third resource combination, and so on. The length of this field is 13 bits. If the length of the firstResourceLocation field in SCI format 2-C is shorter than 13 bits, this field contains the firstResourceLocation field using the LSB bit;

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

[0251] Fig.10 An inter-UE coordination request MAC CE is illustrated.

[0252] The Inter-UE Coordination Request MAC CE is identified by a MAC subheader with LCID as specified in Table 5. The priority of the Inter-UE Coordination Request MAC CE is fixed to '1'. It has a variable size with the following fields:

[0253] -RT: This field indicates the resource set type, ie, preferred resource set or non-preferred resource set, as the code point value of the SCI format 2-C resourceSetType field.

[0254] -RP: This field indicates the resource reservation period as the code point value of the resourceReservationPeriod field in SCI format 2-C. The length of this field is 4 bits. If the length of the resourceReservationPeriod field in SCI format 2-C is shorter than 4 bits, this field contains the resourceReservationPeriod field using the LSB bit;

[0255] - Priority: This field indicates the priority as the code point value of the SCI format 2-C priority field. The length of this field is 3 bits;

[0256] -RSWL: This field indicates the resource selection window location as the code point value of the SCI format 2-CresourceSelectionWindowLocation field. The length of this field is 34 bits. If the length of the resourceSelectionWindowLocation field in SCI format 2-C is shorter than 34 bits, this field contains the resourceSelectionWindowLocation field using the LSB bit;

[0257] - Number of subchannels: This field indicates the number of subchannels as the code point value of the SCI format 2-C numberOfSubchannel field. The length of this field is 5 bits. If the length of the numberOfSubchannel field in SCI format 2-C is shorter than 5 bits, this field contains the numberOfSubchannel field using the LSB bit;

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

[0259] Sidelink Relay

[0260] Sidelink relay is introduced to support 5G ProSe UE to Network Relay (U2N Relay) functionality to provide connectivity to the network for U2N remote UEs. Both L2 and L3 U2N relay architectures are supported. The L3 U2N relay architecture is transparent to the serving RAN of the U2N relay UE, except for controlling the sidelink resources.

[0261] Relay Discovery: The AS functionality enables 5G ProSe UE to network relay discovery, using NR technology but without traversing any network nodes.

[0262] U2N Relay UE: A UE that provides a U2N Remote UE with the functionality of supporting connection to the network.

[0263] U2N Remote UE: A UE that communicates with the network via a U2N Relay UE.

[0264] Upstream: In the IAB topology, in the direction toward the parent node.

[0265] Uu Relay RLC Channel: RLC channel between L2 U2N Relay UE and gNB, which is used for L2UE to network relay transmission packets over Uu.

[0266] A U2N relay UE should be in RRC_CONNECTED to perform relay of unicast data.

[0267] For L2 U2N relay operation, the following RRC state combinations are supported:

[0268] - Both the U2N relay UE and the U2N remote UE should be in RRC_CONNECTED to perform transmission / reception of relayed unicast data.

[0269] - The U2N relay UE may be in RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED as long as all U2N remote UEs connected to the U2N relay UE are in RRC_INACTIVE or RRC_IDLE.

[0270] For L2 U2N relay, the U2N remote UE can only be configured to use resource allocation mode 2 for the data to be relayed.

[0271] A single unicast link is established between one L2 U2N relay UE and one L2 U2N remote UE. Traffic of the U2N remote UE via a given U2N relay UE and traffic of the U2N relay UE should be separated in different Uu RLC channels on Uu.

[0272] Protocol stack for SL relay

[0273] Fig.11 (a) User plane protocol stack and (b) control plane protocol stack for L2 UE to network relay are illustrated.

[0274] exist Fig.11 (a) and Fig.11The protocol stacks for the user plane and control plane of the L2 U2N relay architecture are presented in (b). The SRAP sublayer is placed above the RLC sublayer of both CP and UP at both the PC5 interface and the Uu interface. UuSDAP, PDCP and RRC are terminated between the L2 U2N remote UE and the gNB, while SRAP, RLC, MAC and PHY are terminated in each hop (i.e., the link between the L2 U2N remote UE and the L2 U2N relay UE and the link between the L2 U2N relay UE and the gNB).

[0275] For L2 U2N relay, the SRAP sublayer on the PC5 hop is used only for bearer mapping purposes. The SRAP sublayer does not exist on the PC5 hop for relaying messages for L2 U2N remote UEs on BCCH and PCCH. For messages about SRB0 for L2 U2N remote UEs, the SRAP sublayer does not exist on the PC5 hop, but the SRAP sublayer exists on the Uu hop for both DL and UL.

[0276] For L2 U2N relay, for uplink:

[0277] - The Uu SRAP sublayer supports UL bearer mapping between the ingress PC5 relay RLC channel for relay and the egress Uu relay RLC channel on the L2 U2N relay UEUu interface. For uplink relay services, different end-to-end RBs (SRBs or DRBs) of the same remote UE and / or different remote UEs can be multiplexed on the same Uu relay RLC channel.

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

[0279] -L2 U2N The PC5 SRAP sublayer at the remote UE supports UL bearer mapping between the remote UE Uu radio bearers and the egress PC5 relay RLC channels.

[0280] For L2 U2N relay, for downlink:

[0281] -The Uu SRAP sublayer supports DL bearer mapping at the gNB to map the end-to-end radio bearers (SRBs, DRBs) of the remote UE to the Uu relay RLC channel over the relay UE Uu interface. The Uu SRAP sublayer supports DL bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRBs or DRBs) of one L2 U2N remote UE and / or different L2 U2N remote UEs and one Uu relay RLC channel over the relay UE Uu interface.

[0282] - The Uu SRAP sublayer supports remote UE identification for DL ​​traffic. The identification information of the remote UE Uu radio bearer and the local remote UE ID are included by the gNB into the Uu SRAP header at DL so that the relay UE maps packets received from the remote UE Uu radio bearer to its associated PC5 relay RLC channel.

[0283] - The PC5 SRAP sublayer at the relay UE supports DL bearer mapping between the ingress Uu relay RLC channel and the egress PC5 relay RLC channel.

[0284] - The PC5 SRAP sublayer at the remote UE associates the received packets of a specific PDCP entity associated with the correct Uu radio bearer of the remote UE based on the identification information included in the Uu SRAP header.

[0285] The Local Remote UE ID is included in both the PC5 SRAP header and the Uu SRAP header. The L2 U2N relay UE is configured by the gNB with the Local Remote UE ID to be used in the SRAP header. The remote UE obtains the Local Remote ID from the gNB via Uu RRC messages including RRCSetup, RRCReconfiguration, RRCResume, and RRCReestablishment. Uu DRBs and Uu SRBs are mapped to different PC5 relay RLC channels and Uu relay RLC channels in both the PC5 hop and the Uu hop.

[0286] The gNB is responsible for avoiding conflicts in the use of the Local Remote UE ID. The gNB may update the Local Remote UE ID by sending the updated Local Remote ID to the relay UE via an RRCReconfiguration message. The serving gNB may perform the Local Remote UE ID update independently of the PC5 unicast link L2 ID update procedure.

[0287] Fig.12 A protocol stack for UE-to-network relay discovery messages is illustrated.

[0288] Supports both Model A discovery model and Model B discovery model for U2N relay discovery. Fig.12 The protocol stack used for discovery is presented in .

[0289] The U2N remote UE may perform relay discovery message transmission and may monitor the relay discovery message on the sidelink when in RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED. The network may broadcast a threshold value that is used by the U2N remote UE to determine whether it can send a relay discovery solicitation message to the U2N relay UE.

[0290] A U2N relay UE may perform relay discovery message transmission and may monitor relay discovery messages on the sidelink while in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED. The network may broadcast a maximum Uu RSRP threshold, a minimum Uu RSRP threshold, or both, which the U2N relay UE uses to determine whether it can send a relay discovery message to a U2N remote UE.

[0291] The network may use broadcast or dedicated signaling to provide relay discovery configuration for relay discovery. In addition, U2N remote UE and U2N relay UE may use pre-configuration for relay discovery.

[0292] The resource pool for NR side link communication can be used for relay discovery, or the network can configure a resource pool dedicated to relay discovery. The resource pool dedicated to relay discovery can be configured simultaneously with the resource pool for NR side link communication in system information, dedicated signaling and / or pre-configuration. Whether to configure a resource pool dedicated to relay discovery is based on network implementation. If a resource pool dedicated to relay discovery is configured, only those resource pools dedicated to relay discovery should be used for relay discovery. If only resource pools for NR side link communication are configured, all configured transmission resource pools can be used for relay discovery and side link communication.

[0293] For a U2N remote UE that has connected to the network via a U2N relay UE (including both in-coverage and out-of-coverage cases), only resource allocation mode 2 is used for discovery message transmission.

[0294] Relay discovery reuses the NR sidelink resource allocation principles for in-coverage U2N relay UEs and for both in-coverage and out-of-coverage U2N remote UEs.

[0295] The sidelink power control used to transmit relay discovery messages is the same as that used for NR sidelink communications.

[0296] No ciphering or integrity protection in the PDCP layer is applied to the Relay Discovery message.

[0297] The UE can determine from SIB12 whether the gNB supports relay discovery, non-relay discovery, or both.

[0298] Relay selection / reselection

[0299] The U2N Remote UE performs radio measurements at the PC5 interface and uses them together with higher layer criteria for U2N Relay selection and reselection. When there is no unicast PC5 connection between the U2N Relay UE and the U2N Remote UE, the U2N Remote UE uses SD-RSRP measurements to evaluate whether the PC5 link quality towards the U2N Relay UE meets the relay selection criteria.

[0300] For relay reselection, when there is data transmission from the U2N relay UE to the U2N remote UE, the U2N remote UE uses the SL-RSRP measurement towards the serving U2N relay UE for relay reselection trigger evaluation, and in the absence of data transmission from the U2N relay UE to the U2N remote UE, whether SL-RSRP or SD-RSRP is used for relay reselection trigger evaluation depends on the UE implementation.

[0301] If the PC5 link quality measured by the U2N Remote UE towards the U2N Relay UE exceeds a configured threshold (pre-configured or provided by the gNB), the U2N Relay UE is considered suitable in terms of radio criteria. The U2N Remote UE searches for a suitable U2N Relay UE candidate that meets all AS layer and higher layer criteria (see TS 23.304 [xx]). If there are multiple such suitable U2N Relay UEs, one U2N Relay UE is selected among them depending on the U2N Remote UE implementation. For L2 U2N Relay (re)selection, PLMN ID and Cell ID may be used as additional AS criteria.

[0302] The U2N remote UE triggers the U2N relay selection in the following cases:

[0303] -The direct Uu signal strength of the current serving cell of the U2N remote UE is lower than the configured signal strength threshold;

[0304] - Indicated by upper layers of the U2N remote UE.

[0305] The U2N remote UE can trigger U2N relay reselection in the following situations:

[0306] -The current PC5 signal strength of the U2N relay UE is lower than the (pre-)configured signal strength threshold;

[0307] -Cell (reselection) selection, handover or Uu RLF has been indicated by the U2N relay UE via PC5-RRC signalling;

[0308] -When the remote UE receives a PC5-S link release message from the U2N relay UE;

[0309] -When the U2N remote UE detects PC5 RLF;

[0310] -Instructed by upper layer.

[0311] For L2 U2N remote UE and L3 U2N remote UE in RRC_IDLE / INACTIVE, the cell (re)selection process and relay (re)selection process run independently. If both a suitable cell and a suitable U2N relay UE are available, the selection of the cell or the U2N relay UE depends on the UE implementation. The L3 U2N remote UE can select both the cell and the U2N relay UE at the same time, and this depends on the implementation of the L3 U2N remote UE.

[0312] For both L2 and L3 U2N relay UEs in RRC_IDLE / INACTIVE, the PC5-RRC message is used to notify its connected remote UEs when the U2N relay UE selects a new cell. The PC5-RRC message is also used to notify its connected L2 or L3 U2N remote UEs when the L2 / L3 U2N relay UE performs a handover or detects a Uu RLF. After receiving the PC5 RRC message for notification, whether to release or maintain the unicast PC5 link depends on the U2N remote UE implementation. If the U2N remote UE decides to release the unicast PC5 link, it triggers the L2 release procedure and can perform relay reselection.

[0313] Control plane procedures for L2 U2N relay

[0314] 1)RRC connection management

[0315] U2N remote UE needs to establish its own PDU session / DRB with the network before user plane data transmission.

[0316] Before the U2N remote UE establishes a Uu RRC connection with the network via the U2N relay UE, the NR V2X PC5 unicast link establishment procedure may be reused to establish a secure unicast link between the U2N remote UE and the U2N relay UE.

[0317] The establishment of Uu SRB1 / SRB2 and DRB of U2N remote UE is subject to the Uu configuration process from L2 UE to network relay.

[0318] Fig.13 The procedure for L2 U2N remote UE connection establishment is illustrated. Fig.13 The following high-level connection establishment process applies to L2 U2N trunking:

[0319] 1. The U2N Remote and U2N Relay UEs perform the discovery procedure and establish a PC5-RRC connection using NR V2X procedures.

[0320] 2. The U2N Remote UE sends a first RRC message (i.e., RRCSetupRequest) for its connection establishment with the gNB via the Relay UE using the designated PC5 Relay RLC channel configuration. If the U2N Relay UE is not in RRC_CONNECTED, it needs to do its own connection establishment after receiving the message on the designated PC5 Relay RLC channel. During the RRC connection establishment procedure of the Relay UE, the gNB may configure the SRB0 Relay Uu Relay RLC channel to the U2N Relay UE. The gNB responds to the U2N Remote UE with an RRCSetup message. An RRCSetup message is sent to the U2N Remote UE using the SRB0 Relay channel on Uu and the designated PC5 Relay RLC channel on PC5.

[0321] 3. gNB and U2N Relay UE perform the Relay Channel Establishment Procedure on Uu. Based on the configuration from gNB, U2N Relay / Remote UE establishes PC5 Relay RLC channel for relaying SRB1 towards U2N Remote / Relay UE on PC5.

[0322] 4. The RRCSetupComplete message is sent by the U2N remote UE to the gNB via the U2N relay UE using the SRB1 relay channel on PC5 and the SRB1 relay channel configured for the U2N relay UE on Uu. The U2N remote UE then establishes an RRC connection on Uu.

[0323] 5. The U2N remote UE and gNB establish security following Uu procedures and forward security messages via the U2N relay UE.

[0324] 6. The gNB sends an RRCReconfiguration message to the U2N Remote UE via the U2N Relay UE to set up SRB2 / DRB for relay purposes. The U2N Remote UE sends an RRCReconfigurationComplete message to the gNB via the U2N Relay UE in response. In addition, the gNB configures an additional Uu Relay RLC channel between the gNB and the U2N Relay UE and a PC5 Relay RLC channel between the U2N Relay UE and the U2N Remote UE for relay services.

[0325] 2) Radio link failure

[0326] When a U2N remote UE is connected to the gNB via a U2N relay UE, the U2N remote UE in RRC_CONNECTED suspends Uu RLM.

[0327] The U2N relay UE declares a Radio Link Failure (RLF) following the same criteria.

[0328] After declaring RLF, the U2N relay UE also takes the following actions on top of the actions:

[0329] - The PC5-RRC message may be used to send an indication to the U2N remote UE to which it is connected, which may trigger the RRC connection re-establishment (Connection Re-establishmen) for the U2N remote UE.

[0330] After detecting PC5 RLF, the U2N remote UE can trigger connection re-establishment.

[0331] 3)RRC connection reestablishment

[0332] The U2N remote UE may perform the following actions during the RRC connection reestablishment procedure:

[0333] - If only a suitable cell is available, the U2N remote UE initiates the RRC re-establishment procedure towards the suitable cell;

[0334] - If only a suitable U2N relay UE is available, the U2N remote UE initiates an RRC re-establishment procedure towards the serving cell of the suitable relay UE;

[0335] - If both a suitable cell and a suitable relay are available, the U2N remote UE may select either one to initiate the RRC re-establishment procedure based on implementation.

[0336] 4)RRC connection recovery

[0337] The RRC connection recovery mechanism is applied to the U2N remote UE.

[0338] 5) System Information

[0339] The U2N remote UE in coverage is allowed to obtain any necessary SIBs over the Uu interface regardless of its PC5 connection with the relay UE. The U2N remote UE can also receive system information from the relay UE after the PC5 connection with the U2N relay UE is established.

[0340] A U2N remote UE in RRC_CONNECTED may request SIBs via a U2N relay UE using the on-demand SIB framework. A U2N remote UE in RRC_IDLE or RRC_INACTIVE may notify the U2N relay UE of the type of SIB it requested via a PC5-RRC message. The U2N relay UE then triggers the on-demand SI / SIB acquisition procedure based on its own RRC state (if necessary) and sends the acquired SI / SIB to the U2N remote UE via PC5-RRC.

[0341] A U2N Remote UE in RRC_IDLE or RRC_INACTIVE may request (from the U2N Relay UE or the network) any SIBs that the U2N Remote UE requires to use (e.g. for relay purposes). For SIBs that the U2N Remote UE has requested from the U2N Relay UE, the U2N Relay UE forwards them again in case of any updates to the requested SIBs. In the case of a U2N Remote UE in RRC_CONNECTED, the network is responsible for sending updated SIBs to the U2N Remote UE when the SIBs are updated. The U2N Remote UE deconfigures the SI request to the U2N Relay UE when entering the RRC_CONNECTED state.

[0342] For SIB1 forwarding, for U2N remote UEs, the U2N relay UE supports both request-based delivery (i.e., SIB1 request by the U2N remote UE) and unsolicited forwarding, where which one is used depends on the U2N relay UE implementation. If SIB1 changes, the U2N relay UE always forwards SIB1 for U2N remote UEs in RRC_IDLE or RRC_INACTIVE.

[0343] For L2 U2N remote UEs in RRC_IDLE or RRC_INACTIVE, the L2 U2N relay UE does not forward short messages on the Uu interface to the L2 U2N remote UEs. The L2 U2N relay UE may forward the PWS SIB to its connected L2 U2N remote UEs.

[0344] L2 U2N relay UE supports RAN sharing. In particular, before establishing a PC5-RRC connection, the L2 U2N relay UE can forward cell access related information via a discovery message.

[0345] 6) Paging

[0346] When both the U2N relay UE and the U2N remote UE are in RRC IDLE or RRC INACTIVE, the U2N relay UE monitors the paging occasion of the U2N remote UE to which it is connected. When the U2N relay UE needs to monitor the paging of the U2N remote UE, the U2N relay UE shall monitor all POs of the U2N remote UE.

[0347] When the U2N Relay UE is in RRC CONNECTED and the U2N Remote UE is in RRC_IDLE or RRC_INACTIVE, there are two options for paging delivery:

[0348] - If the active DL BWP of the U2N relay UE is configured with CORESET and paging search space, the U2N relay UE monitors the PO of its connected U2N remote UE.

[0349] -Delivery of paging for U2N remote UEs may be performed by a dedicated RRC message from the gNB to the U2N relay UE. The dedicated RRC message for delivering remote UE paging to an RRC_CONNECTED relay UE may contain one or more remote UE IDs (5G-S-TMSI or I-RNTI).

[0350] The decision of which of the above two options to use depends on the network implementation.If configured with a paging search space, a U2N relay UE in RRC CONNECTED may determine whether to monitor PO for a U2N remote UE based on PC5-RRC signaling received from the U2N remote UE.

[0351] The U2N remote UE in RRC_IDLE provides the 5G-S-TMSI and UE-specific DRX cycle (configured by upper layers) to the U2N relay UE to request the U2N relay UE to perform PO monitoring. The U2N remote UE in RRC_INACTIVE provides the minimum of two UE-specific DRX cycles (configured by upper layers and configured by RAN), 5G-S-TMSI and I-RNTI to the U2N relay UE for PO monitoring. The L2 U2N relay UE can notify the gNB of the remote UE information (i.e., 5G-S-TMSI / I-RNTI) via the SidelinkUEInformationNR message for paging delivery purposes. The U2N relay UE receives the paging message to check the 5G-S-TMSI / I-RNTI and sends the relevant paging record to the remote UE accordingly.

[0352] The U2N relay UE may use unicast signaling to send paging to the U2N remote UE via PC5.

[0353] 7) Access Control

[0354] The U2N remote UE performs unified access control. The U2N relay UE in RRC-CONNECTED does not perform UAC for the data of the U2N remote UE.

[0355] 8) Mobility registration update and RAN area update

[0356] When a L2 U2N remote UE is connected to a L2 U2N relay UE, it performs a mobility registration update / RNAU based on the serving cell of the L2 U2N relay UE. If the serving cell changes (due to a cell change of the U2N relay UE) and the new serving cell is outside the configured RNA / TA of the U2N remote UE, the L2 U2N remote UE in RRC_IDLE or RRC_INACTIVE initiates a mobility registration update / RNAU procedure.

[0357] Service continuity for L2 U2N trunking

[0358] 1) Transition from indirect to direct path

[0359] Fig.14 The process of U2N remote UE switching to direct Uu cell is illustrated.

[0360] For service continuity over L2 U2N relay, in case the U2N remote UE switches to direct path, the following procedure is used:

[0361] 1. Perform Uu measurement configuration and measurement report signaling procedures to evaluate both relay link measurements and Uu link measurements. When the configured measurement report criteria are met, the measurement results from the U2N remote UE are reported. The sidelink relay measurement report shall include at least the source L2 ID of the U2N relay UE, the serving cell ID (i.e., NCGI), and the sidelink measurement quantity information. The sidelink measurement quantity may be the SL-RSRP of the serving U2N relay UE, and if SL-RSRP is not available, SD-RSRP is used.

[0362] 2. The gNB decides to switch the U2N remote UE to the direct Uu path.

[0363] 3. The gNB sends an RRCReconfiguration message to the U2N remote UE. The U2N remote UE stops UP and CP transmission via the U2N relay UE after receiving the RRCReconfiguration message from the gNB.

[0364] 4. The U2N remote UE synchronizes with the gNB and performs random access.

[0365] 5. The UE (i.e., the U2N Remote UE in the previous step) sends an RRCReconfigurationComplete to the gNB via a direct path using the configuration provided in the RRCReconfiguration message. According to this step, the UE (i.e., the U2N Remote UE in the previous step) uses an RRC connection via a direct path to the gNB.

[0366] 6. The gNB sends an RRCReconfiguration message to the U2N Relay UE to reconfigure the connection between the U2N Relay UE and the gNB. The RRCReconfiguration message to the U2N Relay UE may be sent at any time after step 3 based on the gNB implementation (e.g., to release the Uu and PC5 Relay RLC channel configurations for relaying, and the bearer mapping configuration between PC5 RLC and Uu RLC).

[0367] 7. The U2N relay UE or the U2N remote UE may initiate a PC5 unicast link release (PC5-S). The timing of performing the link release depends on the UE implementation. After receiving the RRC reconfiguration from the gNB in ​​step 6, the U2N relay UE may perform a PC5 connection reconfiguration to release the PC5 relay RLC channel for relaying, or after receiving the RRC reconfiguration from the gNB in ​​step 3, the UE (i.e., the previous U2N remote UE) may perform a PC5 connection reconfiguration to release the PC5 relay RLC channel for relaying.

[0368] 8. The data path is switched from the indirect path between the UE (i.e., the previous U2N remote UE) and the gNB to the direct path. DL / UL lossless delivery during the path switch is accomplished according to the PDCP data recovery procedure.

[0369] Note: Step 8 can be performed at any time after Step 4. Step 8 is independent of Step 6 and Step 7.

[0370] 2) Transition from direct to indirect path

[0371] Fig.15 The process of U2N remote UE switching to indirect path is illustrated.

[0372] The gNB may select a U2N relay UE in any RRC state (i.e., RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED) as a target U2N relay UE for the transition of the direct to indirect path.

[0373] For service continuity of L2 U2N remote UE, in case the L2 U2N remote UE switches to an indirect path via a U2N relay UE in RRC_CONNECTED, the following procedure is used:

[0374] 1. After the U2N remote UE measures / discovers the candidate U2N relay UE, the U2N remote UE reports one or more candidate U2N relay UEs and Uu measurements.

[0375] - The UE may filter appropriate U2N relay UEs according to the relay selection criteria before reporting. The UE shall only report U2N relay UE candidates that meet higher layer criteria.

[0376] - The report may include at least the U2N relay UE ID, the serving cell ID of the U2N relay UE and the sidelink measurement quantity information. The sidelink measurement quantity may be the SL-RSRP of the candidate U2N relay UE, and if the SL-RSRP is not available, the SD-RSRP is used.

[0377] 2. The gNB decides to transfer the U2N remote UE to the target U2N relay UE. Then, the gNB sends an RRCReconfiguration message to the target U2N relay UE, which may include at least the local ID and L2ID of the remote UE, the Uu and PC5 relay RLC channel configuration for relaying, and the bearer mapping configuration.

[0378] 3. The gNB sends an RRCReconfiguration message to the U2N remote UE. The content in the RRCReconfiguration message may include at least the U2N relay UE ID, the PC5 relay RLC channel configuration for the relay service, and the associated end-to-end radio bearers. After receiving the RRCReconfiguration message from the gNB, the U2N remote UE stops UP and CP transmission over Uu.

[0379] 4. The U2N remote UE establishes a PC5 connection with the target U2N relay UE.

[0380] 5. The U2N remote UE completes the path switching process by sending an RRCReconfigurationComplete message to the gNB via the relay UE.

[0381] 6. The data path is converted from the direct path to the indirect path between the U2N remote UE and the gNB.

[0382] In the case where the selected U2N relay UE for direct to indirect path switching is in RRC_IDLE or RRC_INACTIVE, after receiving the path switching command, the U2N remote UE establishes a PC5 link with the U2N relay UE and sends an RRCReconfigurationComplete message via the U2N relay UE, which will trigger the U2N relay UE to enter the RRC_CONNECTED state. Fig.15 The process of U2N remote UE switching to indirect path in may also be applied to the case where the selected U2N relay UE for direct to indirect path switching is in RRC_IDLE or RRC_INACTIVE, except that step 4 is performed before step 2.

[0383] Sidelink Discovery

[0384] The UE may perform NR sidelink discovery when in-coverage or out-of-coverage for non-relay operation.

[0385] The relay discovery mechanism (in addition to the discovery message transmission based on U2N relay-specific thresholds) is also applied to sidelink discovery.

[0386] Relay-based measurement of service continuity from direct to indirect paths

[0387] Fig.16 and Fig.17 is a diagram for explaining a method of performing handover for direct-indirect path switching or indirect-indirect path switching for a remote UE.

[0388] According to the prior art, when the relay UE and the remote UE are configured with UE-to-network relay (U2N relay) functions, the relay UE provides connectivity to the network for the U2N remote UE. In this case, the remote UE does not have a direct connection with the network while maintaining an indirect connection based on the U2N relay function.

[0389] For U2N operation, the remote UE should perform HO from one indirect path to another indirect path or from a direct path to an indirect path. However, the prior art does not provide an inter-gNB handover from a direct / indirect path of a source gNB to an indirect path of a target gNB.

[0390] The method for performing a direct-to-indirect path switching or an indirect-to-indirect path switching for a remote UE comprises the following steps:

[0391] 1. The relay UE and the remote UE establish a PC5 unicast link and a PC5-RRC connection (S161).

[0392] 2. Upon request from the remote UE or if the relay UE supports U2N relay, the relay UE informs the remote UE of the relay UE's serving cell via a PC5-RRC message.

[0393] - The PC5-RRC message includes the global cell ID of the serving cell (eg, the PCell of the relay UE).

[0394] 3. The relay UE may be configured with measurements on the serving cell of the remote UE and / or the relay UE through the gNB or the remote UE.

[0395] -The remote UE may receive a configuration from the gNB. The remote UE may then configure measurements to be performed by the relay UE based on the configuration received from the gNB.

[0396] 4. If configured, the relay UE reports the measurement results about the remote UE and / or the serving cell of the relay UE to the gNB or the remote UE. The gNB may be the serving gNB of the relay UE or the serving gNB of the remote UE (S162). Depending on the configuration, the report is triggered periodically or based on an event (e.g., an A1 event, an A2 event, or an A3 event).

[0397] A. If the measurement result about the serving cell is higher than the threshold configured by the remote UE or gNB (i.e., A1 event), the relay UE notifies the remote UE of the measurement result about the serving cell with the serving cell ID via a PC5-RRC message. The relay UE may also notify the remote UE of the measurement result about the remote UE via the same PC5-RRC message.

[0398] B. If the measurement result about the remote UE is higher than the threshold configured by the remote UE or the gNB, the relay UE notifies the remote UE of the measurement result about the remote UE via a PC5-RRC message. The relay UE may also notify the remote UE of the measurement result about the serving cell with the serving cell ID of the relay UE via the same PC5-RRC message.

[0399] 5. Upon receiving the serving cell of the relay UE from the relay UE, the remote UE indicates the serving cell of the relay UE (e.g., the global cell ID of the serving cell) to the gNB of the remote UE via an RRC message.

[0400] A. The remote UE reports the measurement results about the serving cell of the remote UE and / or relay UE to the gNB in ​​the same RRC message.

[0401] B. The remote UE reports the measurement results about the relay UE and / or the remote UE’s serving cell to the gNB in ​​the same RRC message.

[0402] C. Upon receiving the serving cell of the relay UE from the relay UE, the remote UE may measure the serving cell of the relay UE and then report the measurement result about the serving cell of the relay UE to the gNB of the remote UE via the same RRC message.

[0403] D. The remote UE may report measurement results on neighboring cells that are above a threshold in descending order of the measurement results to the remote UE's gNB via the same RRC message.

[0404] 6. After receiving the measurement results from the relay UE, the remote UE reports the measurement results about the serving cell of the relay UE to the gNB of the remote UE.

[0405] A. The measurement report of the gNB to the remote UE may also include the global cell ID of the serving cell.

[0406] B. The remote UE reports the measurement results about the relay UE and / or the remote UE’s serving cell to the gNB in ​​the same RRC message.

[0407] C. Upon receiving the serving cell of the relay UE from the relay UE, the remote UE may measure the serving cell of the relay UE and then report the measurement result about the serving cell of the relay UE to the gNB of the remote UE via the same RRC message.

[0408] D. The remote UE may report measurement results on neighboring cells that are above a threshold in descending order of the measurement results to the remote UE's gNB via the same RRC message.

[0409] 7. The remote UE can measure the following targets.

[0410] A. Relay UE (e.g., SL-RSRP or SD-RSRP)

[0411] B. Neighboring relay UE (e.g., SL-RSRP or SD-RSRP)

[0412] C. Relay UE's serving cell (e.g., RSRP or RSRQ)

[0413] D. Serving cell of remote UE (e.g. RSRP or RSRQ)

[0414] E. Neighboring cells of remote UE (e.g., RSRP or RSRQ)

[0415] 8. The remote UE reports measurement results on one or more of the following targets to the gNB, for example periodically or based on events configured by the gNB:

[0416] A. Best ranking (neighboring) relay UE based on measurements

[0417] B. Non-optimal (neighboring) relay UEs above the threshold in descending order of measurement results

[0418] C. Relay UE (e.g., SL-RSRP or SD-RSRP)

[0419] D. Relay UE's serving cell (e.g., RSRP or RSRQ)

[0420] E. Serving cell of remote UE (e.g. RSRP or RSRQ)

[0421] F. Neighboring cells of remote UEs above a threshold in descending order of measurement results (e.g., RSRP or RSRQ)

[0422] 9. The source gNB determines the target relay UE based on the indication of the serving cell of the relay UE and the measurement report (S163).

[0423] -The source gNB may determine the target path type (i.e., direct or indirect) for the remote UE based on the measurement report. For example, the source gNB receives measurements from the relay UE regarding the remote UE and / or the relay UE's serving cell. Additionally, the source gNB receives measurements from the remote UE regarding neighboring cells.

[0424] 10. The source gNB notifies the target gNB of information about the target relay UE in an XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message (e.g., source L2 ID of the L2U2N relay UE, serving cell ID) (S164).

[0425] A. In case of direct-to-direct HO / indirect-to-direct HO, the source gNB provides information about relaying UE measurement results in the XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message.

[0426] B. The information in the message includes the best ranked relay UE in the measurement results and the non-best relay UEs in descending order of the measurement results. Alternatively, the message may include information about at least one relay UE and information about the remote UE.

[0427] C. This information includes the measurement result about the relay UE with SD-RSRP or SL-RSRP. If the relay UE has established a PC5 unicast link with the remote UE, the measurement result about the relay UE is SL-RSRP. Otherwise, the measurement result about any relay UE is SD-RSRP.

[0428] D. The source gNB of the remote UE may transmit an indication to the serving cell of the relay UE and the measurement report received from the relay UE.

[0429] E. If the target gNB can successfully establish resources for all requested PDU Sessions, the target gNB sends a HANDOVER REQUEST ACKNOWLEDGE message to the source gNB.

[0430] F. In case of direct to indirect handover / indirect to indirect handover, additional information may be required from the source gNB to the target gNB. For direct to indirect / indirect to indirect handover, the source gNB selects a relay UE among the candidate relay UEs. The target gNB will be the gNB to which the selected relay UE belongs. The source gNB may send an XnAP HANDOVERREQUEST or NGAP HANDOVER REQUIRED message with the SRCL2 ID, the serving cell ID of the selected relay UE and the context of the connected remote UE to the selected target gNB. Because the target UE must know which relay UE will connect with the remote UE for handover.

[0431] 11. The target gNB determines the target path type (i.e., direct or indirect) for the remote UE based on the relay UE measurement results upon HO request from the source gNB, i.e., upon receipt of the XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message.

[0432] A. The serving gNB can decide the target gNB based on the Uu measurement results of the candidate target cells and the SL measurement results of the candidate relay UEs. If the selected target gNB is an available Uu direct link or an indirect link via a relay UE, it is unclear whether the target gNB can decide the final target path type. We believe that the source gNB or the target gNB can decide the target path type. If the target gNB decides the target path type, there may be some benefits. The target gNB can decide the target path type more appropriately. Since the target gNB can know the Uu measurement results between the selected relay UE (if the selected relay UE is RRC_CONNECTED) and the target gNB. If the target gNB can decide the target path type for the remote UE, the source gNB must notify the measurement results of the Uu link signal strength (between the remote UE and the target gNB) and the side link signal strength (between the remote UE and the selected relay UE).

[0433] B. The source gNB may indicate the target path type (i.e., direct or indirect) for the remote UE to the target gNB via an XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message. If the source gNB indicates a target path type or if the source gNB indicates no target path type, the target gNB may determine whether to follow the indicated target path type. If the target gNB may determine a target path type different from the target path type indicated by the source gNB, the target gNB may inform the source gNB of the target path type (i.e., direct or indirect) for the remote UE in the next step.

[0434] 12. The target gNB notifies the source gNB of the determined target path type (i.e., direct or indirect) for the remote UE via an XnAP HANDOVER REQUEST ACKNOWLEDGE message or an NGAP HANDOVER COMMAND message. The determined target path type may be the same as or different from the target path type indicated by the source gNB (S165).

[0435] A. The XnAP HANDOVER REQUEST ACKNOWLEDGE message or the NGAP HANDOVER COMMAND message includes the HO command to be sent to the remote UE.

[0436] B. The HO command includes the determined target path type and the radio / bearer configuration for the determined target path type (ie, direct or indirect).

[0437] 13. Upon receiving the XnAP HANDOVER REQUEST ACKNOWLEDGE message or the NGAP HANDOVER COMMAND message, the source gNB sends the HO command included in the message to the remote UE (S166).

[0438] 14. Upon receiving the HO command for the indirect path via the target relay UE, if the remote UE already has a PC5-RRC connection with the target relay UE, the remote UE sends a HO completion message to the target gNB via the target relay UE (S167).

[0439] - Upon receiving a HO command for an indirect path via the target relay UE, if the remote UE already has no PC5-RRC connection with the target relay UE, the remote UE establishes a PC5 unicast link and a PC5-RRC connection with the target relay UE, and then sends a HO completion message to the target gNB via the target relay UE.

[0440] - Upon receiving the HO command to the direct path, the remote UE performs RACH at the target gNB and sends a HO Complete message to the target gNB via MSG3 or MSGA.

[0441] Using the disclosed invention, especially when the UE can support the U2N relay function via the SL, the UE can appropriately perform direct-to-indirect HO or indirect-to-indirect HO according to the present invention.

[0442] The invention is beneficial in that the system can properly provide HO to an indirect path via U2N relay.In the prior art, there is no mechanism to provide HO to an indirect path using sidelink relay.

[0443] Reference Fig.17 , the gNB can determine HO, which is a handover from indirect (path) to indirect (path).

[0444] Specifically, the remote UE has established PC5-RRC with the source relay UE (S171). The remote UE may perform a PC5-RRC establishment procedure with the target relay UE through a discovery procedure (S172).

[0445] HO from an indirect path to an indirect path (or U2N HO) may be determined as follows.

[0446] The gNB (or source gNB) determines HO from an indirect path to an indirect path (S173).

[0447] - If the remote UE can connect to the T-relay UE and the gNB of the T-relay UE and the gNB of the remote UE are the same, the gNB determines the HO from the indirect path to the indirect path.

[0448] -When the gNB determines the HO, the gNB may request a handover to the target relay UE (S174). In addition, the handover request may be in the same Fig.16 The method described in is executed according to the method described in.

[0449] - The gNB may receive a handover request confirmation message from the target relay UE. Here, the handover request confirmation message may also include information about rejecting some U2N bearers (S175). Fig.16 The message for handover request confirmation is executed in a method corresponding to the method described in.

[0450] -The gNB may send an RRC reconfiguration message to the remote UE (via a direct path or a tortuous path through the source relay UE) based on the handover request confirmation message received from the target relay UE (S176). Subsequently, as described above, the remote UE may configure an indirect path with the target UE relay based on the RRC reconfiguration message, and may perform an indirect path release procedure with the source relay UE (S177).

[0451] Hereinafter, a method for determining HO by a gNB, a relay UE, or a remote UE will be described in detail.

[0452] The method for performing data transmission by a UE comprises the following steps:

[0453] For direct to indirect HO / indirect to indirect HO,

[0454] 1. The relay UE informs the remote UE of the serving cell quality of the relay UE with the serving cell ID of the relay UE based on the relay UE's measurement on the relay UE's serving cell.

[0455] - When a specific event (eg, A1 event) is met, the relay UE triggers a report of the relay UE's serving cell quality towards the remote UE.

[0456] 2. The remote UE notifies the source gNB (i.e., the serving gNB of the remote UE) of the serving cell quality that the relay UE has received from the relay UE and the serving cell quality of the remote UE based on the remote UE's measurement of the remote UE's serving cell.

[0457] 3. The source gNB determines the target relay UE based on the information received from the remote UE.

[0458] 4. The source gNB informs the target gNB of information about the target relay UE in the XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message (e.g., source L2 ID of the L2U2N relay UE, serving cell ID)

[0459] - In case of direct-to-direct HO / indirect-to-direct HO, the source gNB provides information about relaying UE measurement results in the XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message.

[0460] - The information in the message includes the best ranked relay UE in the measurement results and the non-best relay UEs in descending order of the measurement results.

[0461] - This information includes measurement results about relay UEs with SD-RSRP or SL-RSRP. If the relay UE has established a PC5 unicast link with the remote UE, the measurement result about the relay UE is SL-RSRP. Otherwise, the measurement result about any relay UE is SD-RSRP.

[0462] 5. Upon HO request from the source gNB, i.e., upon receipt of XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED, the target gNB determines the target path type (i.e., direct or indirect) for the remote UE based on the relay UE measurement results.

[0463] - The source gNB may indicate the target path type (i.e., direct or indirect) for the remote UE to the target gNB via the XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message. If the source gNB indicates a target path type or if the source gNB indicates no target path type, the target gNB may determine whether to follow the indicated target path type. If the target gNB may determine a target path type different from the target path type indicated by the source gNB, the target gNB may inform the source gNB of the target path type (i.e., direct or indirect) for the remote UE in the next step.

[0464] 6. The target gNB informs the source gNB of the target path type (i.e., direct or indirect) for the remote UE via an XnAP HANDOVER REQUEST ACKNOWLEDGE message or an NGAP HANDOVER COMMAND message.

[0465] Specifically, HO (handover) from a direct path to an indirect path may be determined as follows.

[0466] (1) Alt1: S-gNB (source gNB) determines HO from direct path to indirect path

[0467] -If the remote UE can connect to the relay UE, but the gNBs of the relay UE and the remote UE are different, the S-gNB determines the HO from the direct path to the indirect path.

[0468] (2) Alt2: T-gNB (target gNB) determines HO from direct path to indirect path

[0469] -If the remote UE can connect to the relay UE, but the gNBs of the relay UE and the remote UE are different, the T-gNB determines the HO from the direct path to the indirect path.

[0470] (3) Alt3: The relay UE determines the HO from the direct path to the indirect path.

[0471] - The relay UE may request a HO from the T-gNB. In this case, the T-gNB may send a HO command without a separate request from the S-gNB.

[0472] -When the T-gNB sends a HO command to the S-gNB, the S-gNB sends a HO command to the remote UE via the relay UE.

[0473] (4) Alt4: The remote UE determines the HO from the direct path to the indirect path

[0474] -The remote UE may request HO from the direct path to the indirect path to the S-gNB. The request message may be sent using sidelink UE information, etc.

[0475] Alternatively, the HO from an indirect path to an indirect path (or U2N HO) may be determined as follows.

[0476] (1) Alt1: The gNB (or source gNB) determines the HO from an indirect path to an indirect path.

[0477] - If the remote UE can connect to the T-relay UE and the gNB of the T-relay UE and the gNB of the remote UE are the same, the gNB determines the HO from the indirect path to the indirect path.

[0478] -When the gNB determines HO, the gNB may request a handover to the target relay UE. Fig.16 and Fig.17 The switching request is performed in a method corresponding to the method described in.

[0479] - The gNB may receive a handover request confirmation message from the target relay UE. Here, the handover request confirmation message may also include information about rejecting some U2N bearers. In addition, the message for the handover request confirmation may be in the same format as Fig.16 and Fig.17 The method described in .

[0480] (2) Alt2: The source relay UE determines the HO from the indirect path to the indirect path.

[0481] -When the remote UE is connected to the target relay UE, the remote UE sends a U2N HO (or HO from an indirect path to an indirect path) request to the source relay UE. In this case, the remote UE may notify the source relay UE of information about the target relay UE. Thereafter, the source relay UE requests the gNB for HO from an indirect path to an indirect path. Here, the HO request may be sent using a sidelink UE information message.

[0482] (3) Alt3: The target relay UE determines HO from an indirect path to an indirect path.

[0483] -When the remote UE is connected to the target relay UE, the remote UE may request U2N HO from the target relay UE. At this time, the remote UE does not need to notify the target relay UE of information about the source relay UE (because the base station has learned the information about the source relay UE). Thereafter, the target relay UE may request (U2N) HO from the gNB. The HO request may be sent using a sidelink UE information message or the like.

[0484] (4) Alt4: The remote UE determines HO from an indirect path to an indirect path.

[0485] -When the remote UE is connected to the target relay UE, the remote UE can request U2N HO from the gNB (or base station). The request message can be sent to the gNB (or base station) through the sidelink UE information, etc. At this time, the remote UE needs to provide the gNB (or base station) with information about the target relay UE.

[0486] The HO command related to the above HO may be delivered to the remote UE through the following method.

[0487] -HO command includes U2N bearer setup

[0488] -How to send HO command to remote UE:

[0489] -Alt1: The S-gNB transmits directly to the remote UE (e.g., via a direct path).

[0490] -Alt2: S-gNB sends to remote UE via relay UE (when PC5-RRC connection exists)

[0491] - How the remote UE sends the HO Complete message to the target gNB:

[0492] --Alt1: After the relay UE performs U2N related settings through the RRC reconfiguration sidelink, the relay UE (or remote UE) can send a message to the T-gNB regarding the completion of the RRC reconfiguration.

[0493] --Alt2: Regardless of the RRC reconfiguration sidelink, the relay UE (or remote UE) may send a message to the gNB for RRC reconfiguration complete.

[0494] Fig.18 A diagram for explaining a method in which a first network performs handover for a first UE.

[0495] The first UE may support a multipath including a direct radio path directly connected to the network and an indirect radio path indirectly connected to the network through a relay UE. In this case, the first network may establish an indirect radio path with the first UE and / or a direct radio path with the second UE. In addition, hereinafter, the first network may be a source gNB, the second network may be a target gNB, and the first UE may be a remote UE.

[0496] Reference Fig.18 , the first network may receive measurement information related to the indirect radio path and / or the direct radio path from the first UE (S181).

[0497] Here, as described above, the measurement information may include at least one of the following qualities.

[0498] A. Relay UE (e.g., SL-RSRP or SD-RSRP)

[0499] B. Neighboring relay UE (e.g., SL-RSRP or SD-RSRP)

[0500] C. Relay UE's serving cell (e.g., RSRP or RSRQ)

[0501] D. Serving cell of remote UE (e.g. RSRP or RSRQ)

[0502] E. Neighboring cells of remote UE (e.g., RSRP or RSRQ)

[0503] Alternatively, as described above, the measurement information may include at least one of the following qualities.

[0504] A. Best ranking (neighboring) relay UE based on measurements

[0505] B. Non-optimal (neighboring) relay UEs above the threshold in descending order of measurement results

[0506] C. Relay UE (e.g., SL-RSRP or SD-RSRP)

[0507] D. Relay UE's serving cell (e.g., RSRP or RSRQ)

[0508] E. Serving cell of remote UE (e.g. RSRP or RSRQ)

[0509] F. Neighboring cells of remote UEs above a threshold in descending order of measurement results (e.g., RSRP or RSRQ)

[0510] Next, the first network may determine a HO (handover) to the second network for one of the indirect radio path and the direct radio path of the first UE based on the measurement information (S183). For example, the first network may determine a HO (direct to indirect HO) for converting the direct radio path between the first UE and the first network to the indirect radio path between the first UE and the second network based on the measurement information. Alternatively, the first network may determine a HO (indirect to indirect HO) for converting the indirect radio path between the first UE and the first network to the indirect radio path between the first UE and the second network based on the measurement information. That is, the first network may determine a HO (refer to the indirect HO) for converting the direct radio path or the indirect radio path established with the first UE to the indirect radio path between the first UE and the second network based on the measurement information. Fig.16 10).

[0511] Next, the first network may send a handover request message requesting HO for the first UE to the second network based on the HO decision (S185). Here, the handover request message may also include information about at least one relay UE that will form an indirect radio path between the second network and the first UE. Alternatively, the handover request message may also include identification information about a serving cell associated with the at least one relay UE. Here, the handover request message may be an Xn Application Protocol (XnAP) handover REQUEST message.

[0512] For example, when converting an indirect radio path (or a direct radio path) with a first UE to an indirect radio path between a second network and the first UE, the first network may send a handover request message including information about at least one relay. Alternatively, the handover request message may include information about at least one relay and the first UE. Here, the information about at least one relay may be at least one identifier (ID) for at least one relay UE or / and the first UE. When the first network determines a HO from a direct path to a direct path, the first network may send a handover request message that does not include at least one relay information to the second network.

[0513] In response to the handover request message from the second network, the first network may receive a message including a handover COMMAND (handover COMMAND message). Here, the handover COMMAND message may include information about a relay UE selected by the second network from among at least one relay UE. The first network may send the HO COMMAND message to the first UE.

[0514] As described above, the source gNB may provide the target gNB with information related to the handover type and the target relay UE related to the indirect path in advance through the handover request message. The handover type may include a type of converting a direct radio path / indirect radio path to an indirect radio path, and a type of converting a direct radio path / indirect radio path to a direct radio path. Through the above-proposed scheme, it becomes clear that in the inter-gNB handover for multipath, the handover scheme for multipath and the information about the target relay UE for the indirect path are determined by the source gNB.

[0515] That is, when the UE can support the U2N relay function via SL (side link), the first UE can appropriately perform direct to indirect HO or indirect to indirect HO. The benefit of the present invention is that the system can appropriately provide HO via U2N relay to an indirect path. In the prior art, there is no mechanism to provide HO using a side link relay to an indirect path.

[0516] The various descriptions, functions, processes, proposals, methods and / or operational flowcharts of the present disclosure described herein may be applied without limitation to various fields requiring wireless communication / connection (5G) between devices.

[0517] Hereinafter, a description will be given in more detail with reference to the accompanying drawings. In the following drawings / descriptions, unless otherwise described, the same reference numerals may represent the same or corresponding hardware blocks, software blocks or functional blocks.

[0518] Fig.19 A communication system applied to the present disclosure is illustrated.

[0519] Reference Fig.19, the communication system 1 applied to the present disclosure includes a wireless device, a BS, and a network. Herein, a wireless device refers to a device that performs communication using a RAT (e.g., 5G NR or LTE), and may be referred to as a communication / radio / 5G device. The wireless device may include, but is not limited to, a robot 100a, a vehicle 100b-1 and 100b-2, an extended reality (XR) device 100c, a handheld device 100d, a home appliance 100e, an Internet of Things (IoT) device 100f, and an artificial intelligence (AI) device / server 400. For example, a vehicle may include a vehicle with a wireless communication function, an autonomous driving vehicle, and a vehicle capable of performing inter-vehicle communication. Herein, a vehicle may include an unmanned aerial vehicle (UAV) (e.g., a drone). The XR device may include an augmented reality (AR) / virtual reality (VR) / mixed reality (MR) device and may be implemented in the form of a head-mounted device (HMD), a head-up display (HUD) installed in a vehicle, a television, a smart phone, a computer, a wearable device, a home appliance device, a digital signage, a vehicle, a robot, and the like. Handheld devices may include smart phones, smart boards, wearable devices (e.g., smart watches or smart glasses), and computers (e.g., notebooks). Home appliances may include TVs, refrigerators, and washing machines. IoT devices may include sensors and smart meters. For example, a BS and a network may be implemented as wireless devices, and a specific wireless device 200a may operate as a BS / network node relative to other wireless devices.

[0520] The wireless devices 100a to 100f may be connected to the network 300 via the BS 200. AI technology may be applied to the wireless devices 100a to 100f, and the wireless devices 100a to 100f may be connected to the AI ​​server 400 via the network 300. The network 300 may be configured using a 3G network, a 4G (e.g., LTE) network, or a 5G (e.g., NR) network. Although the wireless devices 100a to 100f may communicate with each other via the BS 200 / network 300, the wireless devices 100a to 100f may perform direct communication (e.g., side link communication) with each other without passing through the BS / network. For example, the vehicles 100b-1 and 100b-2 may perform direct communication (e.g., V2V / V2X communication). An IoT device (e.g., a sensor) may perform direct communication with other IoT devices (e.g., a sensor) or other wireless devices 100a to 100f.

[0521] Wireless communication / connection 150a, 150b or 150c can be established between wireless devices 100a to 100f / BS200 or BS200 / BS200. Herein, wireless communication / connection can be established through various RATs (e.g., 5G NR) such as UL / DL communication 150a, side link communication 150b (or D2D communication) or inter-BS communication (e.g., relay, integrated access backhaul (IAB)). The wireless device and the BS / wireless device can send / receive radio signals to each other through wireless communication / connection 150a and 150b. For example, wireless communication / connection 150a and 150b can send / receive signals through various physical channels. To this end, various configuration information configuration processes for sending / receiving radio signals, various signal processing processes (e.g., channel coding / decoding, modulation / demodulation, and resource mapping / demapping) and at least a part of the resource allocation process can be performed based on various proposals of the present disclosure.

[0522] Fig. 20 A wireless device suitable for use with the present disclosure is illustrated.

[0523] Reference Fig. 20 , the first wireless device 100 and the second wireless device 200 may transmit radio signals through various RATs (e.g., LTE and NR). Herein, {the first wireless device 100 and the second wireless device 200} may correspond to Fig.19 {wireless device 100x and BS200} and / or {wireless device 100x and wireless device 100x} in.

[0524] The first wireless device 100 may include one or more processors 102 and one or more memories 104, and further include one or more transceivers 106 and / or one or more antennas 108. The processor 102 may control the memory 104 and / or the transceiver 106, and may be configured to implement the description, functions, processes, proposals, methods, and / or operation flowcharts disclosed herein. For example, the processor 102 may process the information in the memory 104 to generate first information / signals, and then transmit a radio signal including the first information / signals through the transceiver 106. The processor 102 may receive a radio signal including second information / signals through the transceiver 106, and then store information obtained by processing the second information / signals in the memory 104. The memory 104 may be connected to the processor 102, and may store various information related to the operation of the processor 102. For example, the memory 104 may store software codes including commands for executing part or all of the processing controlled by the processor 102 or for executing the description, functions, processes, proposals, methods, and / or operation flowcharts disclosed herein. Herein, the processor 102 and the memory 104 may be part of a communication modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). The transceiver 106 may be connected to the processor 102 and transmit and / or receive radio signals through one or more antennas 108. Each of the transceivers 106 may include a transmitter and / or a receiver. The transceiver 106 may be used interchangeably with (one or more) radio frequency (RF) units. In the present disclosure, a wireless device may represent a communication modem / circuit / chip.

[0525] Specifically, the UE may include a processor 102 connected to an RF transceiver and a memory 104. The memory 104 may include a processor for executing the above-referenced Figures 16 to 18 At least one program for operations related to the described embodiments. For example, the memory 104 may include at least one program for the following operations: configuring a first radio path directly connected to the network and a second radio path indirectly connected to the network via a relay UE; receiving an RRC (Radio Resource Control) reconfiguration message related to the second radio path through the first radio path or the second radio path, and sending a first status report for at least one data unit related to the second radio path to the network based on the RRC reconfiguration message, the RRC reconfiguration message including information for releasing the second radio path or modifying at least one radio bearer related to the second radio path.

[0526] Alternatively, a chipset including the processor 102 and the memory 104 may be configured. The chipset may include: at least one processor; and at least one memory operatively connected to the at least one processor and configured to cause the at least one processor to perform operations when executed.

[0527] The second wireless device 200 may include one or more processors 202 and one or more memories 204, and further include one or more transceivers 206 and / or one or more antennas 208. The processor 202 may control the memory 204 and / or the transceiver 206, and may be configured to implement the description, functions, processes, proposals, methods, and / or operation flowcharts disclosed herein. For example, the processor 202 may process the information in the memory 204 to generate third information / signals, and then transmit a radio signal including the third information / signals through the transceiver 206. The processor 202 may receive a radio signal including fourth information / signals through the transceiver 106, and then store information obtained by processing the fourth information / signals in the memory 204. The memory 204 may be connected to the processor 202, and may store various information related to the operation of the processor 202. For example, the memory 204 may store software codes including commands for executing part or all of the processing controlled by the processor 202 or for executing the description, functions, processes, proposals, methods, and / or operation flowcharts disclosed herein. Herein, the processor 202 and the memory 204 may be part of a communication modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). The transceiver 206 may be connected to the processor 202 and transmit and / or receive radio signals through one or more antennas 208. Each of the transceivers 206 may include a transmitter and / or a receiver. The transceiver 206 may be used interchangeably with an RF unit. In the present disclosure, a wireless device may represent a communication modem / circuit / chip.

[0528] Hereinafter, the hardware elements of the wireless devices 100 and 200 will be described in more detail. One or more protocol layers may be implemented by one or more processors 102 and 202 without limitation. For example, one or more processors 102 and 202 may implement one or more layers (e.g., functional layers such as PHY, MAC, RLC, PDCP, RRC, and SDAP). One or more processors 102 and 202 may generate one or more protocol data units (PDUs) and / or one or more service data units (SDUs) according to the descriptions, functions, processes, proposals, methods, and / or operational flow diagrams disclosed herein. One or more processors 102 and 202 may generate messages, control information, data, or information according to the descriptions, functions, processes, proposals, methods, and / or operational flows disclosed herein. One or more processors 102 and 202 may generate a signal (e.g., a baseband signal) including a PDU, SDU, message, control information, data, or information according to the description, functions, procedures, proposals, methods, and / or operational flow diagrams disclosed herein, and provide the generated signal to one or more transceivers 106 and 206. One or more processors 102 and 202 may receive a signal (e.g., a baseband signal) from one or more transceivers 106 and 206 and obtain the PDU, SDU, message, control information, data, or information according to the description, functions, procedures, proposals, methods, and / or operational flow diagrams disclosed herein.

[0529] One or more processors 102 and 202 may be referred to as controllers, microcontrollers, microprocessors, or microcomputers. One or more processors 102 and 202 may be implemented by hardware, firmware, software, or a combination thereof. As an example, one or more application specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more digital signal processing devices (DSPDs), one or more programmable logic devices (PLDs), or one or more field programmable gate arrays (FPGAs) may be included in one or more processors 102 and 202. Firmware or software may be used to implement the description, function, process, proposal, method, and / or operational flow chart disclosed herein, and the firmware or software may be configured to include modules, processes, or functions. Firmware or software configured to perform the description, function, process, proposal, method, and / or operational flow chart disclosed herein may be included in one or more processors 102 and 202 or stored in one or more memories 104 and 204 so as to be driven by one or more processors 102 and 202. The descriptions, functions, processes, proposals, methods and / or operational flows disclosed herein may be implemented using firmware or software in the form of codes, commands and / or command sets.

[0530] One or more memories 104 and 204 may be connected to one or more processors 102 and 202 and store various types of data, signals, messages, information, programs, codes, instructions and / or commands. One or more memories 104 and 204 may be composed of read-only memory (ROM), random access memory (RAM), electrically erasable programmable read-only memory (EPROM), flash memory, hard drive, register, cache memory, computer-readable storage medium and / or a combination thereof. One or more memories 104 and 204 may be located inside and / or outside of one or more processors 102 and 202. One or more memories 104 and 204 may be connected to one or more processors 102 and 202 by respective technologies such as wired or wireless connections.

[0531] One or more transceivers 106 and 206 can send the user data, control information and / or radio signal / channel mentioned in the method and / or operation flow chart of this article to one or more other devices. One or more transceivers 106 and 206 can receive the user data, control information and / or radio signal / channel mentioned in the description, function, process, proposal, method and / or operation flow chart disclosed in this article from one or more other devices. For example, one or more transceivers 106 and 206 can be connected to one or more processors 102 and 202, and send and receive radio signals. For example, one or more processors 102 and 202 can perform control so that one or more transceivers 106 and 206 can send user data, control information or radio signal to one or more other devices. One or more processors 102 and 202 can perform control so that one or more transceivers 106 and 206 can receive user data, control information or radio signal from one or more other devices. One or more transceivers 106 and 206 may be connected to one or more antennas 108 and 208, and one or more transceivers 106 and 206 may be configured to send and receive user data, control information, and / or radio signals / channels mentioned in the description, functions, processes, proposals, methods, and / or operation flow charts disclosed herein through one or more antennas 108 and 208. In this document, one or more antennas may be multiple physical antennas or multiple logical antennas (e.g., antenna ports). One or more transceivers 106 and 206 may convert received radio signals / channels, etc. from RF band signals into baseband signals so as to process received user data, control information, radio signals / channels, etc. using one or more processors 102 and 202. One or more transceivers 106 and 206 may convert user data, control information, radio signals / channels, etc. processed using one or more processors 102 and 202 from baseband signals into RF band signals. To this end, one or more of the transceivers 106 and 206 may include (analog) oscillators and / or filters.

[0532] Fig.21 Another example of a wireless device applied to the present disclosure is illustrated. The wireless device can be implemented in various forms according to use cases / services (refer to Fig.19 ).

[0533] Reference Fig.21 , the wireless devices 100 and 200 may correspond to Fig. 20The wireless devices 100 and 200 of the present invention may be composed of various elements, components, units / portions and / or modules. For example, each of the wireless devices 100 and 200 may include a communication unit 110, a control unit 120, a storage unit 130 and an additional component 140. The communication unit may include a communication circuit 112 and (one or more) transceivers 114. For example, the communication circuit 112 may include Fig. 20 The one or more processors 102 and 202 and / or the one or more memories 104 and 204 of the present invention. For example, the transceiver 114 may include Fig. 20 The control unit 120 is electrically connected to the communication unit 110, the memory 130, and the additional components 140, and controls the overall operation of the wireless device. For example, the control unit 120 can control the electrical / mechanical operation of the wireless device based on the program / code / command / information stored in the storage unit 130. The control unit 120 can send the information stored in the storage unit 130 to the outside (e.g., other communication devices) via the communication unit 110 through a wireless / wired interface, or store the information received from the outside (e.g., other communication devices) via the communication unit 110 through a wireless / wired interface in the storage unit 130.

[0534] The additional component 140 may be configured in various ways depending on the type of the wireless device. For example, the additional component 140 may include at least one of a power unit / battery, an input / output (I / O) unit, a drive unit, and a computing unit. The wireless device may be implemented in the following forms without limitation: a robot ( Fig.19 100a), vehicles ( Fig.19 100b-1 and 100b-2), XR devices ( Fig.19 100c), handheld device ( Fig.19 100d), household appliances ( Fig.19 100e), IoT devices ( Fig.19 100f), digital broadcast terminal, hologram device, public safety device, MTC device, medical device, FinTech device (or financial device), security device, climate / environmental device, AI server / device ( Fig.19 400), BS( Fig.19 200), network nodes, etc. Depending on the use case / service, the wireless device can be used in a mobile or fixed place.

[0535] exist Fig.21In the wireless devices 100 and 200, various elements, components, units / parts and / or modules in the wireless devices 100 and 200 may all be connected to each other through a wired interface, or at least a part thereof may be wirelessly connected through the communication unit 110. For example, in each of the wireless devices 100 and 200, the control unit 120 and the communication unit 110 may be connected by wire, and the control unit 120 and the first unit (e.g., 130 and 140) may be wirelessly connected through the communication unit 110. Each element, component, unit / part and / or module in the wireless devices 100 and 200 may also include one or more elements. For example, the control unit 120 may be composed of a set of one or more processors. As an example, the control unit 120 may be composed of a set of a communication control processor, an application processor, an electronic control unit (ECU), a graphics processing unit and a memory control processor. As another example, the memory 130 may be composed of a RAM, a DRAM, a ROM, a flash memory, a volatile memory, a non-volatile memory and / or a combination thereof.

[0536] Fig. 22 The vehicle or autonomous driving vehicle applied to the present disclosure is illustrated. The vehicle or autonomous driving vehicle can be realized by a mobile robot, a car, a train, a manned / unmanned aerial vehicle (AV), a ship, etc.

[0537] Reference Fig. 22 , the vehicle or autonomous driving vehicle 100 may include an antenna unit 108, a communication unit 110, a control unit 120, a drive unit 140a, a power supply unit 140b, a sensor unit 140c, and an autonomous driving unit 140d. The antenna unit 108 may be configured as a part of the communication unit 110. Blocks 110 / 130 / 140a to 140d correspond to Fig.21 Block 110 / 130 / 140.

[0538] The communication unit 110 may send signals (e.g., data and control signals) to and receive signals from external devices such as other vehicles, BSs (e.g., gNBs and roadside units), and servers. The control unit 120 may perform various operations by controlling elements of the vehicle or autonomous driving vehicle 100. The control unit 120 may include an ECU. The drive unit 140a may enable the vehicle or autonomous driving vehicle 100 to travel on a road. The drive unit 140a may include an engine, a motor, a powertrain, wheels, brakes, a steering device, and the like. The power supply unit 140b may supply power to the vehicle or autonomous driving vehicle 100 and include a wired / wireless charging circuit, a battery, and the like. The sensor unit 140c may acquire vehicle status, surrounding environment information, user information, and the like. The sensor unit 140c may include an inertial measurement unit (IMU) sensor, a collision sensor, a wheel sensor, a speed sensor, a slope sensor, a weight sensor, a heading sensor, a position module, a vehicle forward / reverse sensor, a battery sensor, a fuel sensor, a tire sensor, a steering sensor, a temperature sensor, a humidity sensor, an ultrasonic sensor, an illumination sensor, a pedal position sensor, etc. The autonomous driving unit 140d may implement a technology for maintaining a lane on which the vehicle is driving, a technology for automatically adjusting a speed such as an adaptive cruise control, a technology for autonomous driving along a determined path, a technology for driving by automatically setting a path when a destination is set, and the like.

[0539] For example, the communication unit 110 may receive map data, traffic information data, etc. from an external server. The autonomous driving unit 140d may generate an autonomous driving path and a driving plan from the obtained data. The control unit 120 may control the drive unit 140a so that the vehicle or the autonomous driving vehicle 100 may move along the autonomous driving path according to the driving plan (e.g., speed / direction control). In autonomous driving, the communication unit 110 may obtain the latest traffic information data from the external server irregularly / regularly, and may obtain surrounding traffic information data from neighboring vehicles. In autonomous driving, the sensor unit 140c may obtain vehicle status and / or surrounding environment information. The autonomous driving unit 140d may update the autonomous driving path and driving plan based on the newly obtained data / information. The communication unit 110 may transmit information about the vehicle position, autonomous driving path, and / or driving plan to an external server. The external server may predict traffic information data based on information collected from the vehicle or autonomous driving vehicle, using AI technology, etc., and provide the predicted traffic information data to the vehicle or autonomous driving vehicle.

[0540] Here, the wireless communication technology implemented in the wireless device (XXX, YYY) of this specification may include LTE, NR and 6G, as well as narrowband Internet of Things for low-power communication. At this time, for example, NB-IoT technology may be an example of low-power wide area network (LPWAN) technology, and may be implemented in standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the above names. Additionally or alternatively, the wireless communication technology implemented in the wireless device (XXX, YYY) of this specification may perform communication based on LTE-M technology. In this case, as an example, LTE-M technology may be an example of LPWAN technology, and may be referred to by various names such as eMTC (enhanced machine type communication). For example, LTE-M technology may be implemented in at least one of various standards, such as: 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-bandwidth limited), 5) LTE-MTC, 6) LTE machine type communication, and / or 7) LTE M, and is not limited to the above names. Additionally or alternatively, the wireless communication technology implemented in the wireless device (XXX, YYY) of the present specification is at least one of ZigBee, Bluetooth, and a low power wide area network (LPWAN) considering low power communication, and is not limited to the above names. As an example, ZigBee technology can generate a personal area network (PAN) related to small / low power digital communication based on various standards such as IEEE 802.15.4, and can be called various names.

[0541] The above-mentioned embodiments are embodiments in which the components and features of the present disclosure are combined in a predetermined form. Unless otherwise expressly stated, each component or feature should be considered optional. Each component or feature can be implemented in a form not combined with other components or features. In addition, the embodiments of the present disclosure can also be constituted by combining some parts and / or features. The order of operations described in the embodiments of the present disclosure can be changed. Some configurations or features of an embodiment can be included in other embodiments, or can be replaced by corresponding configurations or features of other embodiments. It is obvious that the embodiment can be configured by combining claims that do not have a clear reference relationship in the claims, or can be included as a new claim by modification after submission.

[0542] In this document, the embodiments of the present disclosure are described mainly based on the signal transmission / reception relationship between the terminal and the base station. This transmission / reception relationship is extended to the signal transmission / reception between the terminal and the repeater or the base station and the repeater in the same / similar manner. In some cases, the specific operations described in this document as being performed by the base station can be performed by its superior node. That is, it is obvious that various operations for communicating with a terminal in a network of multiple network nodes including a base station can be performed by a base station or a network node other than the base station. The base station can be replaced by terms such as a fixed station, a node B, an eNode B (eNB), an access point, etc. In addition, the terminal can be replaced by terms such as a user equipment (UE), a mobile station (MS), a mobile user station (MSS), etc.

[0543] In hardware configuration, the embodiments of the present disclosure may be implemented by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, etc.

[0544] In firmware or software configuration, the method according to the embodiment of the present disclosure can be implemented in the form of modules, processes, functions, etc. The software code can be stored in a memory unit and executed by a processor. The memory unit is located inside or outside the processor and can send data to and receive data from the processor via various known means.

[0545] As mentioned above, a detailed description of the preferred embodiments of the present disclosure has been given so that those skilled in the art can implement and perform the present disclosure. Although the above has been referred to the preferred embodiments of the present disclosure, it will be understood by those skilled in the art that various modifications and changes can be made to the present disclosure within the scope of the present disclosure. For example, those skilled in the art can use the components described in the aforementioned embodiments in combination. Therefore, the above embodiments are interpreted as illustrative and not restrictive in all aspects. The scope of the present disclosure should be determined by the attached claims and their legal equivalents, rather than by the above description, and all changes falling within the meaning and equivalent scope of the attached claims are intended to be included therein.

[0546] Industrial Applicability

[0547] The present disclosure is applicable to UE, BS or other devices in a wireless mobile communication system.

Claims

1. A method for performing communication by a first network in a wireless communication system, the method comprising the following steps: receiving measurement information from a first user equipment UE configured with at least one of a direct radio path directly connected to the first network and an indirect radio path indirectly connected to the first network through a relay UE; determining, for the first UE, a handover to a second network based on the measurement information; as well as A handover request message is sent to the second network, the handover request message including information about at least one relay UE related to an indirect radio path between the second network and the first UE.

2. The method according to claim 1, further comprising the steps of: A HANDOVER COMMAND message is received from the second network.

3. The method according to claim 1, wherein: The HANDOVER COMMAND message includes information on one relay UE selected from among the at least one relay UE.

4. The method according to claim 1, wherein: The first network decides whether the handover request message includes a target cell of the second network for handover to a direct path between the second network and the first UE, or at least one relay UE for handover to the indirect radio path via the relay UE between the second network and the first UE.

5. The method according to claim 1, wherein: The handover request message is an Xn application protocol XnAP HANDOVERREQUEST message.

6. The method according to claim 1, wherein: The handover request message further includes information indicating a serving cell associated with the at least one relay UE.

7. The method according to claim 1, wherein: The information about the at least one relay UE is at least one identifier ID for the at least one relay UE.

8. The method according to claim 1, wherein: The measurement information includes at least one of the quality of the relay UE, the quality of neighboring relay UEs, the quality of a serving cell of the relay UE, the quality of a neighboring cell of the first UE, and the quality of a serving cell of the first UE.

9. The method according to claim 8, wherein: The quality is reference signal received power RSRP or reference signal received quality RSRQ.

10. A computer readable medium storing instructions which, when executed by a processor, cause the processor to perform the method according to claim 1.

11. A first device for wireless communication, the first device comprising: a memory configured to store instructions; as well as a processor configured to perform operations by executing the instructions, The operations performed by the processor include: receiving measurement information from a first user equipment UE configured with at least one of a direct radio path directly connected to a first network and an indirect radio path indirectly connected to the first network through a relay UE; determining, for the first UE, a handover to a second network based on the measurement information; and A handover request message is sent to the second network, the handover request message including information about at least one relay UE related to an indirect radio path between the second network and the first UE.

12. The device according to claim 11, wherein The device is an application specific integrated circuit ASIC or a digital signal processor.

13. The device according to claim 11, wherein: The apparatus is a first network operating in a wireless communication system based on the 3rd Generation Partnership Project 3GPP.

14. A method for performing communication by a second network in a wireless communication system, the method comprising the following steps: receiving a handover request message for a first user equipment UE from a first network, wherein the handover request message includes information about at least one relay UE to configure an indirect radio path between the second network and the first UE; selecting a relay UE from among the at least one relay UE included in the handover request message; and A HANDOVER COMMAND including information about a selected relay UE is sent to the first network.

15. A second network for wireless communication, the second network comprising: Transceiver; as well as a processor configured to control the transceiver, The processor is configured to receive a handover request message for a first user equipment UE from a first network, wherein the handover request message includes information about at least one relay UE to configure an indirect radio path between the second network and the first UE, select a relay UE from the at least one relay UE included in the handover request message, and send a HANDOVERCOMMAND including information about a selected relay UE to the first network.

Images