Method and apparatus for transmitting and receiving radio signals in a wireless communication system

Abstract

According to an embodiment of the present invention, a network receives measurement information from a first terminal (UE, user equipment) comprising at least one of a direct wireless path directly connected to a first network and an indirect wireless path indirectly connected to the first network via a relay terminal, determines a handover to a second network for the first terminal based on the measurement information, and transmits a handover request message to the second network, the handover request message including information about at least one relay terminal associated with the indirect wireless path between the second network and the first terminal.

Description

[Technical Field]

[0001] The present invention relates to wireless communication systems, and more particularly to methods and apparatus for transmitting and receiving wireless signals. [Background technology]

[0002] Wireless communication systems are multiple access systems that support communication with multiple users by sharing available system resources (e.g., 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) is a communication method that establishes a direct link between terminals (User Equipment, UE) to directly exchange voice or data between terminals without going through a base station (BS). SL is one solution to alleviate the burden on base stations due to the rapidly increasing data traffic.

[0004] V2X (vehicle-to-everything) refers to a communication technology that exchanges information with other vehicles, pedestrians, and infrastructure-based objects via wired and wireless communications. V2X is divided into four types: V2V (vehicle-to-vehicle), V2I (vehicle-to-infrastructure), V2N (vehicle-to-network), and V2P (vehicle-to-pedestrian). V2X communication is provided via the PC5 interface and / or Uu interface.

[0005] Meanwhile, as more communication devices require greater communication capacity, there is an emerging need for improved mobile broadband communication compared to existing radio access technologies (RATs). This has led to discussions about communication system designs that take into account reliability- and latency-sensitive services or terminals. Next-generation radio access technologies that take into account such improved mobile broadband communication, massive MTC, and ultra-reliable and low latency communication (URLLC) are called new radio access technologies (RATs) or new radios (NRs). NRs can also support vehicle-to-everything (V2X) communication.

[0006] FIG. 1 is a diagram illustrating a comparison between V2X communication based on a RAT prior to NR and V2X communication based on NR.

[0007] In relation to V2X communication, RATs prior to NR have been discussing methods for providing safety services based on V2X messages such as Basic Safety Message (BSM), Cooperative Awareness Message (CAM), and Decentralized Environmental Notification Message (DENM). V2X messages include location information, dynamic information, attribute information, etc. For example, a terminal can send a periodic message type CAM and / or an event-triggered message type DENM to another terminal.

[0008] For example, the CAM includes basic vehicle information such as vehicle dynamic status information such as direction and speed, vehicle static data such as dimensions, exterior lighting status, and route details. For example, a terminal can broadcast the CAM, and the delay of the CAM is less than 100 ms. For example, if an emergency situation such as a vehicle breakdown or accident occurs, the terminal can generate a DENM and transmit it to other terminals. For example, all vehicles within the transmission range of the terminal can receive the CAM and / or the DENM. In this case, the DENM has a higher priority than the CAM.

[0009] Subsequently, various V2X scenarios related to V2X communication have been defined in NR, including vehicle platooning, advanced driving, extended sensors, remote driving, etc.

[0010] For example, based on platooning vehicles, vehicles dynamically form groups and travel together. For example, to perform platooning operations based on platooning vehicles, vehicles belonging to the group receive periodic data from a lead vehicle. For example, vehicles belonging to the group can use the periodic data to decrease or increase the spacing between vehicles.

[0011] For example, based on enhanced driving, vehicles may be semi-automated or fully automated. Each vehicle may adjust its trajectories or maneuvers based on data obtained from local sensors of nearby vehicles and / or nearby logical entities. For example, each vehicle may share driving intentions with nearby vehicles.

[0012] For example, based on the extended sensor, raw data, processed data, or live video data obtained by local sensors can be exchanged between vehicles, logic elements, pedestrian terminals, and / or V2X application servers. Thus, for example, a vehicle can recognize an environment that is more enhanced than the environment it can sense using its own sensors.

[0013] For example, based on remote driving, a remote driver or V2X application can operate or control a remote vehicle for a person who cannot drive or for a remote vehicle located in a dangerous environment. For example, when the route is predictable, such as in public transportation, cloud computing-based driving can be used to operate or control the remote vehicle. For example, a connection to a cloud-based back-end service platform can be considered for remote driving.

[0014] Meanwhile, methods to specify service requirements for various V2X scenarios, such as platooning vehicles, improved driving, extended sensors, and remote driving, are being discussed for NR-based V2X communications. Summary of the Invention [Problem to be solved by the invention]

[0015] SUMMARY OF THE INVENTION An object of the present invention is to provide a method and apparatus for accurately and efficiently performing a radio signal transmission and reception procedure.

[0016] The technical problems to be achieved by the present invention are not limited to the above-mentioned technical problems, and other technical problems not mentioned will be clearly understood by those skilled in the art to which the present invention pertains from the following description. [Means for solving the problem]

[0017] In one aspect of the present invention, the method includes receiving measurement information from a first terminal (UE, user equipment) comprising at least one of a direct wireless path directly connected to a first network and an indirect wireless path indirectly connected to the first network via a relay terminal, determining a handover to a second network for the first terminal based on the measurement information, and transmitting a handover request message to the second network including information regarding at least one relay terminal associated with the indirect wireless path between the second network and the first terminal.

[0018] Preferably, the method further comprises receiving a HANDOVER COMMAND message from the second network.

[0019] Preferably, the handover command message includes information about one relay terminal selected from the at least one relay terminal.

[0020] Preferably, the handover request message is for switching the direct wireless path or the indirect wireless path between the first terminal and the first network to the indirect wireless path between the second network and the first terminal.

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

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

[0023] Preferably, the information relating to said at least one relay terminal is at least one identifier (ID) for said at least one relay terminal.

[0024] Preferably, the measurement information includes at least one of the quality of the relay terminal, the quality of a neighboring relay terminal, the quality of a serving cell of the relay terminal, the quality of a neighboring cell of the first terminal, and the quality of a serving cell of the first terminal.

[0025] Preferably, the quality is Reference Signals Received Power (RSRP) or Reference Signal Received Quality (RSRQ).

[0026] In yet another aspect of the present invention, a computer-readable storage medium storing a program for executing the method is provided.

[0027] In yet another aspect of the invention, there is provided an apparatus configured to perform the method.

[0028] In yet another aspect of the invention, there is provided a second network configured to control the terminal configured to perform the method. [Effects of the Invention]

[0029] According to the embodiment of the present invention, the procedure for transmitting / receiving radio signals can be performed accurately and efficiently.

[0030] According to an embodiment of the present invention, the proposed method clarifies that in handover between gNBs for multiple paths, the handover method for multiple paths and information regarding the target relay terminal for the indirect path are determined by the source gNB.

[0031] Effects that can be obtained from various examples of the present disclosure, as well as other effects not mentioned above, will be clearly derived and understood by those skilled in the art to which the present invention pertains from the following description. [Brief explanation of the drawings]

[0032] [Figure 1] FIG. 1 is a diagram for explaining a comparison between V2X communication based on a RAT prior to NR and V2X communication based on NR. [Figure 2] 1 is a diagram illustrating the structure of an LTE system. [Figure 3] FIG. 1 is a diagram illustrating the structure of an NR system. [Figure 4] FIG. 1 is a diagram illustrating the structure of an NR radio frame. [Figure 5] A diagram showing the slot structure of an NR frame. [Figure 6] FIG. 1 illustrates a radio protocol architecture for SL communication. [Figure 7] FIG. 1 is a diagram illustrating a terminal that performs V2X or SL communication. [Figure 8] FIG. 1 illustrates a resource unit for V2X or SL communication. [Figure 9] FIG. 10 is a diagram showing inter-UE coordination information (MAC CE). [Figure 10] FIG. 10 is a diagram showing an Inter-UE Coordination Request MAC CE. [Figure 11]1A and 1B illustrate (a) a user plane protocol stack and (b) a control plane protocol stack for L2 UE-to-Network Relay. [Figure 12] A diagram showing the protocol stack of a discovery message for relaying between a terminal and a network. [Figure 13] FIG. 10 illustrates a procedure for establishing a connection between an L2 U2N remote terminal. [Figure 14] A diagram showing the procedure by which a U2N remote terminal switches directly to a Uu cell. [Figure 15] FIG. 10 is a diagram illustrating a procedure for a U2N remote terminal to switch to an indirect path. [Figure 16] 10 is a diagram illustrating a method of performing handover for direct-indirect path switching or indirect-indirect path switching for a remote terminal. [Figure 17] 10 is a diagram illustrating a method of performing handover for direct-indirect path switching or indirect-indirect path switching for a remote terminal. [Figure 18] FIG. 10 is a diagram illustrating a method for performing handover of a first terminal by a first network. [Figure 19] 1 is a diagram illustrating a communication system to which the present invention can be applied; [Figure 20] 1 is a diagram illustrating a wireless device to which the present invention can be applied; [Figure 21] FIG. 10 is a diagram illustrating still another example of a wireless device to which the present invention can be applied. [Figure 22] 1 is a diagram showing a vehicle or autonomous vehicle to which the present invention can be applied; DETAILED DESCRIPTION OF THE INVENTION

[0033] Wireless communication systems are multiple access systems that support communication with multiple users by sharing available system resources (e.g., 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.

[0034] For background, terms, definitions, abbreviations, etc. relevant to this invention, the following documents may be referenced:

[0035] 3GPP(registered trademark) LTE

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

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

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

[0039] - 3GPP TS 36.214: Physical layer; Measurements

[0040] - 3GPP TS 36.300: Overall description

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

[0042] - 3GPP TS 36.314: Layer 2 - Measurements

[0043] - 3GPP TS 36.321: Medium Access Control (MAC) protocol

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

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

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

[0047] 3GPP NR

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

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

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

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

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

[0053] - 3GPP TS 38.300: Overall description

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

[0055] - 3GPP TS 38.321: Medium Access Control (MAC) protocol

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

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

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

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

[0060] - 3GPP TS 37.340: Multi-connectivity; Overall description

[0061] Sidelink (SL) is a communication method that establishes a direct link between terminals (User Equipment, UE) and directly transmits voice or data between terminals without going through a base station (BS). Sidelink is one solution to alleviate the burden on base stations due to the rapidly increasing data traffic.

[0062] V2X (vehicle-to-everything) refers to a communication technology that exchanges information with other vehicles, pedestrians, and infrastructure-based objects via wired and wireless communications. V2X is divided into four types: V2V (vehicle-to-vehicle), V2I (vehicle-to-infrastructure), V2N (vehicle-to-network), and V2P (vehicle-to-pedestrian). V2X communication is provided via the PC5 interface and / or Uu interface.

[0063] Meanwhile, as more communication devices require greater communication capacity, there is an emerging need for improved mobile broadband communication compared to existing radio access technologies (RATs). This has led to discussions about communication systems that take into account reliability- and latency-sensitive services or terminals. Next-generation radio access technologies that take into account such improved mobile broadband communication, massive MTC, and ultra-reliable and low latency communication (URLLC) are called new radio access technologies (RATs) or new radios (NRs). NRs can also support vehicle-to-everything (V2X) communication.

[0064] The following technologies can be used for various wireless access systems, such as CDMA (Code Division Multiple Access), FDMA (Frequency Division Multiple Access), TDMA (Time Division Multiple Access), OFDMA (Orthogonal Frequency Division Multiple Access), and SC-FDMA (Single Carrier Frequency Division Multiple Access). CDMA can be implemented using radio technologies such as UTRA (Universal Terrestrial Radio Access) and CDMA2000. TDMA can be implemented using radio technologies such as GSM (Global System for Mobile communications), GPRS (General Packet Radio Service), and EDGE (Enhanced Data Rates for GSM Evolution). OFDMA can be implemented using radio technologies such as IEEE802.11 (Wi-Fi), IEEE802.16 (WiMAX), IEEE802-20, and E-UTRA (Evolved UTRA). IEEE 802.16m is an evolution of IEEE 802.16e and provides backward compatibility with systems based on IEEE 802.16e. UTRA is part of the Universal Mobile Telecommunications System (UMTS). 3GPP (3rd Generation Partnership Project) LTE (long term evolution) is part of E-UMTS (Evolved UMTS) that uses E-UTRA and employs OFDMA on the downlink and SC-FDMA on the uplink. LTE-Advanced (LTE-A) is an evolution of 3GPP LTE.

[0065] 5G NR is the technology that follows LTE-A and is a new clean-slate mobile communication system with characteristics such as high performance, low latency, and high availability. 5G NR can utilize all available spectrum resources, from low-frequency bands below 1 GHz to intermediate-frequency bands between 1 GHz and 10 GHz, and high-frequency (millimeter wave) bands above 24 GHz.

[0066] For clearer explanation, the following description will be focused on LTE-A or 5G NR, but the technical idea according to an embodiment of the present invention is not limited thereto.

[0067] 2 shows the structure of an LTE system according to one embodiment of the present invention, which is also called E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) or LTE (Long Term Evolution) / LTE-A system.

[0068] 2, the E-UTRAN includes a base station 20 that provides a control plane and a user plane to a terminal 10. The terminal 10 may be fixed or mobile, and may also be referred to as a mobile station (MS), user terminal (UT), subscriber station (SS), mobile terminal (MT), wireless device, etc. Generally, the base station 20 is a fixed station that communicates with the terminal 10, and may also be referred to as an evolved NodE-B (eNB), base transceiver system (BTS), access point (AP), etc.

[0069] The base stations 20 are connected to each other via the X2 interface. The base stations 20 are connected to the evolved packet core (EPC) 30 via the S1 interface, more specifically to the mobility management entity (MME) via the S1-MME and to the serving gateway (S-GW) via the S1-U.

[0070] EPC 30 consists of MME, S-GW, and P-GW (Packet Data Network - Gateway). MME has information about terminal connection information and terminal capabilities, and such information is mainly used for terminal mobility management. S-GW is a gateway with E-UTRAN as its end point, and P-GW is a gateway with PDN (Packet Data Network) as its end point.

[0071] The radio interface protocol layers between a terminal and a network are classified into Layer 1 (L1), Layer 2 (L2), and Layer 3 (L3) based on the bottom three layers of the Open System Interconnection (OSI) reference model, which is well known in communication systems. Among them, the physical layer belonging to Layer 1 provides information transmission services using physical channels, and the Radio Resource Control (RRC) layer belonging to Layer 3 controls radio resources between the terminal and the network. To this end, the RRC layer exchanges RRC messages between the terminal and the base station.

[0072] Figure 3 shows the structure of an NR system.

[0073] Referring to FIG. 3, a Next Generation Radio Access Network (NG-RAN) includes a next generation node BF cell (gNB) and / or an eNB that provide user plane and control plane protocol termination for a terminal. FIG. 3 illustrates a case where only a gNB is included. The gNB and eNB are connected to each other via an Xn interface. The gNB and eNB are connected to a 5th generation core network (5G Core Network: 5GC) via an NG interface. More specifically, they are connected to an access and mobility management function (AMF) via an NG-C interface and to a user plane function (UPF) via an NG-U interface.

[0074] Figure 4 shows the structure of an NR radio frame.

[0075] Referring to Figure 4, in NR, radio frames are used for uplink and downlink transmission. A radio frame has a length of 10 ms and is defined by two 5 ms half-frames (HF). A half-frame includes five 1 ms subframes (SF). A subframe is divided into one or more slots, and the number of slots within a subframe depends on the subcarrier spacing (SCS). Each slot includes 12 or 14 OFDM(A) symbols depending on the cyclic prefix (CP).

[0076] When a normal CP is used, each slot contains 14 symbols. When an extended CP is used, each slot contains 12 symbols. Here, the symbols include OFDM symbols (or CP-OFDM symbols) and SC-FDMA symbols (or DFT-s-OFDM symbols).

[0077] Table 1 shows the number of symbols per slot (N) depending on the SCS setting (μ) when a general CP is used. slot symbol ), number of slots per frame (N frame,u slot ) and the number of slots per subframe (N subframe,u slot ) is shown below.

[0078] [Table 1]

[0079] Table 2 illustrates the number of symbols per slot, the number of slots per frame, and the number of slots per subframe according to the SCS when an extended CP is used.

[0080] [Table 2]

[0081] In an NR system, OFDM(A) pneumatology (e.g., SCS, CP length, etc.) can be configured to be different among multiple cells merged into one UE, and thus the (absolute time) duration of time resources (e.g., subframes, slots, or TTIs) (commonly referred to as TUs (Time Units) for convenience) consisting of the same number of symbols can be configured to be different among the merged cells.

[0082] NR supports multiple pneumothoraxes or SCSs to support various 5G services. For example, a 15 kHz SCS supports wide areas in traditional cellular bands, while a 30 kHz / 60 kHz SCS supports dense urban areas, lower latency, and wider carrier bandwidths. A 60 kHz or higher SCS supports bandwidths greater than 24.25 GHz to overcome phase noise.

[0083] The NR frequency band is defined by two types of frequency ranges. The two types of frequency ranges are FR1 and FR2. The numerical values of the frequency ranges are variable. For example, the two types of frequency ranges are as shown in Table 3 below. Of the frequency ranges used in the NR system, FR1 refers to the "sub 6 GHz range" and FR2 refers to the "above 6 GHz range," also known as millimeter wave (mmW).

[0084] [Table 3]

[0085] As mentioned above, the numerical values of the frequency range of the NR system can be changed. For example, FR1 includes the band from 410 MHz to 7125 MHz, as shown in Table 4 below. That is, FR1 includes frequency bands above 6 GHz (or 5850, 5900, 5925 MHz, etc.). For example, the frequency bands above 6 GHz (or 5850, 5900, 5925 MHz, etc.) included in FR1 include unlicensed bands. Unlicensed bands are used for various purposes, such as communications for vehicles (e.g., autonomous driving).

[0086] [Table 4]

[0087] FIG. 5 is a diagram showing the slot structure of an NR frame.

[0088] 5, a slot includes a plurality of symbols in the time domain. For example, in the case of a general CP, one slot includes 14 symbols, but in the case of an extended CP, one slot includes 12 symbols. Alternatively, in the case of a general CP, one slot includes 7 symbols, but in the case of an extended CP, one slot includes 6 symbols.

[0089] A carrier wave includes multiple subcarriers in the frequency domain. An RB (Resource Block) is defined as multiple (e.g., 12) consecutive subcarriers in the frequency domain. A BWP is defined as multiple consecutive (P)RBs (Physical Resource Blocks) in the frequency domain and corresponds to one numerology (e.g., SCS, CP length, etc.). A carrier wave includes up to N (e.g., 5) BWPs. Data communication is performed using activated BWPs. Each element in the resource grid is called a resource element (RE), and one complex symbol can be mapped to it.

[0090] Meanwhile, a radio interface between terminals or a radio interface between a terminal and a network is composed of an L1 layer, an L2 layer, and an L3 layer. In various embodiments of the present invention, the L1 layer refers to a physical layer. The L2 layer refers to, for example, any one of a MAC layer, an RLC layer, a PDCP layer, and an SDAP layer. The L3 layer refers to, for example, an RRC layer.

[0091] V2X or SL (sidelink) communication will be explained below.

[0092] Figure 6 shows the radio protocol architecture for SL communication. More specifically, Figure 6(a) shows the NR user plane protocol stack, and Figure 6(b) shows the NR control plane protocol stack.

[0093] The SL synchronization signal (Sidelink Synchronization Signal, SLSS) and synchronization information will be described below.

[0094] The SLSS includes a Primary Sidelink Synchronization Signal (PSSS) and a Secondary Sidelink Synchronization Signal (SSSS) as SL-specific sequences. The PSSS is called a Sidelink Primary Synchronization Signal (S-PSS), and the SSSS is called a Sidelink Secondary Synchronization Signal (S-SSS). For example, length-127 M-sequences are used for the S-PSS, and length-127 Gold sequences are used for the S-SSS. For example, a terminal performs initial signal detection and acquires synchronization using the S-PSS. For example, a terminal acquires detailed synchronization and detects a synchronization signal ID using the S-PSS and S-SSS.

[0095] The PSBCH (Physical Sidelink Broadcast Channel) is a (broadcast) channel that transmits basic (system) information that a terminal must first know before transmitting or receiving an SL signal. For example, the basic information includes information about SLSS, duplex mode (DM), TDD UL / DL (Time Division Duplex Uplink / Downlink) configuration, information about the resource pool, the type of application related to SLSS, subframe offset, broadcast information, etc. For example, to evaluate the performance of the PSBCH, in NR V2X, the payload size of the PSBCH is 56 bits including a 24-bit CRC.

[0096] The S-PSS, S-SSS, and PSBCH are included in a block format (e.g., an SL Synchronization Signal (SS) / PSBCH block, hereinafter referred to as an S-SSB (Sidelink-Synchronization Signal Block)) that supports periodic transmission. The S-SSB has the same pneumatics (i.e., SCS and CP length) as the PSCCH (Physical Sidelink Control Channel) / PSSCH (Physical Sidelink Shared Channel) in a carrier, and the transmission bandwidth is within a (pre-set) SL BWP (Sidelink BWP). For example, the bandwidth of the S-SSB is 11 RBs (Resource Blocks). For example, the PSBCH spans 11 RBs. In addition, the frequency location of the S-SSB is (pre-set). Therefore, the terminal does not need to perform hypothesis detection in frequency to find the S-SSB in the carrier.

[0097] Meanwhile, in an NR SL system, multiple pneumothorologies with different SCS and / or CP lengths are supported. Here, as the SCS increases, the length of the time resource in which a transmitting terminal transmits an S-SSB decreases. This reduces S-SSB coverage. Therefore, to ensure S-SSB coverage, a transmitting terminal transmits one or more S-SSBs to a receiving terminal within one S-SSB transmission period according to the SCS. For example, the number of S-SSBs that a transmitting terminal transmits to a receiving terminal within one S-SSB transmission period is pre-configured or configured in the transmitting terminal. For example, the S-SSB transmission period is 160 ms. For example, an S-SSB transmission period of 160 ms is supported for all SCSs.

[0098] For example, if the SCS is 15 kHz in FR1, the transmitting terminal transmits one or two S-SSBs to the receiving terminal within one S-SSB transmission period. For example, if the SCS is 30 kHz in FR1, the transmitting terminal transmits one or two S-SSBs to the receiving terminal within one S-SSB transmission period. For example, if the SCS is 60 kHz in FR1, the transmitting terminal transmits one, two, or four S-SSBs to the receiving terminal within one S-SSB transmission period.

[0099] For example, if the SCS is 60 kHz in FR2, the transmitting terminal transmits 1, 2, 4, 8, 16, or 32 S-SSBs to the receiving terminal within one S-SSB transmission period. For example, if the SCS is 120 kHz in FR2, the transmitting terminal transmits 1, 2, 4, 8, 16, 32, or 64 S-SSBs to the receiving terminal within one S-SSB transmission period.

[0100] Meanwhile, when the SCS is 60 kHz, two types of CP are supported. The structure of the S-SSB transmitted from the transmitting terminal to the receiving terminal may vary depending on the CP type. For example, the CP type is a normal CP (NCP) or an extended CP (ECP). Specifically, for example, when the CP type is NCP, the number of symbols to which the PSBCH is mapped within the S-SSB transmitted from the transmitting terminal is nine or eight. On the other hand, for example, when the CP type is ECP, the number of symbols to which the PSBCH is mapped within the S-SSB transmitted from the transmitting terminal is seven or six. For example, the PSBCH is mapped to the first symbol within the S-SSB transmitted from the transmitting terminal. For example, a receiving terminal receiving an S-SSB performs an automatic gain control (AGC) operation during the first symbol period of the S-SSB.

[0101] FIG. 7 shows a terminal performing V2X or SL communication.

[0102] 7, in V2X or SL communication, the term "terminal" mainly refers to a user terminal. However, when network equipment such as a base station transmits and receives signals according to a terminal-to-terminal communication method, the base station may also be considered a type of terminal. For example, terminal 1 is a first device 100, and terminal 2 is a second device 200.

[0103] For example, terminal 1 selects a resource unit corresponding to a specific resource in a resource pool, which means a collection of a series of resources. Terminal 1 then transmits an SL signal using the resource unit. For example, terminal 2, which is a receiving terminal, is configured with a resource pool capable of transmitting a signal to terminal 1, and detects the signal of terminal 1 in the resource pool.

[0104] Here, when terminal 1 is within the connection range of the base station, the base station notifies terminal 1 of a resource pool. On the other hand, when terminal 1 is outside the connection range of the base station, another terminal notifies terminal 1 of a resource pool, or terminal 1 uses a pre-configured resource pool.

[0105] Generally, a resource pool consists of multiple resource units, and each terminal selects one or more resource units to use for its SL signal transmission.

[0106] FIG. 8 shows resource units for V2X or SL communication.

[0107] Referring to Figure 8, the total frequency resources of the resource pool are divided into NF subframes, and the total time resources of the resource pool are divided into NT subframes. Thus, a total of NF*NT resource units are defined within the resource pool. Figure 8 shows an example in which the resource pool is repeated every NT subframes.

[0108] As shown in Fig. 8, one resource unit (e.g., Unit #0) is shown to be repeated periodically. Alternatively, to obtain a diversity effect in the time or frequency dimension, the index of the physical resource unit to which one logical resource unit is mapped may change over time in a predetermined pattern. In this resource unit structure, a resource pool refers to a collection of resource units that a terminal that wishes to transmit an SL signal can use for transmission.

[0109] Resource pools can be subdivided into various types. For example, depending on the content of the SL signal transmitted from each resource pool, resource pools can be classified as follows:

[0110] (1) A Scheduling Assignment (SA) is a signal containing information such as the location of resources used by a transmitting terminal to transmit an SL data channel, a Modulation and Coding Scheme (MCS) or a Multiple Input Multiple Output (MIMO) transmission method required for demodulating other data channels, and a Timing Advance (TA). The SA can be multiplexed with SL data on the same resource unit and transmitted, and in this case, the SA resource pool refers to a resource pool in which the SA is multiplexed with the SL data and transmitted. The SA is also called an SL control channel.

[0111] (2) The SL data channel (Physical Sidelink Shared Channel, PSSCH) is a resource pool used by a transmitting terminal to transmit user data. If SA is multiplexed and transmitted together with SL data on the same resource unit, only the SL data channel excluding SA information is transmitted from the resource pool for the SL data channel. In other words, REs (Resource Elements) used to transmit SA information on individual resource units in the SA resource pool can still be used to transmit SL data in the resource pool for the SL data channel. For example, the transmitting terminal maps PSSCH to consecutive PRBs and transmits them.

[0112] (3) The discovery channel is a resource pool for a transmitting terminal to transmit information such as its ID, allowing neighboring terminals to discover it.

[0113] Even if the content of the SL signal is the same, different resource pools can be used depending on the attributes of transmission and reception of the SL signal. For example, even if the same SL data channel or discovery message is used, the SL signal may be divided into different resource pools depending on the method of determining the transmission timing of the SL signal (e.g., whether it is transmitted at the time of reception of the synchronization reference signal or whether it is transmitted with a certain timing advance applied to the reception time), the resource allocation method (e.g., whether the base station assigns transmission resources for individual signals to individual transmitting terminals or whether individual transmitting terminals select individual signal transmission resources themselves within a resource pool), the signal format (e.g., the number of symbols each SL signal occupies in one subframe or the number of subframes used to transmit one SL signal), the signal strength from the base station, the transmission power strength of the SL terminal, etc.

[0114] SL DRX(sidelink discontinuous reception)

[0115] SL supports SL DRX for unicast, groupcast, and broadcast. Similar parameters for Uu (on-duration, inactivity timer, retransmission timer, cycle) are defined for SL to determine the SL active time for SL DRX. During the SL active time, the terminal performs SCI monitoring for data reception (e.g., two-stage SCI for PSCCH and PSSCH). During the SL DRX inactive time, the terminal may skip SCI monitoring for data reception.

[0116] The actual parameters supported for each cast type (unicast, groupcast, broadcast) are specified in the next subsections.

[0117] The SL active time of the RX UE includes the time during which the applicable SL on-duration timer, SL inactivity timer, or SL retransmission timer (for one of unicast, groupcast, or broadcast) runs. Also, the slots associated with the TX UE's announced periodic transmissions and the time during which the UE expects a CSI report accompanying a CSI request (for unicast) are considered to be the SL active time of the RX UE.

[0118] The TX terminal maintains a timer set corresponding to the SL DRX timer of the RX terminal for each source / destination L2 ID pair for unicast or each destination L2 ID for groupcast / broadcast. When there is data to transmit to one or more RX terminals configured with SL DRX, the TX terminal selects resources taking into account the active time of the RX terminals determined by the timers maintained by the TX terminal itself.

[0119] In the unicast case, for each pair of source L2 ID and destination L2 ID, an SL DRX is configured.

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

[0121] The RX terminal may transmit assistance information including the desired on-duration timer, SL DRX start offset, and SL DRX period to the TX terminal, which the Mode 2 TX terminal may use to determine the SL DRX settings for the RX terminal.

[0122] Regardless of whether assistance information is provided, a TX UE in RRC_IDLE / RRC_INACTIVE / OOC or a TX UE in RRC_CONNECTED using Mode 2 resource allocation determines the SL DRX configuration for the RX UE. For a TX UE in RRC_CONNECTED using Mode 1 resource allocation, the SL DRX configuration for the RX UE is determined by the serving base station of the TX UE.

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

[0124] - The RX terminal accepts or rejects the SL DRX setting.

[0125] The default SL DRX configuration for groupcast / broadcast is used for the DCR message.

[0126] When the TX terminal is RRC_CONNECTED, the TX terminal reports the received assistance information to the serving base station, and when the TX terminal receives the SL DRX configuration in the base station via a dedicated RRC signal, it transmits the SL DRX configuration to the RX terminal. When the RX terminal is RRC_CONNECTED, the RX terminal reports the received SL DRX configuration to its serving base station, for example, for alignment of the Uu configuration and the SL DRX configuration.

[0127] The SL on-duration timer, SL inactivity timer, SL HARQ RTT timer, and SL HARQ retransmission timer are supported in unicast. The SL HARQ RTT timer and SL HARQ retransmission timer are maintained per SL process in the RX terminal. If the SCI indicates more than one transmission resource, in addition to the (pre)configured values for each of these timers, the SL HARQ RTT timer value is derived from the retransmission resource timing.

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

[0129] In the case of groupcast / broadcast, SL DRX is configured commonly among multiple terminals based on the QoS profile and destination L2 ID. Multiple SL DRX configurations can be supported for each groupcast / broadcast.

[0130] For groupcast, the SL on-duration timer, SL inactivity timer, SL HARQ RTT timer, and SL retransmission timer are supported. For broadcast, only the SL on-duration timer is supported. The SL DRX period, SL on-duration, and SL inactivity timer (applicable to groupcast only) are configured for each QoS profile. The start offset and slot offset of the SL DRX period are determined according to the destination L2 ID. The SL HARQ RTT timer (applicable to groupcast only) and SL HARQ retransmission timer (applicable to groupcast only) are not configured for each QoS profile or destination L2 ID. In the case of groupcast, the RX terminal maintains an SL inactivity timer for each destination L2 ID, and if multiple SL inactivity timer values associated with different QoS profiles are configured for that L2 ID, it selects the largest SL inactivity timer value. In the case of groupcast and broadcast, when multiple QoS profiles are configured for each destination L2 ID, the RX terminal maintains a single SL DRX period (selected as the smallest SL DRX period of all QoS profiles for that L2 ID) and a single SL on-duration (selected as the largest SL on-duration of all QoS profiles for that L2 ID) for that L2 ID.

[0131] In the case of groupcast, the SL HARQ RTT timer and the SL retransmission timer are maintained for each SL process in the RX UE. The SL HARQ RTT timer may be set to different values to support both HARQ enabled transmission and HARQ disabled transmission.

[0132] The basic SL DRX setting, which is common between groupcast and broadcast, is used for QoS profiles that do not map to non-default SL DRX settings.

[0133] TX and RX terminals in RRC_IDLE / RRC_INACTIVE coverage obtain their SL DRX configuration in the SIB. RRC_CONNECTED (TX or RX) terminals obtain the SL DRX configuration in the SIB or from dedicated RRC signaling during handover. When out of coverage, the SL DRX configuration is obtained by pre-configuration.

[0134] In the case of groupcast, when the TX terminal receives new data with the same destination L2 ID, it restarts its own timer corresponding to the SL inactivity timer for the destination L2 ID (used to determine the allowable transmission time).

[0135] The TX profile is introduced to ensure compatibility for groupcast and broadcast transmission between terminals that support / do not support the SL DRX function. The TX profile is provided to the AS layer from a higher layer and identifies one or more SL function groups. The TX terminal assumes SL DRX for the RX terminal only if the associated TX profile supports SL DRX. The RX terminal determines that SL DRX is to be used if all destination L2 IDs of interest have associated TX profiles that support SL DRX.

[0136] For unicast, groupcast, and broadcast, alignment of Uu DRX and SL DRX for an RRC_CONNECTED UE is supported. Alignment of Uu DRX and SL DRX for the same UE is supported. Also, in Mode 1 scheduling, alignment of Uu DRX of a TX UE and SL DRX of a RX UE is supported.

[0137] Alignment is performed with total or partial time overlap between Uu DRX and SL DRX. For an RRC_CONNECTED SL RX terminal, alignment is performed at the base station.

[0138] The SL DRX function that controls the terminal's SCI (i.e., 1st-stage SCI and 2nd-stage SCI) monitoring activity for unicast, groupcast, and broadcast is configured in the MAC entity by RRC. When using SL DRX operation, the MAC entity must also monitor the SCI (i.e., 1st-stage SCI and 2nd-stage SCI) in accordance with the requirements in other sections of this invention.

[0139] RRC sets the following parameters to control the SL DRX operation:

[0140] - sl-drx-onDurationTimer: Duration at the start of the SL DRX cycle

[0141] - sl-drx-SlotOffset: Delay before starting sl-drx-onDurationTimer

[0142] - sl-drx-InactivityTimer (excluding broadcast transmissions): the period after the first slot of reception of an SCI (i.e., one-phase SCI and two-phase SCI) indicating a new SL transmission to the MAC entity.

[0143] - sl-drx-RetransmissionTimer (per SL process excluding broadcast transmissions): Maximum period before receiving a SL retransmission

[0144] - sl-drx-StartOffset: The slot at which the SL DRX cycle starts

[0145] - sl-drx-Cycle: SL DRX cycle

[0146] - sl-drx-HARQ-RTT-Timer (per SL process excluding broadcast transmissions): minimum period before which the MAC entity should expect a SL HARQ retransmission

[0147] When SL DRX is configured, the Active Time includes the following times:

[0148] - The time that sl-drx-onDurationTimer or sl-drx-InactivityTimer runs, or

[0149] - The time when the sl-drx-RetransmissionTimer runs, or

[0150] - the sl-LatencyBoundCSI-Report interval configured by RRC if no SL-CSI reporting MAC CE is received, or

[0151] - if an SL-CSI Report MAC CE is received, the time between the transmission of the SL-CSI Report Request and the reception of the SL-CSI Report MAC CE, or

[0152] - Slots associated with the known periodic transmissions of the terminal transmitting SL-SCH data.

[0153] If one or more SL DRX are configured, the MAC entity does the following:

[0154] 1> When multiple SL DRX cycles mapped to multiple SL-QoS-Profiles with destination Layer-2 ID and Interest-cast type are related to groupcast and broadcast:

[0155] 2> Select the sl-drx-Cycle with the shortest length from among the multiple SL DRX cycles mapped to the multiple SL-QoS-Profiles associated with the destination Layer-2 ID.

[0156] 2> Select the sl-drx-onDurationTimer with the longest duration from among the multiple SL DRX onduration timers mapped to the multiple SL-QoS-Profiles associated with the destination Layer-2 ID.

[0157] 1> When sl-drx-HARQ-RTT-Timer expires:

[0158] 2> If the data of the SL process is not successfully decoded or no HARQ feedback (i.e., negative acknowledgment) is sent in unicast by the UL / SL priority:

[0159] 3> After the sl-drx-HARQ-RTT-Timer expires, start the sl-drx-RetransmissionTimer for the SL process in the first slot.

[0160] If the cast type is groupcast or broadcast as instructed by the upper layer, sl-drx-StartOffset and sl-drx-SlotOffset are derived from the following formulas.

[0161] sl-drx-StartOffset(ms) = Destination Layer-2 ID modulo sl-drx-Cycle(ms).

[0162] sl-drx-SlotOffset(ms) = Destination Layer-2 ID modulo sl-drx-onDurationTimer(ms).

[0163] 1> If SL DRX cycle is used and [(DFN Х 10) + subframe number] modulo (sl-drx-Cycle) = sl-drx-StartOffset:

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

[0165] 1> When SL DRX is active time:

[0166] 2> SCI (i.e., 1st-stage SCI and 2nd-stage SCI) is monitored during this SL DRX.

[0167] 2> If SCI indicates a new SL transmission:

[0168] 3> If the SCI's source Layer-1 ID is equal to the 8 LSBs of the intended destination Layer-2 ID, and the SCI's destination Layer-1 ID is equal to the 8 LSBs of the intended source Layer-2 ID, and the SCI's cast type indicator is set to unicast:

[0169] 4> After the first slot of SCI reception, start or restart the sl-drx-InactivityTimer for that source Layer-2 ID and destination Layer-2 ID pair.

[0170] 3> If the destination Layer-1 ID of the SCI (i.e., a two-stage SCI) is equal to the 8 LSBs of the intended destination Layer-1 ID and the cast type indicator of the SCI is set to group cast:

[0171] 4> Select the sl-drx-InactivityTimer with the longest length among 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.

[0172] 4> After the first slot of SCI reception, start or restart the sl-drx-InactivityTimer for that destination Layer-2 ID.

[0173] 2> If SCI indicates SL transmission:

[0174] 3> If no PSFCH resource is configured for the SL grant related to the SCI:

[0175] 4> Start the sl-drx-HARQ-RTT-Timer for that SL process in the slot after the PSSCH (i.e., the currently received PSSCH) transmission ends.

[0176] 3> If PSFCH resources are configured for SL grants related to SCI:

[0177] 4> HARQ feedback is activated by SCI and the cast type indicator of SCI is set to unicast; or 4> HARQ feedback is activated by SCI and the cast type indicator of SCI is set to groupcast and positive-negative acknowledgement is selected;

[0178] 5> Start the sl-drx-HARQ-RTT-Timer for that SL process at the first slot after the corresponding PSFCH transmission carrying SL HARQ feedback has finished, or

[0179] 5> When SL HARQ feedback is not sent due to UL / SL priority, start the sl-drx-HARQ-RTT-Timer for that SL process at the first slot after the corresponding PSFCH resource for SL HARQ feedback is terminated.

[0180] 4> HARQ feedback is activated in the SCI, the cast type indicator of the SCI is set to groupcast, and negative-only acknowledgment is selected;

[0181] 5> Start the sl-drx-HARQ-RTT-Timer for that SL process at the first slot after the corresponding PSFCH transmission carrying SL HARQ feedback has finished, or

[0182] 5> When SL HARQ feedback is not sent with UL / SL priority, start the sl-drx-HARQ-RTT-Timer for that SL process at the first slot after the corresponding PSFCH resource for SL HARQ feedback is finished; or

[0183] 5> When the SL HARQ feedback is a positive confirmation, start the sl-drx-HARQ-RTT-Timer for that SL process at the 1st slot after the corresponding PSFCH resource for the SL HARQ feedback is finished.

[0184] 4> If the SCI deactivates HARQ feedback and no resources for one or more retransmission opportunities are scheduled at the SCI:

[0185] 5> Start the sl-drx-HARQ-RTT-Timer for that SL process in the slot after the PSFCH resource ends.

[0186] 4> If HARQ feedback is deactivated in the SCI and resources for one or more retransmission opportunities are scheduled in the SCI:

[0187] 5> Start the sl-drx-HARQ-RTT-Timer for that SL process in the slot after the PSSCH (i.e., the currently received PSSCH) transmission has ended.

[0188] 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 immediately next retransmission resource indicated in the SCI). The terminal uses the configured sl-drx-HARQ-RTT-Timer when the SCI does not indicate the next transmission resource.

[0189] 3> Stop the sl-drx-RetransmissionTimer for that SL process.

[0190] 1> If a SL DRX command MAC CE is received for a unicast source Layer-2 ID and destination Layer-2 ID pair:

[0191] 2> Stop the sl-drx-onDurationTimer for the unicast source Layer-2 ID and destination Layer-2 ID pair.

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

[0193] Inter-UE Coordination (IUC)

[0194] The SL terminal supports inter-terminal coordination (IUC) in mode 2. Here, terminal A transmits resource-related information to terminal B, which uses it for resource (re)selection. The following inter-terminal coordination methods are supported:

[0195] - IUC scheme 1. Coordination information transmitted from terminal-A to terminal-B indicates preferred and / or non-preferred resources for transmission of terminal-B.

[0196] - IUC Method 2. The coordination information sent from terminal A to terminal B indicates the existence of expected / potential resource collisions for the resources indicated by the SCI of terminal B.

[0197] In Scheme 1, IUC can be triggered by an explicit request from UE-B or the state of UE-A. UE-A determines a resource set reserved by another UE or a slot set in which UE-A is not expected to receive SL from UE-B through half-duplex operation when UE-A is the intended receiver of UE-B. UE-A uses these resources as a non-preferred resource set or determines a preferred resource set excluding these resources, and transmits the preferred / non-preferred resources to UE-B. The resources UE-B uses for resource (re)selection may be based on UE-B's sensing result (if available) and the coordination information received by UE-A, or may be based only on the coordination information received by UE-A. In Scheme 1, IUC can be transmitted using MAC CE and two-stage SCI or MAC CE only. Explicit requests and reports for IUC are supported in a unicast manner.

[0198] In method 2, terminal-A determines resources that are reserved by other terminals and identified by terminal-A as completely / partially overlapping with the resources indicated by terminal-B's SCI, or slots in which terminal-A is the intended receiver of terminal-B and is not expected to perform SL reception in the slot by half-duplex operation, as expected / potential collision resources among the resources indicated by terminal-B's SCI. Terminal-B uses the collision resources to determine resources to reselect and excludes the collision resources from the reselected resources. In method 2, IUC is transmitted using the PSFCH.

[0199] The SL-IUC Req transmission procedure is used to trigger transmission of coordination information between SL terminals of peer UEs.

[0200] The SL-IUC Info reporting procedure is used to provide end-to-end coordination information to a peer terminal.

[0201] - sl-LatencyBoundIUC-Report is maintained for each PC5-RRC connection.

[0202] The MAC entity maintains an 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 by the SL-IUC information reporting terminal to comply with the delay requirement notified by the IUC-Information triggering terminal. The value of the sl-IUC-ReportTimer is the same as the SL-IUC information delay requirement of the sl-LatencyBoundIUC-Report configured by the RRC.

[0203] The MAC entity shall do the following for each pair of source Layer-2 ID and destination Layer-2 ID corresponding to the PC5-RRC connection established by the upper layer:

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

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

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

[0207] 2> If the sl-IUC-ReportTimer expires for a triggered SL-IUC Information Report:

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

[0209] 2> Otherwise, if the MAC entity has SL resources allocated for the new transmission and, as a result of the logical channel priority, the SL-SCH resources can accommodate the SL-IUC information MAC CE and its subheader:

[0210] 3> Instructs the multiplexing and assembly procedure to generate coordination information MAC CE between SL terminals as defined in 6.1.3.35.

[0211] 3> Stop the sl-IUC-ReportTimer for the triggered SL-IUC information report.

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

[0213] FIG. 9 shows the coordination information MAC CE between terminals.

[0214] The end-to-end coordination information MAC CE is identified by a MAC subheader with the LCID specified in Table 5.

[0215] [Table 5]

[0216] The priority of the inter-terminal coordination information MAC CE is fixed to "1." The inter-terminal coordination information MAC CE has a variable size and includes the following fields:

[0217] - RT: This field is the codepoint value of the SCI Format 2-C resourceSetType field and indicates the resource set type, i.e., preferred or non-preferred resource set.

[0218] - RSL: This field is the code point value of the referenceSlotLocation field of SCI Format 2-C and indicates the location of the reference slot. The length of the field is 17 bits. If the length of the referenceSlotLocation field of SCI Format 2-C is shorter than 17 bits, this field contains the referenceSlotLocation field using the LSB bits.

[0219] - LSIi: This field is the codepoint value of the lowestIndices field in SCI Format 2-C and indicates the lowest subchannel index for the first resource position of each TRIV. LSI0 indicates the lowest subchannel index for the first resource position of a TRIV in the first resource combination, and LSI1 indicates the lowest subchannel index for the first resource position of a TRIV in the second resource combination. The length of this field is 5 bits. If the length of the lowestIndices field in SCI Format 2-C is shorter than 5 bits, this field contains the lowestIndices field using the LSB bits.

[0220] - RCi: This field is the code point value of the resourceCombination field in SCI Format 2-C and indicates the resource combination. RC0 indicates the first resource combination, RC1 indicates the second resource combination. [The maximum number of resource combinations included is 8.] The length of the 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.

[0221] - First resource location i-1: This field is the code point value of the firstResourceLocation field in SCI Format 2-C and indicates the first resource location. First Resource location 0 indicates the first resource location of the second resource combination, and First Resource location 1 indicates the first resource location of the third resource combination. 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 bits.

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

[0223] FIG. 10 shows an end-to-end coordination request MAC CE.

[0224] The end-to-end coordination request MAC CE is identified by a MAC subheader with the LCID specified in Table 5. The priority of the end-to-end coordination request MAC CE is fixed to "1". The end-to-end coordination request MAC CE has a variable size and contains the following fields:

[0225] - RT: This field is the codepoint value of the SCI Format 2-C resourceSetType field and indicates the resource set type, i.e., preferred or non-preferred resource set.

[0226] - RP: This field is the codepoint value of the resourceReservationPeriod field in SCI Format 2-C and indicates the resource reservation period. The length of the 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 least significant bits.

[0227] - Priority: This field is the code point value of the SCI format 2-C priority field, indicating the priority. The field length is 3 bits.

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

[0229] - Number of Subchannel: This field is the code point value of the SCI Format 2-C numberOfSubchannel field and indicates the number of subchannels. The length of the 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 bits.

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

[0231] SL Relay

[0232] The SL relay was introduced to support the 5G ProSe terminal-to-network relay (U2N relay) function, which provides network connectivity to U2N remote terminals. Both L2 and L3 U2N relay architectures are supported. The L3 U2N relay architecture is transparent to the serving RAN of the U2N relay terminal, except for SL resource control.

[0233] Relay Discovery: An AS function that uses NR technology but activates 5G ProSe UE-to-Network Relay Discovery without going through a network node.

[0234] U2N relay terminal: A terminal that provides the function of supporting network connection for U2N remote terminals.

[0235] U2N Remote Terminal: A terminal that communicates with the network via a U2N Relay Terminal.

[0236] Upstream: From the IAB topology towards the parent node.

[0237] Uu relay RLC channel: An RLC channel between an L2 U2N relay terminal and a base station, used to transmit packets over Uu for relay between the L2 terminal and the network.

[0238] A U2N relay terminal must be in the RRC_CONNECTED state to relay unicast data.

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

[0240] - Both the U2N relay terminal and the U2N remote terminal can send / receive relayed unicast data only when they are in the RRC CONNECTED state.

[0241] - If all U2N remote terminals connected to the U2N relay terminal are in RRC_INACTIVE or RRC_IDLE, the U2N relay terminal is in RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED.

[0242] For L2 U2N relay, the U2N remote terminal is configured to use only resource allocation mode 2 for the data it relays.

[0243] A single unicast link is set up between one L2 U2N relay terminal and one L2 U2N remote terminal. The U2N remote terminal traffic and the U2N relay terminal traffic via a given U2N relay terminal need to be separated onto different Uu RLC channels on Uu.

[0244] SL Relay Protocol Stack

[0245] FIG. 11 shows (a) the user plane protocol stack and (b) the control plane protocol stack for the L2 terminal-network relay.

[0246] The protocol stacks for the user plane and control plane of the L2 U2N relay architecture are shown in Figures 11(a) and 11(b). The SRAP sublayer is located above the RLC sublayer for both CP and UP on both the PC5 and Uu interfaces. The Uu SDAP, PDCP, and RRC are terminated between the L2 U2N remote terminal and the base station, while the SRAP, RLC, MAC, and PHY are terminated at each hop (i.e., the link between the L2 U2N remote terminal and the L2 U2N relay terminal and the link between the L2 U2N relay terminal and the base station).

[0247] For L2 U2N relay, the SRAP sublayer over the PC5 hop is for bearer mapping only. The SRAP sublayer does not exist on the PC5 hop for relaying L2 U2N remote terminal messages on the BCCH and PCCH. For L2 U2N remote terminal messages on SRBO, the SRAP sublayer does not exist on the PC5 hop, but there is an SRAP sublayer on the Uu hop in both DL and UL.

[0248] For L2 U2N relay, uplink:

[0249] - The Uu SRAP sublayer supports UL bearer mapping between the incoming PC5 relay RLC channel and the outgoing Uu relay RLC channel for relaying over the L2 U2N relay terminal Uu interface. For uplink relay traffic, other end-to-end RBs (SRBs or DRBs) of the same remote terminal and / or other remote terminals are multiplexed over the same Uu relay RLC channel.

[0250] - The Uu SRAP sublayer supports L2 U2N remote terminal identification for UL traffic. L2 U2N remote terminal Uu radio bearer ID information and local remote terminal ID are included in the UL Uu SRAP header so that the base station can correlate received packets to the specific PDCP entity associated with the correct Uu radio bearer for the remote terminal.

[0251] - The PC5 SRAP sublayer of the L2 U2N remote terminal supports UL bearer mapping between the remote terminal Uu radio bearer and the transmit PC5 relay RLC channel.

[0252] For L2 U2N relay, downlink:

[0253] The Uu SRAP sublayer supports DL bearer mapping in the base station, mapping end-to-end radio bearers (SRB, DRB) of a remote terminal to a Uu relay RLC channel via the relay terminal Uu interface. The Uu SRAP sublayer supports DL bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRB or DRB) of an L2 U2N remote terminal and / or other L2 U2N remote terminals and one Uu Relay RLC channel via the relay terminal Uu interface.

[0254] - The Uu SRAP sublayer supports remote terminal identification for DL traffic. The ID information of the remote terminal Uu radio bearer and the local remote terminal ID are included in the Uu SRAP header by the base station in DL so that the relay terminal can map packets received on the remote terminal Uu radio bearer to the associated PC5 Relay RLC channel.

[0255] - The PC5 SRAP sublayer of the relay terminal supports DL bearer mapping between the receiving Uu Relay RLC channel and the transmitting PC5 Relay RLC channel.

[0256] - The PC5 SRAP sublayer of the remote terminal correlates the received packet to the particular PDCP entity associated with the correct Uu radio bearer of the remote terminal based on the ID information contained in the Uu SRAP header.

[0257] The local remote terminal ID is included in both the PC5 SRAP header and the Uu SRAP header. The local remote terminal ID used in the SRAP header is configured in the L2 U2N relay terminal by the base station. The remote terminal obtains the local remote ID from the base station via Uu RRC messages including RRCSetup, RRCReconfiguration, RRCResume, and RRCReestablishment. Uu DRBs and Uu SRBs are mapped to other PC5 relay RLC channels and Uu relay RLC channels in both the PC5 hop and the Uu hop.

[0258] The base station is responsible for collision prevention of local remote terminal ID usage. The base station can update the local remote terminal ID by sending the updated local remote ID to the relay terminal via an RRCReconfiguration message. The serving base station can perform local remote terminal ID updates independently of the PC5 unicast link L2 ID update procedure.

[0259] FIG. 12 shows the protocol stack of a discovery message for relaying between a terminal and a network.

[0260] For U2N relay discovery, two discovery models are supported: Model A and Model B. The protocol stack used for discovery is shown in Figure 12.

[0261] A U2N remote terminal may transmit relay discovery messages and may monitor the SL for relay discovery messages while in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED. The network may broadcast a threshold value that is used to determine whether a U2N remote terminal may transmit a relay discovery solicitation message to a U2N relay terminal.

[0262] A U2N relay terminal may transmit relay discovery messages and may monitor the SL for relay discovery messages 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, that a U2N relay terminal uses to determine whether it can transmit relay discovery messages to a U2N remote terminal.

[0263] The network can provide relay discovery configuration using broadcast or dedicated signaling for relay discovery, and U2N remote terminals and U2N relay terminals can use pre-configuration for relay discovery.

[0264] A resource pool used for NR SL communication may be used for relay discovery, or the network may configure a dedicated resource pool for relay discovery. A dedicated resource pool for relay discovery and a resource pool for NR SL communication may be configured simultaneously through system information, dedicated signaling, and / or pre-configuration. Whether a dedicated resource pool for relay discovery is configured depends on the implementation of the network. If a dedicated resource pool for relay discovery is configured, only the dedicated resource pool for relay discovery is used for relay discovery. If only a resource pool for NR SL communication is configured, all configured transmission resource pools can be used for relay discovery and SL communication.

[0265] For U2N remote terminals (both in-coverage and out-of-coverage) connected to the network by U2N relay terminals, only resource allocation mode 2 is used to transmit discovery messages.

[0266] Relay discovery reuses the NR SL resource allocation principles for in-coverage U2N relay terminals and for all in-coverage and out-of-coverage U2N remote terminals.

[0267] SL power control for relay discovery message transmission is performed similarly to NR SL communication.

[0268] Relay discovery messages are not subject to PDCP layer encryption or integrity protection.

[0269] The terminal determines whether the base station supports relay discovery, non-relay discovery, or both using SIB12.

[0270] Relay selection / reselection

[0271] The U2N remote terminal performs radio measurements on the PC5 interface and uses these, along with higher layer criteria, for U2N relay selection and reselection. If there is no unicast PC5 connection between the U2N relay terminal and the U2N remote terminal, the U2N remote terminal uses SD-RSRP measurements to evaluate whether the PC5 link quality to the U2N relay terminal meets the relay selection criteria.

[0272] If there is data transmission from the U2N relay terminal to the U2N remote terminal for relay reselection, the U2N remote terminal uses SL-RSRP measurements for the serving U2N relay terminal for relay reselection trigger evaluation, and if there is no data transmission from the U2N relay terminal to the U2N remote terminal, whether to use SL-RSRP or SD-RSRP for relay reselection trigger evaluation depends on the implementation of the terminal.

[0273] If the PC5 link quality measured by the U2N remote terminal to a U2N relay terminal exceeds a configured threshold (pre-configured or provided by the base station), the U2N remote terminal considers the U2N relay terminal suitable from a radio criteria perspective. The U2N remote terminal searches for suitable U2N relay terminal candidates that meet all AS hierarchical and upper hierarchical criteria (see TS 23.304[xx]). If there are multiple suitable U2N relay terminals, it is up to the U2N remote terminal's implementation to select one U2N relay terminal from among them. For L2 U2N relay (re)selection, PLMN ID and cell ID can be used as further AS criteria.

[0274] The U2N remote terminal triggers U2N relay selection when:

[0275] - If the direct Uu signal strength of the current serving cell of the U2N remote terminal is lower than the configured signal strength threshold.

[0276] - When instructed by a higher layer of the U2N remote terminal.

[0277] The U2N remote terminal triggers a U2N relay reselection when:

[0278] - If the PC5 signal strength of the current U2N relay terminal is lower than the (pre)configured signal strength threshold.

[0279] - When the U2N relay terminal notifies cell (re)selection, handover or Uu RLF via PC5-RRC signaling.

[0280] - When the remote terminal receives a PC5-S Unlink message from the U2N relay terminal.

[0281] - If the U2N remote terminal detects a PC5 RLF.

[0282] - When instructing at a higher level.

[0283] For L2 U2N remote terminals and L3 U2N remote terminals in RRC_IDLE / INACTIVE, the cell (re)selection procedure and relay (re)selection procedure are performed independently. If both a suitable cell and a suitable U2N relay terminal are available, the cell or the U2N relay terminal is selected depending on the implementation of the terminal. An L3 U2N remote terminal can simultaneously select a cell and a U2N relay terminal, which varies depending on the implementation of the L3 U2N remote terminal.

[0284] For L2 and L3 U2N relay terminals in RRC_IDLE / INACTIVE, when the U2N relay terminal selects a new cell, it uses the PC5-RRC message to notify the remote terminal to which it is connected. The PC5-RRC message is also used to notify the L2 or L3 U2N remote terminal to which it is connected when the L2 / L3 U2N relay terminal performs a handover or detects a Uu RLF. When the U2N remote terminal receives the PC5 RRC message for notification, it decides whether to release or maintain the unicast PC5 link, depending on the implementation of the U2N remote terminal. If the U2N remote terminal decides to release the unicast PC5 link, it can trigger an L2 release procedure and perform relay reselection.

[0285] Control plane procedures for L2 U2N relays

[0286] 1) RRC connection management

[0287] A U2N remote terminal must configure its PDU section / DRB with the network before transmitting user plane data.

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

[0289] The Uu configuration procedure for L2 terminal-network relay is applied to set up the Uu SRB1 / SRB2 and DRB of the U2N remote terminal.

[0290] Figure 13 shows the L2 U2N remote terminal connection setup procedure. The following upper level connection setup procedure in Figure 13 is applied to the L2 U2N relay.

[0291] 1. The U2N remote terminal and the U2N relay terminal perform a discovery procedure and establish a PC5-RRC connection using the NR V2X procedure.

[0292] 2. The U2N remote terminal sends a first RRC message (i.e., RRCSetupRequest) to establish its connection with the base station via the relay terminal using the designated PC5 relay RLC channel setup. If the U2N relay terminal is not in RRC_CONNECTED, it must establish its connection when it receives a message on the designated PC5 relay RLC channel. During the relay terminal's RRC connection setup procedure, the base station can set up a Uu relay RLC channel to relay SRB0 to the U2N relay terminal. The base station responds with an RRCSetup message to the U2N remote terminal. The RRCSetup message is sent to the U2N remote terminal using the SRB0 relay channel via Uu and the designated PC5 relay RLC channel via PC5.

[0293] 3. The base station and the U2N relay terminal perform the relay channel setup procedure via Uu. According to the setup from the base station, the U2N relay / remote terminal sets up a PC5 relay RLC channel to relay SRB1 to the U2N remote / relay terminal via PC5.

[0294] 4. The RRCSetupComplete message is sent from the U2N remote terminal to the base station by the U2N relay terminal using the SRB1 relay channel via PC5 and the SRB1 relay channel set up for the U2N relay terminal via Uu. The U2N remote terminal is then RRC connected via Uu.

[0295] 5. The U2N remote terminal and base station establish security through the Uu procedure, and security messages are transmitted by the U2N relay terminal.

[0296] 6. The base station sends an RRCReconfiguration message to the U2N remote terminal via the U2N relay terminal to set up an SRB2 / DRB for relay purposes. In response, the U2N remote terminal sends an RRCReconfigurationComplete message to the base station via the U2N relay terminal. The base station also sets up a Uu relay RLC channel between the base station and the U2N relay terminal, and a PC5 relay RLC channel between the U2N relay terminal and the U2N remote terminal for relay traffic.

[0297] 2) Radio Link Failure

[0298] A U2N remote terminal in RRC_CONNECTED ceases Uu RLM when it is connected to a base station via a U2N relay terminal.

[0299] U2N relay terminals declare Radio Link Failure (RLF) according to the same criteria.

[0300] After the RLF is declared, the U2N relay terminal performs the following actions:

[0301] - A PC5-RRC message is used to send an instruction to a U2N remote terminal connected to a U2N relay terminal, which triggers an RRC connection re-establishment for the U2N remote terminal.

[0302] Upon detecting a PC5 RLF, the U2N remote terminal triggers a link re-establishment.

[0303] 3) RRC connection reconfiguration

[0304] The U2N remote terminal performs the following operations during the RRC connection reestablishment procedure:

[0305] If only a suitable cell is available, the U2N remote terminal initiates an RRC re-establishment procedure to a suitable cell.

[0306] - If only a suitable U2N relay terminal is available, the U2N remote terminal initiates an RRC reconfiguration procedure for the serving cell of the suitable relay terminal.

[0307] - If both a suitable cell and a suitable relay are available, the U2N remote terminal selects one of the two to initiate the RRC reconfiguration procedure, depending on the implementation.

[0308] 4) RRC connection resumed

[0309] The RRC connection resumption mechanism is applied to the U2N remote terminal.

[0310] 5) System information

[0311] A U2N remote terminal within the coverage area can obtain all necessary SIBs via the Uu interface regardless of the PC5 connection with the relay terminal. After the PC5 connection with the U2N relay terminal is established, the U2N remote terminal may receive system information from the relay terminal.

[0312] A U2N remote terminal in RRC_CONNECTED can request an SIB from a U2N relay terminal using the on-demand SIB framework. A U2N remote terminal in RRC_IDLE or RRC_INACTIVE can inform the U2N relay terminal of the requested SIB type via a PC5-RRC message. The U2N relay terminal then triggers the on-demand SI / SIB acquisition procedure (if necessary) according to its RRC state and transmits the SI / SIB acquired via PC5-RRC to the U2N remote terminal.

[0313] In RRC_IDLE or RRC_INACTIVE states, the U2N remote terminal can request (from the U2N relay terminal or the network) the SIBs that it uses (e.g., for relay purposes). In the case of an SIB requested by the U2N remote terminal from the U2N relay terminal, the U2N relay terminal retransmits any updates to the requested SIB. In the case of an RRC_CONNECTED U2N remote terminal, it is the network's responsibility to send updated SIBs to the U2N remote terminal in the event of an update. When the U2N remote terminal enters the RRC_CONNECTED state, it deconfigures the SI request with the U2N relay terminal.

[0314] In the case of SIB1 transmission, both requested transmission (i.e., SIB1 request of the U2N remote terminal) and unsolicited transmission to the U2N remote terminal are supported by the U2N relay terminal, and their use depends on the implementation of the U2N relay terminal. When SIB1 is changed, the U2N relay terminal always transmits SIB1 to a U2N remote terminal in RRC_IDLE or RRC_INACTIVE.

[0315] For an L2 U2N remote terminal in RRC_IDLE or RRC_INACTIVE, short messages over the Uu interface are not transmitted from the L2 U2N relay terminal to the L2 U2N remote terminal. The L2 U2N relay terminal can transmit PWS SIBs to the L2 U2N remote terminals connected to it.

[0316] RAN sharing is supported by the L2 U2N relay terminal. In particular, the L2 U2N relay terminal can transmit information about cell access via a discovery message before establishing a PC5-RRC connection.

[0317] 6) The paging

[0318] When both the U2N relay terminal and the U2N remote terminal are in the RRC IDLE or RRC INACTIVE state, the U2N relay terminal monitors the paging occasions of the U2N remote terminal connected thereto. If the U2N relay terminal needs to monitor paging for the U2N remote terminal, the U2N relay terminal must monitor all POs of the U2N remote terminal.

[0319] When the U2N relay terminal is in the RRC CONNECTED state and the U2N remote terminal is in the RRC_IDLE or RRC_INACTIVE state, there are two options for paging transmission.

[0320] - If the CORESET and paging search space are set in the active DL BWP of the U2N relay terminal, the U2N relay terminal monitors the PO of the U2N remote terminal connected to it.

[0321] Paging transmission of a U2N remote terminal can be performed by a dedicated RRC message from a base station to a U2N relay terminal. The dedicated RRC message for transmitting remote terminal paging to an RRC_CONNECTED relay terminal includes one or more remote terminal IDs (5G-S-TMSI or I-RNTI).

[0322] Which of the two options described above is used depends on the network implementation. If a paging search space is configured for a U2N relay terminal in RRC CONNECTED, it can determine whether to monitor PO for the U2N remote terminal based on the PC5-RRC signal received by the U2N remote terminal.

[0323] A U2N remote terminal in RRC_IDLE requests the U2N relay terminal to perform PO monitoring by providing the 5G-S-TMSI and UE-specific DRX period (configured by a higher layer) to the U2N relay terminal. A U2N remote terminal in RRC_INACTIVE provides the U2N relay terminal with the minimum of two UE-specific DRX periods (configured by a higher layer and configured by the RAN), the 5G-S-TMSI, and the I-RNTI for PO monitoring. The L2 U2N relay terminal can inform the base station of the remote terminal information (i.e., 5G-S-TMSI / I-RNTI) via a SidelinkUEInformationNR message for the purpose of paging transmission. The U2N relay terminal receives the paging message, checks the 5G-S-TMSI / I-RNTI, and transmits the associated paging record to the remote terminal accordingly.

[0324] The U2N relay terminal can send pages to the U2N remote terminal via PC5 using unicast signaling.

[0325] 7) Access Control

[0326] The U2N remote terminal performs unified access control (UAC). The RRC-CONNECTED U2N relay terminal does not perform UAC on the data of the U2N remote terminal.

[0327] 8) Mobility Registration Update and RAN Area Update

[0328] When an L2 U2N remote terminal is connected to an L2 U2N relay terminal, it performs a mobility registration update / RNAU based on the serving cell of the L2 U2N relay terminal. An L2 U2N remote terminal in RRC_IDLE or RRC_INACTIVE state initiates a mobility registration update / RNAU procedure when its serving cell changes (due to a cell change by the U2N relay terminal) and the new serving cell is outside the configured RNA / TA of the U2N remote terminal.

[0329] Service continuity for L2 U2N relays

[0330] 1) Switching from indirect to direct pathways

[0331] FIG. 14 shows the procedure for a U2N remote terminal to switch directly to a Uu cell.

[0332] For service continuity of L2 U2N relay, when a U2N remote terminal switches to a direct route, the following procedure is performed.

[0333] 1. The Uu measurement configuration and measurement report signaling procedure is performed to evaluate both relay link measurements and Uu link measurements. When the configured measurement reporting criteria are met, the measurement results of the U2N remote terminal are reported. The SL relay measurement report must include at least the source L2 ID, serving cell ID (i.e., NCGI) and SL measurement information of the U2N relay terminal. The SL measurement is the SL-RSRP of the serving U2N relay terminal, and if SL-RSRP is not available, SD-RSRP is used.

[0334] 2. The base station decides to switch the U2N remote terminal to a direct Uu path.

[0335] 3. The base station sends an RRCReconfiguration message to the U2N remote terminal. After receiving the RRCReconfiguration message from the base station, the U2N remote terminal stops UP and CP transmission by the U2N relay terminal.

[0336] 4. The U2N remote terminal synchronizes with the base station and performs random access.

[0337] 5. The terminal (i.e., the U2N remote terminal in the previous stage) sends RRCReconfigurationComplete to the base station via a direct route using the settings provided in the RRCReconfiguration message. From this stage, the terminal (i.e., the U2N remote terminal in the previous stage) uses an RRC connection via a direct route to the base station.

[0338] 6. The base station sends an RRCReconfiguration message to the U2N relay terminal to reconfigure the connection between the U2N relay terminal and the base station. The RRCReconfiguration message to the U2N relay terminal is sent at any time after step 3 depending on the implementation of the base station (e.g., to release the Uu and PC5 relay RLC channel setup for relay and the bearer mapping setup between the PC5 RLC and Uu RLC).

[0339] 7. The U2N relay terminal or U2N remote terminal initiates PC5 unicast link release (PC5-S). The timing of the link release depends on the implementation of the terminal. The U2N relay terminal performs PC5 connection reconfiguration to release the PC5 relay RLC channel for the relay when the base station receives RRC Reconfiguration in step 6, or the terminal (i.e., the previous U2N remote terminal) performs PC5 connection reconfiguration to release the PC5 relay RLC channel when the base station receives RRC Reconfiguration in step 3.

[0340] 8. The data path is switched from an indirect path to a direct path between the terminal (i.e., the former U2N remote terminal) and the base station. During the path switch, DL / UL lossless transmission is performed according to the PDCP data recovery procedure.

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

[0342] 2) Switching from direct to indirect routes

[0343] FIG. 15 shows the procedure for a U2N remote terminal to switch to an indirect path.

[0344] The base station can select a U2N relay terminal in any RRC state, such as RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED, as a target U2N relay terminal for direct-indirect path switching.

[0345] For service continuity of the L2 U2N remote terminal, when the L2 U2N remote terminal switches to an indirect path via a U2N relay terminal in RRC_CONNECTED, the following procedure is performed.

[0346] 1. After measuring / discovering candidate U2N relay terminals, the U2N remote terminal reports one or more candidate U2N relay terminals and Uu measurements.

[0347] - Before reporting, the terminal can filter suitable U2N relay terminals according to the relay selection criteria. The terminal needs to report only U2N relay terminal candidates that meet the upper layer criteria.

[0348] The report includes at least the U2N relay terminal ID, the serving cell ID of the U2N relay terminal, and SL measurement information. The SL measurement is the SL-RSRP of the candidate U2N relay terminal, and if SL-RSRP is not available, SD-RSRP is used.

[0349] 2. The base station decides to switch the U2N remote terminal to the target U2N relay terminal, and then sends an RRCReconfiguration message to the target U2N relay terminal, which contains at least the remote terminal's local ID and L2 ID, Uu and PC5 relay RLC channel configuration for relaying, and bearer mapping configuration.

[0350] 3. The base station sends an RRCReconfiguration message to the U2N remote terminal. The content of the RRCReconfiguration message includes at least the U2N relay terminal ID, the PC5 relay RLC channel configuration for relay traffic, and the associated end-to-end radio bearer. After receiving the RRCReconfiguration message from the base station, the U2N remote terminal stops UP and CP transmission over Uu.

[0351] 4. The U2N remote terminal establishes a PC5 connection with the target U2N relay terminal.

[0352] 5. The U2N remote terminal sends an RRCReconfigurationComplete message to the base station via the relay terminal to complete the path switching procedure.

[0353] 6. The data path is switched from a direct path to an indirect path between the U2N remote terminal and the base station.

[0354] If the U2N relay terminal selected for direct-indirect path switching is in RRC_IDLE or RRC_INACTIVE, after receiving the path switching command, the U2N remote terminal establishes a PC5 link with the U2N relay terminal and sends an RRCReconfigurationComplete message via the U2N relay terminal. In this case, the U2N relay terminal switches to the RRC_CONNECTED state. In FIG. 15, the U2N remote terminal procedure for switching to an indirect path can also be applied when the U2N relay terminal selected for direct-indirect path switching is in RRC_IDLE or RRC_INACTIVE, but step 4 must be performed before step 2.

[0355] SL Discovery

[0356] A terminal can perform NR SL discovery while in coverage or out of coverage for non-relay operation.

[0357] The relay discovery mechanism (except for U2N relay-specific threshold-based discovery message transmission) also applies to SL discovery.

[0358] Service continuity from direct to indirect paths measured by relays

[0359] 16 and 17 are diagrams illustrating a method of performing handover for direct-indirect path switching or indirect-indirect path switching for a remote terminal.

[0360] According to the prior art, when a relay terminal and a remote terminal are configured with a terminal-to-network relay (U2N relay) function, the relay terminal provides a connection to the network for the U2N remote terminal. In this case, the remote terminal is not directly connected to the network, but maintains an indirect connection through the U2N relay function.

[0361] In U2N operation, the remote terminal performs HO from one indirect path to another indirect path or from a direct path to an indirect path, but the prior art does not provide for inter-gNB handover from a direct / indirect path of a source gNB to an indirect path of a target gNB.

[0362] A method for performing a handover for a direct-to-indirect path switch or an indirect-to-indirect path switch for a remote terminal includes the following steps:

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

[0364] 2. If there is a request from the remote terminal or if the relay terminal supports U2N relaying, the relay terminal informs the remote terminal of the serving cell of the relay terminal via a PC5-RRC message.

[0365] - The PC5-RRC message includes the global cell ID of the serving cell (e.g., the PCell of the relay terminal).

[0366] 3. The relay terminal is configured to perform measurements on the serving cells of the remote terminal and / or relay terminal by the gNB or remote terminal.

[0367] The remote terminal receives a configuration from the gNB, and then configures measurements to be performed by the relay terminal based on the configuration received from the gNB.

[0368] 4. If configured, the relay terminal reports the measurement results on the serving cell of the remote terminal and / or relay terminal to the gNB or remote terminal. The gNB becomes the serving gNB of the relay terminal or the serving gNB of the remote terminal (S162). Such reporting is triggered periodically or by an event (e.g., A1, A2, or A3 event) depending on the configuration.

[0369] A. If the results measured on the serving cell exceed a threshold configured by the remote terminal or gNB (e.g., A1 event), the relay terminal informs the remote terminal about the results measured on the serving cell with the serving cell ID via a PC5-RRC message. The relay terminal can also inform the remote terminal about the results measured on the remote terminal via the same PC5-RRC message.

[0370] B. If the result measured on the remote terminal exceeds a threshold configured by the remote terminal or the gNB, the relay terminal informs the remote terminal about the result measured on the remote terminal by a PC5-RRC message. The relay terminal also informs the remote terminal about the result measured on the relay terminal's serving cell with the serving cell ID by the same PC5-RRC message.

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

[0372] A. The remote terminal reports the results measured on the serving cell of the remote terminal and / or relay terminal to the gNB in the same RRC message.

[0373] B. The remote terminal reports the results measured on the relay terminal and / or the remote terminal's serving cell to the gNB in the same RRC message.

[0374] C. Upon receiving the serving cell of the relay terminal from the relay terminal, the remote terminal measures the serving cell of the relay terminal and then reports the measurement results on the serving cell of the relay terminal to the gNB of the remote terminal via the same RRC message.

[0375] D. The remote terminal reports the results measured on neighboring cells that exceed the threshold in decreasing order to the remote terminal's gNB via the same RRC message.

[0376] 6. Upon receiving the measurement results from the relay terminal, the remote terminal reports the results measured on the relay terminal's serving cell to the remote terminal's gNB.

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

[0378] B. The remote terminal reports the results measured on the relay terminal and / or the remote terminal's serving cell to the gNB in the same RRC message.

[0379] C. Upon receiving the serving cell of the relay terminal from the relay terminal, the remote terminal measures the serving cell of the relay terminal and then reports the measurement results on the serving cell of the relay terminal to the gNB of the remote terminal via the same RRC message.

[0380] D. The remote terminal reports the results measured on neighboring cells that exceed the threshold in decreasing order of the measured results to the remote terminal's gNB via the same RRC message.

[0381] 7. The remote terminal measures the following objectives:

[0382] A. Relay terminal (e.g., SL-RSRP or SD-RSRP)

[0383] B. Adjacent relay stations (e.g., SL-RSRP or SD-RSRP)

[0384] C. Serving cell of relay terminal (e.g., RSRP or RSRQ)

[0385] D. Remote terminal's serving cell (e.g., RSRP or RSRQ)

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

[0387] 8. The remote terminal reports the results measured for any one or more of the following objectives to the gNB, for example, periodically or by an event configured by the gNB:

[0388] A. Top-ranked (neighboring) relay based on measurements

[0389] B. Non-top (neighboring) relays exceeding the threshold in decreasing order of measurement results

[0390] C. Relay Station (e.g., SL-RSRP or SD-RSRP)

[0391] D. Serving cell of relay terminal (e.g., RSRP or RSRQ)

[0392] E. Remote terminal's serving cell (e.g., RSRP or RSRQ)

[0393] F. Neighboring cells of a remote terminal exceeding a threshold in order of decreasing measurement results (e.g., RSRP or RSRQ)

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

[0395] The source gNB determines the target route type (i.e., direct or indirect) for the remote terminal based on the measurement report. For example, the source gNB receives measurements of the remote terminal and / or relay terminal on the serving cell of the relay terminal. The source gNB also receives measurements of the remote terminal on neighboring cells.

[0396] 10. The source gNB informs the target gNB of information about the target relay terminal (e.g., source L2 ID and serving cell ID of the L2 U2N relay terminal) in an XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message (S164).

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

[0398] B. The information in the message includes the relay terminal with the highest ranking in the measurement result and the non-highest ranking relay terminal in decreasing order of the measurement result, or the message includes information about at least one relay terminal and information about the remote terminal.

[0399] C. The information includes measurement results for relay terminals that have SD-RSRP or SL-RSRP. If the relay terminal has established a PC5 unicast link with the remote terminal, the measurement results for the relay terminal are SL-RSRP. Otherwise, the measurement results for any relay terminal are SD-RSRP.

[0400] D. The source gNB of the remote terminal sends an indication to the serving cell of the relay terminal and transmits the measurement report received from the relay terminal.

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

[0402] F. In the case of direct / indirect-indirect handover, additional information from the source gNB to the target gNB may be required. In the case of direct / indirect-indirect handover, the source gNB selects one relay terminal from among the candidate relay terminals. The target gNB is the gNB to which the selected relay terminal belongs. The source gNB sends an XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message to the selected target gNB, including the SRC L2 ID, the serving cell ID of the selected relay terminal, and the context of the connected remote terminal. This is because the target terminal needs to know the relay terminal connected to the remote terminal for handover.

[0403] 11. When the target gNB receives an HO request from the source gNB, i.e., an XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message, it determines the target route type (i.e., direct or indirect) to the remote terminal according to the measurement results of the relay terminal.

[0404] A. The serving gNB determines the target gNB according to the Uu measurement results of the candidate target cells and the SL measurement results of the candidate relay terminals. If the selected target gNB can use a direct Uu link or an indirect link via a relay terminal, it is unclear whether the target gNB can determine the final target route type. We believe that the source gNB or the target gNB can determine the target route type. If the target gNB can determine the target route type, there are several advantages. The target gNB can more appropriately determine the target route type because the target gNB knows the Uu measurement results between the selected relay terminal and the target gNB (if the selected relay terminal is RRC_CONNECTED). If the target gNB can determine the target route type for the remote terminal, the source gNB needs to inform it of the measurement results of the Uu link signal strength (between the remote terminal and the target gNB) and the sidelink signal strength (between the remote terminal and the selected relay terminal).

[0405] B. The source gNB informs the target gNB of the target route type (i.e., direct or indirect) for the remote terminal via the XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message. The source gNB indicates the target route type, or if the source gNB does not indicate the target route type, the target gNB can decide whether to follow the indicated target route type. If the target gNB can determine a target route type different from the target route type indicated by the source gNB, the target gNB informs the source gNB of the target route type (i.e., direct or indirect) for the remote terminal in the next step.

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

[0407] A. The XnAP HANDOVER REQUEST ACKNOWLEDGE message or the NGAP HANDOVER COMMAND message contains the HO command sent to the remote terminal.

[0408] 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).

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

[0410] 14. Upon receiving the HO command to the indirect path by the target relay terminal, if the remote terminal already has a PC5-RRC connection with the target relay terminal, the remote terminal sends an HO complete message to the target gNB via the target relay terminal (S167).

[0411] - Upon receiving an HO command for an indirect path via the target relay terminal, if the remote terminal does not already have a PC5-RRC connection with the target relay terminal, the remote terminal establishes a PC5 unicast link and a PC5-RRC connection with the target relay terminal, and then transmits an HO completion message to the target gNB via the target relay terminal.

[0412] Upon receiving the HO command for the direct route, the remote terminal performs RACH with the target gNB and sends an HO complete message to the target gNB via MSG3 or MSGA.

[0413] By utilizing this invention, a terminal can appropriately perform direct-to-indirect HO or indirect-to-indirect HO according to the invention, especially if the terminal can support U2N relay function by SL.

[0414] The present invention is beneficial in that it allows a system to properly provide HO for indirect paths via U2N relays. The prior art does not have a mechanism for providing HO for indirect paths via sidelink relays.

[0415] Referring to Figure 17, the gNB can determine HO, which is a handover from an indirect (route) to an indirect (route).

[0416] Specifically, the remote terminal establishes a PC5-RRC with the source relay terminal (S171), and then performs a PC5-RRC establishment procedure with the target relay terminal through a discovery procedure (S172).

[0417] The HO from an indirect path to an indirect path (or U2N HO) is determined as follows:

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

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

[0420] When the gNB determines HO, the gNB requests handover to the target relay terminal (S174). Meanwhile, the handover request is performed by a method corresponding to the method shown in FIG. 16.

[0421] The gNB receives a handover request confirmation message from the target relay terminal. Here, the handover request confirmation message further includes information regarding the acceptance or rejection of some U2N bearers (S175). Meanwhile, the message for handover request confirmation is transmitted in a manner corresponding to the method shown in FIG. 16.

[0422] The gNB sends an RRC reconfiguration message to the remote terminal (via a direct route or a meandering route via the source relay terminal) based on the handover request confirmation message received from the target relay terminal (S176). Then, as described above, the remote terminal configures an indirect route with the target terminal relay based on the RRC reconfiguration message and performs an indirect route release procedure with the source relay terminal (S177).

[0423] The following describes in detail how HO is determined by the gNB, relay terminal, or remote terminal.

[0424] A method for transmitting data by a terminal includes the following steps:

[0425] Direct / Indirect - In the case of indirect HO,

[0426] 1. The relay terminal informs the remote terminal of the relay terminal's serving cell ID and the relay terminal's serving cell quality based on the relay terminal's measurements on the relay terminal's serving cell.

[0427] - When a predetermined event (e.g., A1 event) is met, the relay terminal triggers a serving cell quality report of the relay terminal to the remote terminal.

[0428] 2. The remote terminal informs the source gNB (i.e., the remote terminal's serving gNB) of the relay terminal's serving cell quality received from the relay terminal and the remote terminal's serving cell quality based on the remote terminal's measurements on the remote terminal's serving cell.

[0429] 3. The source gNB determines the target relay terminal according to the information received from the remote terminal.

[0430] 4. The source gNB informs the target gNB of information about the target relay terminal (e.g., source L2 ID and serving cell ID of the L2 U2N relay terminal) in an XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message.

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

[0432] - The message information includes the relay terminal with the highest ranking in the measurement result and the non-highest ranking relay terminals in decreasing order of the measurement result.

[0433] - The information includes measurement results for relay terminals with SD-RSRP or SL-RSRP. If the relay terminal establishes a PC5 unicast link with the remote terminal, the measurement result for the relay terminal is SL-RSRP. Otherwise, the measurement result for any relay terminal is SD-RSRP.

[0434] 5. When the target gNB receives an HO request from the source gNB, i.e., an XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message, it determines the target route type (i.e., direct or indirect) to the remote terminal according to the relay terminal measurement results.

[0435] - The source gNB indicates the target route type (i.e., direct or indirect) for the remote terminal to the target gNB via the XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED message. If the source gNB indicates the target route type, or if the source gNB does not indicate the target route type, the target gNB decides whether to follow the indicated target route type. If the target gNB can determine a target route type different from the target route type indicated by the source gNB, the target gNB informs the source gNB of the target route type (i.e., direct or indirect) for the remote terminal in the next step.

[0436] 6. The target gNB informs the source gNB of the target route type (i.e., direct or indirect) to the remote terminal via an XnAP HANDOVER REQUEST ACKNOWLEDGE message or an NGAP HANDOVER COMMAND message.

[0437] In particular, the handover (HO) from the direct path to the indirect path is determined as follows.

[0438] (1) Alternative 1: The S-gNB (source gNB) decides the HO from the direct path to the indirect path.

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

[0440] (2) Alternative 2: The T-gNB (target gNB) determines the HO from the direct path to the indirect path.

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

[0442] (3) Alternative 3: The relay terminal decides the HO from the direct route to the indirect route.

[0443] - The relay terminal can request HO from the T-gNB, in which case the T-gNB can send the HO command without a separate request from the S-gNB.

[0444] - When the T-gNB sends an HO command to the S-gNB, the S-gNB sends an HO command to the remote terminal via the relay terminal.

[0445] (4) Alternative 4: The remote terminal decides the HO from the direct route to the indirect route.

[0446] - The remote terminal requests HO from the direct route to the indirect route to the S-gNB. The request message is sent using sidelink terminal information, etc.

[0447] Alternatively, the HO from an indirect path to an indirect path (or U2N HO) is determined as follows:

[0448] (1) Alternative 1: The gNB (or source gNB) determines the HO from the indirect path to the indirect path.

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

[0450] When the gNB determines HO, the gNB requests handover to the target relay terminal. Meanwhile, the handover request is performed in a manner corresponding to the methods shown in FIGS. 16 and 17.

[0451] The gNB receives a handover request confirmation message from the target relay terminal. Here, the handover request confirmation message may further include information regarding the acceptance or rejection of some U2N bearers. Meanwhile, the message for handover request confirmation is performed in a manner corresponding to the methods shown in FIGS. 16 and 17.

[0452] (2) Alternative 2: The source relay terminal decides the HO from the indirect path to the indirect path.

[0453] - When the remote terminal is connected to the target relay terminal, the remote terminal sends a U2N HO (or HO from an indirect path to an indirect path) request to the source relay terminal. In this case, the remote terminal informs the source relay terminal of information about the target relay terminal. After this, the source relay terminal requests HO from the indirect path to the indirect path to the gNB. Here, the HO request is sent using a Sidelink Terminal Information message.

[0454] (3) Alternative 3: The target relay terminal determines the HO from the indirect route to the indirect route.

[0455] - When the remote terminal is connected to the target relay terminal, the remote terminal requests U2N HO from the target relay terminal. At this time, the remote terminal does not need to inform the target relay terminal of information about the source relay terminal (because the base station already knows information about the source relay terminal). After this, the target relay terminal requests (U2N) HO from the gNB. The HO request is transmitted using a Sidelink UE Information message, etc.

[0456] (4) Alternative 4: The remote terminal determines the HO from an indirect path to an indirect path.

[0457] When the remote terminal is connected to the target relay terminal, the remote terminal requests U2N HO from the gNB (or base station). The request message is sent to the gNB (or base station) using sidelink terminal information, etc. In this case, the remote terminal needs to provide information about the target relay terminal to the gNB (or base station).

[0458] The HO command related to the HO described above is transmitted to the remote terminal in the following manner.

[0459] - The HO command includes the U2N bearer setup.

[0460] - How to send a HO command to a remote terminal:

[0461] -- Alternative 1: The S-gNB transmits directly to the remote terminal (e.g., via a direct route).

[0462] -- Alternative 2: (When there is a PC5-RRC connection) The S-gNB transmits to the remote terminal via the relay terminal.

[0463] - How the remote terminal sends an HO Complete message to the target gNB:

[0464] -- Alternative 1: After the relay terminal performs U2N-related configuration via the RRC reconfiguration sidelink, the relay terminal (or remote terminal) sends a message for RRC reconfiguration completion to the T-gNB.

[0465] -- Alternative 2: Regardless of the RRC reconfiguration sidelink, the relay terminal (or remote terminal) sends a message for RRC reconfiguration completion to the gNB.

[0466] FIG. 18 is a diagram illustrating a method for performing handover for a first terminal by a first network.

[0467] The first terminal supports multiple paths including a direct wireless path directly connected to the network and an indirect wireless path indirectly connected to the network via a relay terminal. In this case, the first network establishes an indirect wireless path with the first terminal or establishes a direct wireless path with the second terminal. Meanwhile, in the following, the first network is a source gNB, the second network is a target gNB, and the first terminal is a remote terminal.

[0468] Referring to FIG. 18, the first network receives measurement information related to the indirect wireless path and / or the direct wireless path from the first terminal (S181).

[0469] Here, the measurement information includes at least one of the following qualities as described above:

[0470] A. Relay terminal (e.g., SL-RSRP or SD-RSRP)

[0471] B. Adjacent relay stations (e.g., SL-RSRP or SD-RSRP)

[0472] C. Serving cell of relay terminal (e.g., RSRP or RSRQ)

[0473] D. Remote terminal's serving cell (e.g., RSRP or RSRQ)

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

[0475] Alternatively, the measurement information includes at least one of the following qualities as described above:

[0476] A. Top-ranked (neighboring) relay based on measurements

[0477] B. Non-top (neighboring) relays exceeding the threshold in decreasing order of measurement results

[0478] C. Relay Station (e.g., SL-RSRP or SD-RSRP)

[0479] D. Serving cell of relay terminal (e.g., RSRP or RSRQ)

[0480] E. Remote terminal's serving cell (e.g., RSRP or RSRQ)

[0481] F. Neighboring cells of a remote terminal exceeding a threshold in order of decreasing measurement results (e.g., RSRP or RSRQ)

[0482] Next, the first network determines a handover (HO) to the second network for either the indirect wireless path or the direct wireless path of the first terminal based on the measurement information (S183). For example, the first network determines a handover (HO) to switch the direct wireless path between the first terminal and the first network to the indirect wireless path between the first terminal and the second network (direct to indirect HO) based on the measurement information. Alternatively, the first network determines a handover (HO) to switch the indirect wireless path between the first terminal and the first network to the indirect wireless path between the first terminal and the second network (indirect to indirect HO) based on the measurement information. That is, the first network determines a handover (HO) to switch the direct wireless path or the indirect wireless path established with the first terminal to the indirect wireless path between the first terminal and the second network based on the measurement information (see Section 10 of FIG. 16).

[0483] Next, the first network transmits a handover request message to the second network to request handover for the first terminal according to the handover decision (S185). Here, the handover request message further includes information about at least one relay terminal forming an indirect wireless path between the second network and the first terminal, or the handover request message further includes identification information for a serving cell associated with the at least one relay terminal. Here, the handover request message is an Xn Application Protocol (XnAP) HANDOVER REQUEST message.

[0484] For example, when switching an indirect wireless path (or a direct wireless path) with the first terminal to an indirect wireless path between the second network and the first terminal, the first network transmits a handover request message including information about at least one relay. Alternatively, the handover request message includes information about at least one relay and the first terminal. Here, the information about the at least one relay is at least one identifier (ID) for the at least one relay terminal and / or the first terminal. When the first network determines a handover from a direct path to a direct path, the first network transmits a handover request message to the second network that does not include information about the at least one relay.

[0485] The first network receives a message (HANDOVER COMMAND message) including a handover command from the second network in response to the handover request message. Here, the HANDOVER COMMAND message includes information about one relay terminal selected by the second network from among at least one relay terminal. The first network transmits an HO command message to the first terminal.

[0486] As described above, the source gNB can provide the target gNB with information about the handover type and the target relay terminal associated with the indirect path in advance via the handover request message. The handover type includes a type of switching from a direct wireless path / indirect wireless path to an indirect wireless path and a type of switching from a direct wireless path / indirect wireless path to a direct wireless path. From the above-described method, it is clear that in a handover between gNBs for multiple paths, the handover method for the multiple paths and information about the target relay terminal for the indirect path are determined by the source gNB.

[0487] That is, if the terminal can support the U2N relay function via SL (sidelink), the first terminal can appropriately perform direct-to-indirect HO or indirect-to-indirect HO. The present invention is beneficial because the system can appropriately apply HO to the indirect path via U2N relay. The prior art does not have a mechanism to provide HO to the indirect path via sidelink relay.

[0488] Without being limited thereto, the various descriptions, functions, procedures, suggestions, methods and / or flow charts of the present invention disclosed in this specification may be applied to various fields requiring wireless communication / connectivity between devices (e.g., 5G).

[0489] Hereinafter, a more detailed description will be given with reference to the drawings. In the following drawings / description, the same reference numerals indicate the same or corresponding hardware blocks, software blocks or function blocks unless otherwise specified.

[0490] FIG. 19 illustrates a communication system to which the present invention can be applied.

[0491] 19, a communication system 1 applied to the present invention includes wireless devices, base stations, and a network. Here, the wireless devices refer to devices that communicate using wireless connection technologies (e.g., 5G NR (New RAT) and LTE (Long Term Evolution)) and are also referred to as communication / wireless / 5G devices. The wireless devices include, but are not limited to, a robot 100a, vehicles 100b-1 and 100b-2, an XR (eXtended Reality) device 100c, a handheld device 100d, a home appliance 100e, an IoT (Internet of Things) device 100f, and an AI device / server 400. For example, the vehicles include vehicles equipped with wireless communication capabilities, autonomous vehicles, vehicles capable of vehicle-to-vehicle communication, etc. Here, the vehicles include unmanned aerial vehicles (UAVs) (e.g., drones). XR devices include Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR) devices, and are embodied in the form of Head-Mounted Devices (HMDs), Head-Up Displays (HUDs) mounted on vehicles, TVs, smartphones, computers, wearable devices, home appliances, digital signage, vehicles, robots, etc. Mobile devices include smartphones, smart pads, wearable devices (e.g., smart watches, smart glasses), computers (e.g., laptops, etc.), etc. Home appliances include TVs, refrigerators, washing machines, etc. IoT devices include sensors, smart meters, etc. For example, base stations and networks may also be embodied as wireless devices, and a specific wireless device 200a may operate as a base station / network node for other wireless devices.

[0492] The wireless devices 100a to 100f are connected to a network 300 via a base station 200. The wireless devices 100a to 100f are equipped with AI (Artificial Intelligence) technology, and are connected to an AI server 400 via the network 300. The network 300 is configured using a 3G network, a 4G (e.g., LTE) network, or a 5G (e.g., NR) network. The wireless devices 100a to 100f can communicate with each other via the base station 200 / network 300, but can also communicate directly without going through the base station / network (e.g., sidelink communication). For example, vehicles 100b-1 and 100b-2 can communicate directly (e.g., V2V (Vehicle to Vehicle) / V2X (Vehicle to Everything) communication). IoT devices (e.g., sensors) can also communicate directly with other IoT devices (e.g., sensors) or other wireless devices 100a to 100f.

[0493] Wireless communication / connections 150a, 150b, and 150c are performed between the wireless devices 100a to 100f and the base stations 200, and between the base stations 200. Here, the wireless communication / connections are performed using various radio access technologies (e.g., 5G NR) such as uplink / downlink communication 150a, sidelink communication 150b (or D2D communication), and inter-base station communication 150c (e.g., relay, Integrated Access Backhaul (IAB)). Through the wireless communication / connections 150a, 150b, and 150c, the wireless devices and the base stations, and the base stations, can transmit / receive wireless signals with each other. For example, the wireless communication / connections 150a, 150b, and 150c can transmit / receive signals via various physical channels. To this end, according to various proposals of the present invention, any one of various configuration information setting processes for transmitting / receiving wireless signals, various signal processing processes (e.g., channel coding / decoding, modulation / demodulation, resource mapping / demapping, etc.), and resource allocation processes is performed.

[0494] FIG. 20 illustrates a wireless device to which the present invention can be applied.

[0495] 20, a first wireless device 100 and a second wireless device 200 transmit and receive wireless signals using various radio access technologies (e.g., LTE, NR), where {first wireless device 100, second wireless device 200} corresponds to {wireless device 100x, base station 200} and / or {wireless device 100x, wireless device 100x} in FIG.

[0496] The first wireless device 100 includes one or more processors 102 and one or more memories 104, and further includes one or more transceivers 106 and / or one or more antennas 108. The processor 102 is configured to control the memory 104 and / or the transceiver 106 to implement the descriptions, functions, procedures, suggestions, methods, and / or flowcharts disclosed herein. For example, the processor 102 processes information in the memory 104 to generate first information / signals and then transmits a wireless signal including the first information / signals via the transceiver 106. The processor 102 also receives a wireless signal including second information / signals via the transceiver 106 and then stores information obtained from signal processing of the second information / signals in the memory 104. The memory 104 is coupled to the processor 102 and stores various information related to the operation of the processor 102. For example, the memory 104 stores software code including instructions for performing some or all of the processes controlled by the processor 102 or for implementing the descriptions, functions, procedures, suggestions, methods, and / or flowcharts disclosed herein. Here, the processor 102 and memory 104 are part of a communication modem / circuit / chip designed to implement a wireless communication technology (e.g., LTE, NR). The transceiver 106 is coupled to the processor 102 and transmits and / or receives wireless signals via one or more antennas 108. The transceiver 106 includes a transmitter and / or a receiver. The transceiver 106 may also be referred to as an RF (radio frequency) unit. In the present invention, a wireless device may also refer to a communication modem / circuit / chip.

[0497] Specifically, the terminal includes a processor 102 coupled to an RF transceiver and a memory 104. The memory 104 may include at least one program for performing operations related to the embodiments described above with reference to Figures 16 to 18. For example, the memory 104 may include at least one program for configuring a first wireless path directly coupled to a network and a second wireless path indirectly coupled to the network via a relay terminal, receiving a Radio Resource Control (RRC) reconfiguration message related to the second wireless path via the first wireless path or the second wireless path, and transmitting a first status report for at least one data unit related to the second wireless path to the network in accordance with the RRC reconfiguration message including information regarding release of the second wireless path or modification of at least one radio bearer related to the second wireless path.

[0498] Alternatively, a chipset may be configured that includes the processor 102 and the memory 104. In this case, the chipset includes at least one processor and at least one memory that is operatively coupled to the at least one processor and that, when executed, causes the at least one processor to operate.

[0499] The second wireless device 200 includes one or more processors 202 and one or more memories 204, and further includes one or more transceivers 206 and / or one or more antennas 208. The processor 202 is configured to control the memory 204 and / or the transceiver 206 to implement the descriptions, functions, procedures, suggestions, methods, and / or flowcharts disclosed herein. For example, the processor 202 processes information in the memory 204 to generate third information / signal, and then transmits a wireless signal including the third information / signal via the transceiver 206. The processor 202 also receives a wireless signal including a fourth information / signal via the transceiver 206, and then stores information obtained from signal processing of the fourth information / signal in the memory 204. The memory 204 is coupled to the processor 202 and stores various information related to the operation of the processor 202. For example, the memory 204 stores software code including instructions for performing some or all of the processes controlled by the processor 202 or for implementing the descriptions, functions, procedures, suggestions, methods, and / or flowcharts disclosed herein. Here, the processor 202 and memory 204 are part of a communication modem / circuit / chip designed to implement a wireless communication technology (e.g., LTE, NR). The transceiver 206 is coupled to the processor 202 and transmits and / or receives wireless signals via one or more antennas 208. The transceiver 206 includes a transmitter and / or a receiver. The transceiver 206 may also be referred to as an RF unit. In the present invention, wireless equipment also refers to a communication modem / circuit / chip.

[0500] The hardware elements of the wireless devices 100, 200 are described in more detail below. Without limitation, one or more protocol layers may be implemented by one or more processors 102, 202. For example, one or more processors 102, 202 may implement one or more layers (e.g., functional layers such as PHY, MAC, RLC, PDCP, RRC, and SDAP). The one or more processors 102, 202 may generate one or more Protocol Data Units (PDUs) and / or one or more Service Data Units (SDUs) according to the descriptions, functions, procedures, suggestions, methods, and / or flowcharts disclosed herein. The one or more processors 102, 202 may generate messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods, and / or flowcharts disclosed herein. The one or more processors 102, 202 generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information according to the functions, procedures, suggestions, and / or methods disclosed herein and provide them to the one or more transceivers 106, 206. The one or more processors 102, 202 receive signals (e.g., baseband signals) from the one or more transceivers 106, 206 and derive the PDUs, SDUs, messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods, and / or flowcharts disclosed herein.

[0501] The one or more processors 102, 202 may also be referred to as a controller, microcontroller, microprocessor, or microcomputer. The one or more processors 102, 202 may be implemented using hardware, firmware, software, or a combination thereof. For example, the one or more processors 102, 202 may include 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). The descriptions, functions, procedures, suggestions, methods, and / or flowcharts disclosed herein may be implemented using firmware or software, and the firmware or software may be embodied to include modules, procedures, functions, etc. Firmware or software configured to perform the descriptions, functions, procedures, suggestions, methods, and / or flowcharts disclosed herein may be included in the one or more processors 102, 202 or may be stored in one or more memories 104, 204 and executed by the one or more processors 102, 202. The descriptions, functions, procedures, suggestions, methods and / or flow charts disclosed in this specification may be embodied using firmware or software in the form of code, instructions and / or sets of instructions.

[0502] The one or more memories 104, 204 may be coupled to the one or more processors 102, 202 and may store various types of data, signals, messages, information, programs, code, instructions, and / or commands. The one or more memories 104, 204 may be comprised of ROM, RAM, EPROM, flash memory, hard drives, registers, cache memory, computer-readable storage media, and / or combinations thereof. The one or more memories 104, 204 may be located internal and / or external to the one or more processors 102, 202. Additionally, the one or more memories 104, 204 may be coupled to the one or more processors 102, 202 via various techniques, such as wired or wireless connections.

[0503] One or more transceivers 106, 206 transmit user data, control information, wireless signals / channels, etc., as referenced in the methods and / or flowcharts herein to one or more other devices. One or more transceivers 106, 206 receive user data, control information, wireless signals / channels, etc., as referenced in the descriptions, functions, procedures, suggestions, methods and / or flowcharts herein from one or more other devices. For example, one or more transceivers 106, 206 are coupled to one or more processors 102, 202 to transmit and receive wireless signals. For example, one or more processors 102, 202 control one or more transceivers 106, 206 to transmit user data, control information, or wireless signals to one or more other devices. Also, one or more processors 102, 202 control one or more transceivers 106, 206 to receive user data, control information, or wireless signals from one or more other devices. One or more transceivers 106, 206 are coupled to one or more antennas 108, 208, and are configured to transmit and receive user data, control information, radio signals / channels, etc., as referred to in the descriptions, functions, procedures, suggestions, methods, and / or flowcharts disclosed herein via the one or more antennas 108, 208. In this specification, one or more antennas may refer to multiple physical antennas or multiple logical antennas (e.g., antenna ports). The one or more transceivers 106, 206 convert the received user data, control information, radio signals / channels, etc., from RF band signals to baseband signals for processing by one or more processors 102, 202. The one or more transceivers 106, 206 convert the user data, control information, radio signals / channels, etc., processed by one or more processors 102, 202, from baseband signals to RF band signals. For this purpose, the one or more transceivers 106, 206 include (analog) oscillators and / or filters.

[0504] 21 illustrates another example of a wireless device to which the present invention is applied. The wireless device can be embodied in various forms depending on the use case / service (see FIG. 19).

[0505] 21, wireless devices 100 and 200 correspond to the wireless devices 100 and 200 of FIG. 20 and are composed of various elements, components, units / components, and / or modules. For example, the wireless devices 100 and 200 include a communication unit 110, a control unit 120, a memory unit 130, and an additional element 140. The communication unit includes a communication circuit 112 and a transceiver 114. For example, the communication circuit 112 includes one or more processors 102 and 202 and / or one or more memories 104 and 204 of FIG. 20. For example, the transceiver 114 includes one or more transceivers 106 and 206 and / or one or more antennas 108 and 208 of FIG. 20. The control unit 120 is electrically coupled to the communication unit 110, the memory unit 130, and the additional element 140 and controls the overall operation of the wireless device. For example, the control unit 120 controls the electrical and mechanical operations of the wireless device based on programs, codes, instructions, and information stored in the memory unit 130. The control unit 120 also transmits information stored in the memory unit 130 to the outside (e.g., other communication device) via the wireless / wired interface via the communication unit 110, or stores information received from the outside (e.g., other communication device) via the wireless / wired interface via the communication unit 110 in the memory unit 130.

[0506] The additional element 140 may be configured in various ways depending on the type of wireless device. For example, the additional element 140 may include any of a power unit / battery, an input / output unit (I / O unit), a driving unit, and a computer unit. Wireless devices may be embodied in the form of, but are not limited to, a robot (FIG. 19, 100a), a vehicle (FIG. 19, 100b-1, 100b-2), an XR device (FIG. 19, 100c), a mobile device (FIG. 19, 100d), a home appliance (FIG. 19, 100e), an IoT device (FIG. 19, 100f), a digital broadcasting terminal, a hologram device, a public safety device, an MTC device, a medical device, a FinTech device (or financial device), a security device, a climate / environment device, an AI server / device (FIG. 19, 400), a base station (FIG. 19, 200), a network node, etc. Wireless devices may be mobile or fixed depending on the use case / service.

[0507] 21, various elements, components, units / sections, and / or modules in the wireless devices 100 and 200 are all connected to each other via a wired interface, or at least some are connected wirelessly via the communication unit 110. For example, in the wireless devices 100 and 200, the control unit 120 and the communication unit 110 are connected via a wire, and the control unit 120 and a first unit (e.g., 130, 140) are connected wirelessly via the communication unit 110. Each element, component, unit / section, and / or module in the wireless devices 100 and 200 further includes one or more elements. For example, the control unit 120 is configured with a set of one or more processors. For example, the control unit 120 is configured with a set of a communication control processor, an application processor, an ECU (Electronic Control Unit), a graphics processor, a memory control processor, etc. As another example, the memory unit 130 may be composed of a random access memory (RAM), a dynamic RAM (DRAM), a read only memory (ROM), a flash memory, a volatile memory, a non-volatile memory, and / or a combination thereof.

[0508] 22 illustrates an example of a vehicle or an autonomous vehicle to which the present invention is applied. The vehicle or the autonomous vehicle may be embodied as a mobile robot, a car, a train, an aerial vehicle (AV), a ship, or the like.

[0509] 22, a vehicle or autonomous vehicle 100 includes 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 is configured as part of the communication unit 110. Blocks 110 / 130 / 140a to 140d correspond to blocks 110 / 130 / 140 in FIG. 21, respectively.

[0510] The communication unit 110 transmits and receives signals (e.g., data, control signals, etc.) to and from external devices such as other vehicles, base stations (e.g., base stations, roadside units, etc.), and servers. The control unit 120 controls elements of the vehicle or autonomous vehicle 100 to perform various operations. The control unit 120 includes an ECU (Electronic Control Unit). The driving unit 140a causes the vehicle or autonomous vehicle 100 to move on the ground. The driving unit 140a includes an engine, a motor, a powertrain, wheels, brakes, a steering device, etc. The power supply unit 140b supplies power to the vehicle or autonomous vehicle 100 and includes wired / wireless charging circuits, a battery, etc. The sensor unit 140c can obtain vehicle status, surrounding environment information, user information, etc. The sensor unit 140c includes an IMU (inertial measurement unit) sensor, a collision sensor, a wheel sensor, a speed sensor, an inclination sensor, a weight detection 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 illuminance sensor, a pedal position sensor, etc. The autonomous driving unit 140d implements technologies such as lane maintenance while driving, technology for automatically adjusting speed such as adaptive cruise control, technology for automatically driving along a predetermined route, and technology for automatically setting a route and driving when a destination is set.

[0511] For example, the communication unit 110 receives map data, traffic information data, etc. from an external server. The autonomous driving unit 140d generates an autonomous driving route and a driving plan based on the obtained data. The control unit 120 controls the driving unit 140a (e.g., adjusting speed / direction) so that the vehicle or autonomous vehicle 100 moves along the autonomous driving route according to the driving plan. The communication unit 110 aperiodically obtains the latest traffic information data from an external server during autonomous driving and also obtains surrounding traffic information data from surrounding vehicles. In addition, the sensor unit 140c obtains vehicle status and surrounding environment information during autonomous driving. The autonomous driving unit 140d updates the autonomous driving route and driving plan based on the newly obtained data / information. The communication unit 110 transmits information regarding the vehicle position, autonomous driving route, driving plan, etc. to an external server. The external server can predict traffic information data using AI technology based on information collected from the vehicle or autonomous vehicle and provide the predicted traffic information data to the vehicle or autonomous vehicle.

[0512] Here, the wireless communication technology implemented in the wireless device (XXX, YYY) of this specification includes not only LTE, NR, and 6G, but also Narrowband Internet of Things for low-power communication. Here, for example, NB-IoT technology is an example of Low Power Wide Area Network (LPWAN) technology and may be embodied in standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the above-mentioned names. Additionally or alternatively, the wireless communication technology implemented in the wireless device (XXX, YYY) of this specification communicates based on LTE-M technology. Here, for example, LTE-M technology is an example of LPWAN technology and may also be referred to by various names such as enhanced Machine Type Communication (eMTC). For example, LTE-M technology may be embodied in any of various standards such as 1) LTE CAT0, 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-mentioned names. Additionally or alternatively, the wireless communication technology implemented in the wireless device (XXX, YYY) of this specification may include, but is not limited to, any of ZigBee, Bluetooth, and Low Power Wide Area Network (LPWAN), which are considered to be low-power communications. For example, ZigBee technology creates personal area networks (PANs) related to small / low-power digital communications based on various standards such as IEEE 802.15.4, and is referred to by various names.

[0513] The above-described embodiments combine the elements and features of the present invention in a predetermined form. Each element or feature is considered optional unless otherwise explicitly stated. Each element or feature may be implemented without being combined with other elements or features, or some elements and / or features may be combined to form an embodiment of the present invention. The order of operations described in the embodiments of the present invention may be changed. Some elements or features of one embodiment may be included in another embodiment, or may be replaced by corresponding elements or features of another embodiment. It is clear that claims that are not explicitly cited in the claims may be combined to form an embodiment, or may be included as new claims by amendment after filing.

[0514] In this specification, the embodiments of the present invention are mainly described with a focus on the signal transmission / reception relationship between a terminal and a base station. This transmission / reception relationship can be similarly / identically extended to signal transmission / reception between a terminal and a relay or between a base station and a relay. A specific operation described herein as being performed by a base station may also be performed by its upper node in some cases. That is, it is clear that various operations performed for communication with a terminal in a network consisting of multiple network nodes including a base station may be performed by a base station or a network node other than a base station. A base station may also be referred to as a fixed station, Node B, eNode B (eNB), access point, etc. Furthermore, a terminal may also be referred to as a UE (User Equipment), MS (Mobile Station), MSS (Mobile Subscriber Station), etc.

[0515] An embodiment of the present invention may be implemented in various ways, such as hardware, firmware, software, or a combination thereof. In a hardware implementation, an embodiment of the present invention may be implemented as 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.

[0516] In the case of a firmware or software implementation, an embodiment of the present invention may be implemented in the form of modules, procedures, or functions that perform the functions or operations described above. The software code is stored in a memory and is driven by a processor. The memory unit may be located inside or outside the processor and may exchange data with the processor by various known means.

[0517] It is obvious to those skilled in the art that the present invention can be embodied in other specific forms without departing from the characteristics of the present invention. Therefore, the above detailed description should not be construed as limiting in all respects, but should be considered as illustrative. The scope of the present invention should be determined by reasonable interpretation of the appended claims, and all modifications within the equivalent scope of the present invention are included in the scope of the present invention. [Industrial Applicability]

[0518] The present invention can be applied to a terminal, a base station, or other devices in a wireless mobile communication system.

Claims

1. 1. A method of communicating over a first network in a wireless communication system, comprising: receiving measurement information from a first terminal (UE, user equipment) comprising at least one of a direct wireless path directly connected to the first network and an indirect wireless path indirectly connected to the first network via a relay terminal; determining a handover to a second network for the first terminal based on the measurement information; and 1. A method of communicating by a first network in a wireless communication system, comprising: transmitting a handover request message to the second network, the handover request message including information about at least one relay terminal associated with an indirect wireless path between the second network and the first terminal.

2. 10. The method of communicating with a first network in a wireless communication system of claim 1, comprising receiving a HANDOVER COMMAND message from the second network.

3. 2. The method of communicating with a first network in a wireless communication system according to claim 1, wherein the handover command message includes information about a selected one of the at least one relay terminal.

4. 2. The method of communicating by a first network in a wireless communication system according to claim 1, wherein the first network determines whether the handover request message includes a target cell of the second network for handing over to a direct path between the second network and the first terminal, or includes the at least one relay terminal for handing over to the indirect wireless path via a relay terminal between the second network and the first terminal.

5. 2. The method of communicating with a first network in a wireless communication system of claim 1, wherein the handover request message is an Xn Application Protocol (XnAP) HANDOVER REQUEST message.

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

7. 2. The method of communicating with a first network in a wireless communication system according to claim 1, wherein the information about the at least one relay terminal is at least one identifier (ID) for the at least one relay terminal.

8. 2. The method of communicating by a first network in a wireless communication system according to claim 1, wherein the measurement information includes at least one of a quality of the relay terminal, a quality of a neighboring relay terminal, a quality of a serving cell of the relay terminal, a quality of a neighboring cell of the first terminal, and a quality of a serving cell of the first terminal.

9. 9. The method of communicating with a first network in a wireless communication system according to claim 8, wherein the quality is Reference Signals Received Power (RSRP) or Reference Signal Received Quality (RSRQ).

10. A computer readable medium storing a program for performing the method of claim 1.

11. 1. A first apparatus for wireless communication, comprising: a memory configured to store instructions; and a processor configured to execute the instructions to perform the operations; The actions performed by the processor include: receiving measurement information from a first terminal (UE, user equipment) comprising at least one of a direct wireless path directly connected to a first network and an indirect wireless path indirectly connected to the first network via a relay terminal; determining a handover to a second network for the first terminal based on the measurement information; and A first apparatus for wireless communication, comprising an operation of transmitting a handover request message to the second network, the handover request message including information regarding at least one relay terminal associated with an indirect wireless path between the second network and the first terminal.

12. The first terminal for wireless communication according to claim 11, wherein the device is an ASIC (Application-Specific Integrated Circuit) or a digital signal processor.

13. The first terminal for wireless communication according to claim 11, wherein the device is a first network operating in a 3GPP (3rd generation partnership project) based wireless communication system.

14. 1. A method for communicating over a second network in a wireless communication system, comprising: receiving a handover request message for a first terminal (UE, user equipment) from a first network, the handover request message including information about at least one relay terminal for configuring an indirect wireless path between the second network and the first terminal; selecting one relay terminal from the at least one relay terminal included in the handover request message; and A method of communicating with a second network in a wireless communication system, comprising: transmitting a handover command to the first network, the handover command including information about the selected one relay terminal.

15. a second network for wireless communication, a transceiver, and a processor configured to control the transceiver; The processor: receiving a handover request message for a first terminal (UE, user equipment) from a first network, the handover request message including information about at least one relay terminal for configuring an indirect wireless path between the second network and the first terminal; selecting one relay terminal from the at least one relay terminal included in the handover request message; A second network for wireless communication configured to send a handover command to the first network, the handover command including information about the selected one relay terminal.

Images