Method and apparatus for estimating location of user equipment in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rate. The present disclosure relates to positioning of a user equipment in a wireless communication system and, more particularly, to a method and an apparatus for servicing positioning of the user equipment, which operates as a L2 UE-to-network remote UE.

Description

Method and device for estimating the location of a terminal in a wireless communication system

[0001] The present disclosure relates to positioning of a terminal in a wireless communication or mobile communication system. More specifically, the present disclosure relates to a method and device for providing positioning services to a terminal operating as an L2 (layer 2) UE (user equipment)-to-Network Remote UE.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in the sub-6GHz frequency band such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (mmWave) such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz (THz) band (for example, 3 THz band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low latency time that is reduced to one-tenth.

[0003] In the early stages of 5G mobile communication technology, the goal is to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). These include beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2). Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing.

[0004] Currently, discussions are underway to improve and enhance the initial 5G mobile communication technology in consideration of the services that 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning.

[0005] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0006] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.

[0008] Based on the discussion described above, the present disclosure provides a device and method capable of effectively providing a service in a wireless communication system.

[0009] The present disclosure, which aims to solve the above-described problem, is characterized by a method of operating a relay node in a wireless communication system, comprising the steps of: receiving a request for position estimation from a first node; transmitting, to the first node, setting information related to position estimation received from a second node based on the request; receiving, from the first node, a request for time synchronization information based on the setting information; and transmitting, to the first node, setting information including the time synchronization information.

[0010] The present disclosure provides a device and method capable of effectively providing a service in a wireless communication system.

[0011] FIG. 1 is a diagram illustrating the structure of an NR system according to one embodiment of the present disclosure.

[0012] FIG. 2 is a diagram illustrating a wireless protocol structure in an LTE and NR system according to one embodiment of the present disclosure.

[0013] FIG. 3 is a diagram illustrating a network structure for providing a terminal location estimation service (hereinafter referred to as LCS) according to one embodiment of the present disclosure.

[0014] FIG. 4 is a flowchart of a process for performing LCS according to one embodiment of the present disclosure.

[0015] FIG. 5 is a flowchart of an exchange process of an LPP (LTE Positioning Protocol) message according to one embodiment of the present disclosure.

[0016] FIG. 6 is a diagram illustrating a location estimation service scenario for an L2 (layer 2) UE (user equipment)-to-Network remote UE according to one embodiment of the present disclosure.

[0017] FIG. 7 is a flowchart of an exchange process of LPP messages for location estimation of an L2 UE-to-Network remote UE according to one embodiment of the present disclosure.

[0018] FIG. 8 is a flowchart of a process in which an L2 UE-to-Network remote UE receives auxiliary information necessary for location estimation in an RRC (radio resource control)_IDLE / RRC_INACTIVE state according to one embodiment of the present disclosure.

[0019] FIG. 9 is a flowchart of a process in which an L2 UE-to-Network remote UE receives auxiliary information necessary for location estimation in an RRC _CONNECTED state according to one embodiment of the present disclosure.

[0020] FIG. 10 is a diagram illustrating a terminal device according to one embodiment of the present disclosure.

[0021] FIG. 11 is a diagram illustrating a base station device according to one embodiment of the present disclosure.

[0022] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings. Furthermore, detailed descriptions of related known functions or configurations will be omitted if they are deemed to unnecessarily obscure the gist of the present disclosure. Furthermore, the terms described below are defined based on their functions in the present disclosure and may vary depending on the intent or custom of the user or operator. Therefore, their definitions should be based on the overall content of this specification.

[0023] The advantages and features of the present disclosure, and methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided solely to ensure that the disclosure of the present disclosure is complete and to fully inform those skilled in the art of the scope of the invention, and the present disclosure is defined only by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

[0024] At this time, it will be understood that each block of the processing flowchart drawings and combinations of the flowchart drawings can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flowchart block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).

[0025] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0026] Here, the term '~ part' used in this embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and the '~ part' performs certain roles. However, the '~ part' is not limited to software or hardware. The '~ part' may be configured to be on an addressable storage medium or may be configured to play one or more processors. Therefore, as an example, the '~ part' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and '~ parts' may be combined into a smaller number of components and '~ parts' or further separated into additional components and '~ parts'. Additionally, the components and '~parts' may be implemented to activate one or more CPUs within a device or secure multimedia card. In addition, in an embodiment, the '~parts' may include one or more processors.

[0027] In the following description of the present disclosure, detailed descriptions of related known functions or configurations will be omitted if they are deemed to unnecessarily obscure the gist of the present disclosure. Hereinafter, embodiments of the present disclosure will be described with reference to the attached drawings.

[0028] The terms used in the following description to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, etc. are provided as examples for convenience of explanation. Therefore, the present disclosure is not limited to the terms described below, and other terms referring to objects with equivalent technical meanings may be used.

[0029] In the following description, the terms "physical channel" and "signal" may be used interchangeably with data or control signals. For example, while PDSCH (physical downlink shared channel) refers to a physical channel through which data is transmitted, PDSCH can also be used to refer to data. That is, in the present disclosure, the expression "transmitting a physical channel" can be interpreted equivalently to the expression "transmitting data or a signal through a physical channel."

[0030] Hereinafter, in the present disclosure, upper signaling refers to a signal transmission method in which a base station transmits a signal to a terminal using a downlink data channel of the physical layer, or a terminal transmits a signal to a base station using an uplink data channel of the physical layer. Upper signaling can be understood as radio resource control (RRC) signaling or a media access control (MAC) control element (CE).

[0031] For the convenience of explanation below, this disclosure uses terms and names defined in the 3rd Generation Partnership Project NR (New Radio) or 3rd Generation Partnership Project Long Term Evolution (LTE) standards. However, this disclosure is not limited by the above terms and names, and can be equally applied to systems conforming to other standards. In this disclosure, gNB may be used interchangeably with eNB for the convenience of explanation. That is, a base station described as an eNB may represent a gNB. In addition, the term terminal may represent not only a mobile phone, an MTC device, an NB-IoT device, a sensor, but also other wireless communication devices.

[0032] Hereinafter, the base station is an entity that performs resource allocation of a terminal, and may be at least one of a gNodeB (gNB), an eNode B (eNB), a NodeB, a BS (Base Station), a wireless access unit, a base station controller, or a node on a network. The terminal may include a UE (User Equipment), an MS (Mobile Station), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing a communication function. Of course, the present invention is not limited to the above examples.

[0033] FIG. 1 is a diagram illustrating the structure of an NR system according to one embodiment of the present disclosure.

[0034] Referring to FIG. 1, a wireless communication system may be composed of multiple base stations (e.g., gNB (105), ng-eNB (110), ng-eNB (115), gNB (120)), an Access and Mobility Management Function (AMF) (125), and a User Plane Function (UPF) (130). A user equipment (hereinafter referred to as UE or terminal) (135) may access an external network through the base stations (e.g., gNB (105), ng-eNB (110), ng-eNB (115), gNB (120)) and the UPF (130).

[0035] In Fig. 1, base stations (e.g., gNB (105), ng-eNB (110), ng-eNB (115), gNB (120)) can provide wireless access to terminals accessing the network as access nodes of a cellular network. That is, base stations (e.g., gNB (105), ng-eNB (110), ng-eNB (115), gNB (120)) can collect status information such as buffer status, available transmission power status, and channel status of terminals to schedule and support connection between terminals and a core network (CN; in particular, the CN of NR is referred to as 5GC) in order to service user traffic. Meanwhile, a user plane (UP) related to transmission of actual user data in communication and a control plane (CP) such as connection management can be configured separately. In Fig. 1, gNB (105) and gNB (120) use UP and CP technologies defined in NR technology, and ng-eNB (110) and ng-eNB (115) can use UP and CP technologies defined in LTE technology even though they are connected to 5GC.

[0036] AMF (125) is a device that handles various control functions as well as mobility management functions for terminals and is connected to multiple base stations, and UPF (130) may refer to a type of gateway device that provides data transmission. Although not illustrated in Fig. 1, the NR wireless communication system may also include a Session Management Function (SMF). The SMF can manage packet data network connections, such as PDU (protocol data unit) sessions provided to terminals.

[0037] FIG. 2 is a diagram illustrating a wireless protocol structure in an LTE and NR system according to one embodiment of the present disclosure.

[0038] Referring to FIG. 2, the wireless protocol of the LTE system may be composed of Packet Data Convergence Protocol (PDCP) (205)(240), Radio Link Control (RLC) (210)(235), and Medium Access Control (MAC) (215)(230) in the terminal and the eNB, respectively. Packet Data Convergence Protocol (PDCP) (205)(240) is responsible for operations such as IP header compression / reconstruction, and Radio Link Control (RLC, hereinafter referred to as RLC) (210)(235) reconfigures PDCP Protocol Data Unit (PDU) to an appropriate size. MAC (215)(230) is connected to multiple RLC layer devices configured in one terminal, and multiplexes RLC PDUs into MAC PDUs and demultiplexes RLC PDUs from MAC PDUs. The physical (PHY) layer (220)(225) performs an operation of channel coding and modulating upper layer data, converting it into OFDM symbols and transmitting it through a wireless channel, or demodulating and channel decoding OFDM symbols received through a wireless channel and transmitting them to a higher layer. In addition, the physical layer also uses HARQ (Hybrid ARQ) for additional error correction, and the receiver transmits 1 bit to indicate whether a packet transmitted by the transmitter was received. This is called HARQ ACK / NACK information. Downlink HARQ ACK / NACK information for uplink data transmission is transmitted through the PHICH (Physical Hybrid-ARQ Indicator Channel) physical channel in the case of LTE, and in the case of NR, it can be determined through the PDCCH (Physical Dedicated Control CHannel), which is a channel through which downlink / uplink resource allocation, etc. are transmitted, whether retransmission is necessary or whether new transmission can be performed, through the scheduling information of the corresponding terminal. This is because NR applies asynchronous HARQ.Uplink HARQ ACK / NACK information for downlink data transmission can be transmitted via the Physical Uplink Control Channel (PUCCH) or Physical Uplink Shared Channel (PUSCH) physical channel. PUCCH is generally transmitted in the uplink of the PCell, which will be described later, but the base station may additionally transmit it to the SCell, which will be described later, if the terminal supports it. This is called the PUCCH SCell.

[0039] Although not shown in Figure 2, an RRC (Radio Resource Control) layer exists above the PDCP layer of each terminal and base station, and the RRC layer can exchange connection and measurement-related setting control messages for radio resource control.

[0040] Meanwhile, the PHY layer can be composed of one or more frequencies / carriers. The technology that sets and uses multiple frequencies simultaneously is called carrier aggregation (CA). Using CA, instead of using only one carrier for communication between a terminal (or User Equipment, UE) and a base station (E-UTRAN NodeB, eNB), the transmission capacity can be dramatically increased by the number of secondary carriers by additionally using the primary carrier and one or more secondary carriers. Meanwhile, in LTE, a cell within a base station that uses a primary carrier is called a primary cell or PCell (Primary Cell), and a cell within a base station that uses a secondary carrier is called a subcell or SCell (Secondary Cell).

[0041] FIG. 3 is a diagram illustrating a network structure for providing terminal location estimation services (hereinafter referred to as LCS) in a wireless communication system (or mobile communication system) according to one embodiment of the present disclosure.

[0042] Referring to FIG. 3, a network for providing LCS in a wireless communication system (or mobile communication system) comprises a terminal (300), a base station (NG-RAN Node) (305), an AMF (Access and Mobility Function 310), and an LMF (Location Management Function 315). At this time, the user terminal (300) communicates with the LMF (315) via the base station (305) and the AMF (310), and can exchange information necessary for location estimation. The roles of each component for providing LCS are as follows.

[0043] The terminal (UE) (300) can measure a wireless signal required for location estimation and transmit the result to the LMF (315).

[0044] The base station (305) can perform a role such as transmitting a downlink wireless signal required for location estimation and measuring an uplink wireless signal transmitted by a target terminal.

[0045] After receiving an LCS Request message from an LCS requester, the AMF (310) can forward it to the LMF (315) to instruct the provision of a location provision service. After the LMF (315) processes the location estimation request and responds with the location estimation result of the terminal, the AMF (310) can forward the result to the LCS requester.

[0046] The LMF (315) is a device that receives and processes the LCS Request from the AMF (310), and can play a role in controlling the overall process required for position estimation. In order to estimate the terminal position, the LMF (315) can provide the terminal (300) with auxiliary information necessary for position estimation and signal measurement and receive the result value. At this time, the LTE Positioning Protocol (LPP) can be used as a protocol for data exchange. The LPP can define the message specifications exchanged between the terminal (300) and the LMF (315) for the position estimation service. In addition, the LMF (315) can exchange downlink reference signal (Positioning Reference Signal, hereinafter referred to as PRS) setting information and uplink reference signal (Sounding Reference Signal, hereinafter referred to as SRS) measurement results to be used for position estimation with the base station (305). At this time, NRPPa (NR Positioning Protocol A) may be used as a protocol for data exchange, and NRPPa may define a message standard exchanged between the base station (305) and the LMF (315). Hereinafter, in the embodiments of the present disclosure, a terminal may be used with the same meaning as UE, and a base station (NG-RAN Node) may mean at least one of a gNB or an eNB.

[0047] FIG. 4 is a flowchart of a process for performing LCS according to one embodiment of the present disclosure.

[0048] Referring to FIG. 4, in steps 420a to 420c, AMF (405) can receive LCS Requests (420a / b / c) from Other LCS Client (410) and UE (400), respectively.

[0049] At step 425, AMF (405) can forward LCS Request (420a / b / c) to LMF (407).

[0050] In steps 430 and 435, the LMF (407) can control the process of exchanging necessary information with a terminal (e.g., UE (400)) and a base station (e.g., NG-RAN Node (403)) to process the LCS Reqeust (420a / b / c).

[0051] In step 440, LMF (407) can transmit the result values ​​(e.g., position estimation results) obtained in steps 430 and 435 to AMF (405).

[0052] In steps 445a to 445c, LCS execution can be completed by AMF (405) transmitting a result value (e.g., LCS Response (445a / b / c)) to the target that requested LCS.

[0053] Specifically, there may be three types of LCS Requests received by AMF (405) at step 420.

[0054] 1. LCS Request (420a) received from an external LCS Client (410)

[0055] 2. LCS Request (420b) generated by AMF (405) itself

[0056] 3. LCS Request (420c) received from UE (400)

[0057] The LCS Request may include at least one of the ID (identity) of the LCS target terminal or LCS QoS (Quality of Service) request information (e.g., including at least one of requirements for position estimation accuracy or delay time).

[0058] After receiving one of the three types of LCS Request, the AMF (405) can request the provision of a location estimation service by transmitting a Location Service Request message (step 425) to the LMF (407). Thereafter, in the NG-RAN Node Procedure step (step 430), the LMF (407) can perform a procedure necessary for location estimation (e.g., including at least one of base station PRS configuration or base station SRS measurement information acquisition) through an NRPPa message exchange with the NG-RAN Node (403). In addition, in the UE Procedure step (step 435), the LMF (407) can exchange an LPP message to exchange necessary information with the UE (400). Through the UE Procedure step (step 435), the LMF (407) can perform at least one procedure of exchanging UE Capability information related to location estimation, transmitting auxiliary information for signal measurement of the UE, or requesting and acquiring a UE measurement result. When the estimated location of the terminal is determined based on multiple measurement results acquired by the LMF (407), the LMF (407) can transmit a Location Service Response message to the AMF (405) (step 440). The AMF (405) can transmit an LCS Response message (445a / b / c) to the target that requested the LCS, and the LCS Response message (445a / b / c) can include the terminal location estimation result.

[0059] FIG. 5 is a flowchart of an LPP (LTE Positioning Protocol) message exchange process according to one embodiment of the present disclosure.

[0060] Referring to FIG. 5, a specific LPP message exchange procedure in the UE Procedure step (i.e., step 435) illustrated in FIG. 4 can be described. The process in which the LMF (505) exchanges terminal capability (hereinafter referred to as “UE Capability”) information related to position estimation with the terminal (500), transmits auxiliary information for terminal signal measurement, and requests and acquires terminal measurement results is illustrated. The purposes and definitions of each LPP message exchanged in each step may be as follows. Of course, the present invention is not limited to the examples below.

[0061] LPP Request Capabilities (LMF → UE, 110): The LPP Request Capabilities message can be used by the LMF (505) to request UE Capability information related to position estimation from the terminal (500). The information included in the LPP Request Capabilities message can be defined as shown in Table 1 below. Requests for common information regardless of the position estimation method (e.g., GNSS, OTDOA, or ECID) can be included in CommonIEsRequestCapabilities. Additionally, requests for additional information required for each position estimation method can be included in a separate IE (Information Element) for each method.

[0062]

[0063] LPP Provide Capabilities (UE → LMF, 115): The LPP Provide Capabilities message can be used by the terminal (500) to transmit UE capability information requested from the LMF (505). Information included in the LPP Provide Capabilities message can be defined as shown in Table 2 below. Similar to the LPP Request Capabilities message, common information regardless of the location estimation method can be included in commonIEsProvideCapabilities. Additionally, information requested for each location tracking method can be included in separate IEs.

[0064]

[0065] LPP requestAssistanceData (UE → LMF, 117): The LPP requestAssistanceData message can be used by the terminal (500) to request information from the LMF (505) that is necessary or helpful for measuring wireless signals for location estimation. The information included in the LPP requestAssistanceData message can be defined as shown in Table 3 below. Common information regardless of the location estimation method can be included in commonIEsRequestAssistanceData. Additionally, information requested for each location tracking method can be included in separate IEs.

[0066]

[0067] LPP ProvideAssistanceData (LMF → UE, 120): The LPP ProvideAssistanceData message can be used by the LMF (505) to provide information necessary or helpful for the terminal (500) to measure radio signals for location estimation. The information included in the LPP ProvideAssistanceData message can be defined as shown in Table 4 below. Common information regardless of the location estimation method can be included in commonIEsProvideAssistanceData. Additionally, information provided for each location tracking method can be included in separate IEs.

[0068]

[0069] LPP Request Location Information (LMF → UE, 125): The LPP Request Location Information message can be used by the LMF (505) to request the terminal (500) for signal measurement and location estimation results necessary for location estimation. The LMF (505) can determine which location estimation method to use, which measurements the terminal should perform for location estimation, and how to respond with which results, and then include the relevant information in the LPP Request Location Information message and transmit it to the terminal (500). The information included in the LPP Request Location Information message can be defined as shown in Table 5 below.

[0070]

[0071] LPP Provide Location Information (UE → LMF, 130): The LPP Provide Location Information message can be used by the terminal (500) to transmit measurement results and location estimation results requested from the LMF (505) to the LMF (505). The information included in the LPP Provide Location Information message can be defined as shown in Table 6 below.

[0072]

[0073] FIG. 6 is a diagram illustrating a location estimation service scenario for an L2 UE-to-Network remote UE according to one embodiment of the present disclosure.

[0074] Referring to FIG. 6, a terminal (600) operating as an L2 UE-to-Network remote UE (hereinafter referred to as Remote UE) can be a location estimation target terminal. At this time, a terminal (603) operating as an L2 UE-to-Network relay UE (hereinafter referred to as Relay UE) connected to the Remote UE (600) can exchange data with the Remote UE (600) through a sidelink PC5 interface. In addition, the Relay UE (603) can exchange data with the gNB (605) through a Uu interface. The LMF (607) and the Remote UE (600) can exchange LPP messages as shown in FIG. 5 to estimate the location of the Remote UE (600). At this time, the Relay UE (603) can operate as an L2 UE-to-Network relay UE and can support the exchange of LPP messages between the LMF (607) and the Remote UE (600). For example, an LPP message sent by a Remote UE (600) to an LMF (607) can be delivered to a Relay UE (603) via a PC5 interface. And the Relay UE (603) can deliver the LPP message to the LMF (607) via a Uu interface with a gNB (605).

[0075] In addition, the Relay UE (603) can assist in position estimation of the Remote UE (600) by receiving the Positioning System Information Block (PosSIB) broadcast by the gNB (605) and then transmitting it to the Remote UE (600). At this time, the PosSIB may include at least one of the information included in the LPP Provide Assistance Data (620) of FIG. 5 as assistance information necessary for position estimation. Even when the Remote UE (600) is located outside the signal reception range of the gNB (605) and cannot receive the posSIB broadcast by the gNB (605), the Remote UE (600) can obtain positioning assistance information necessary for position estimation by receiving the posSIB transmitted by the Relay UE (603).

[0076] In addition, the Relay UE (603) may provide the Remote UE (600) with the relationship between the SFN (System Frame Number) used for time synchronization of the cell operated by the gNB (605) and the DFN (Direct Frame Number) used for time synchronization between the Remote UE (600) and the Relay UE (603) (for example, offset information between the SFN and the DFN may include at least one of frame-based offset, subframe-based offset, and slot-based offset information; hereinafter referred to as SFN-DFN offset). At this time, since the Remote UE (600) transmits and receives data through the Relay UE (603) instead of the cell operated by the gNB (605), it may have only DFN-based time synchronization information with the Relay UE (603) instead of SFN-based time synchronization information of the cell operated by the gNB (605). However, since the positioning assistance information required for location estimation generated and provided by the LMF (607) is created based on the SFN time synchronization information of the cell operated by the gNB (605), the Remote UE (600) that only has DFN-based time synchronization information may have difficulty properly interpreting the time synchronization information contained in the positioning assistance information. Therefore, the Relay UE (603) can support the location estimation of the Remote UE (600) by providing SFN-DFN offset information to the Remote UE (600).

[0077] Operations related to PosSIB transmission and SFN-DFN offset provision between Relay UE (603) and Remote UE (600) are described in more detail in the embodiments for FIGS. 8 and 9 below.

[0078] FIG. 7 is a flowchart of an exchange process of LPP messages for location estimation of an L2 UE-to-Network remote UE according to one embodiment of the present disclosure.

[0079] Referring to FIG. 7, a terminal (700) operating as an L2 UE-to-Network remote UE (hereinafter referred to as Remote UE) can be a terminal for position estimation. At this time, a terminal (703) operating as an L2 UE-to-Network relay UE (hereinafter referred to as Relay UE) connected to the Remote UE (700) can exchange data with the Remote UE (700) via a sidelink PC5 interface. In addition, the Relay UE (703) can exchange data with the gNB (705) via a Uu interface. The LMF (707) and the Remote UE (700) can exchange LPP messages to estimate the position of the Remote UE (700). Specifically, the above-described LPP message exchange operation can include the following operations. However, the order of LPP message exchange in the following LPP message exchange operation is not fixed and can be flexibly changed depending on the situation. Additionally, since the LPP message exchange operation may include at least one of the following operations, some operations may be omitted.

[0080] - LPP RequestCapabilities (710): LMF (707) may request terminal capability information related to location estimation by transmitting an LPP RequestCapabilities message to Remote UE (700) for location estimation of the Remote UE (700). At this time, information included in the LPP RequestCapabilities message may include information identical or similar to that described in LPP RequestCapabilities (710) in FIG. 5 described above.

[0081] Additionally, LMF (707) can request the following two pieces of information required for estimating the location of Remote UE (700) through the LPP RequestCapabilities (710) message.

[0082] 1. remoteUE-Indication: When the target terminal for position estimation operates as a Remote UE (700), there may be limitations in the support of functions related to the position estimation operation. For example, in the case of the Remote UE (700), it may be difficult to exchange MAC CE (MAC Control Element) with the gNB (705) because it does not have a Uu interface with the cell operated by the gNB (705). Therefore, when the target terminal for position estimation operates as a Remote UE (700), functions related to the position estimation operation that require MAC CE exchange (e.g., at least one of a pre-configured measurement gap, a pre-configured PRS processing window, or a semi-persistent / aperiodic SRS) may be difficult to use when estimating the position of the target terminal for position estimation. If the target terminal for position estimation operates as a Remote UE (700) and does not support functions related to position estimation operations, the LMF (707) may not use position estimation techniques that require functions related to position estimation operations (e.g., including at least one of DL-TDOA, Multi-RTT, or UL-TDOA) for position estimation of the target terminal. Accordingly, the LMF (707) may include a specific indicator (e.g., remoteUE-IndicationReq) in the LPP RequestCapabilities message, thereby instructing the LPP ProvideCapabilities (715) to report an indicator (e.g., remoteUE-Indication) indicating whether the target terminal for position estimation operates as a Remote UE (700).

[0083] 2. inCoverageIndication: When the target terminal for location estimation operates as a Remote UE (700), the Remote UE (700) may be located outside the coverage of the cell operated by the serving gNB (705) of the connected Relay UE (703), as shown in FIG. 6 described above. Alternatively, when the target terminal for location estimation operates as a Remote UE (700), the Remote UE (700) may be located within the coverage of the cell operated by the serving gNB (705) of the connected Relay UE (703), as shown in FIG. 7. In general, when estimating the location of the target terminal for location estimation, the LMF (707) can roughly determine the location of the terminal based on the location of the serving gNB (705) of the target terminal for location estimation, and can control the subsequent location estimation process based on the determined terminal location. For example, when a position estimation technique is used in which multiple Transmission-Reception Points (TRPs) exchange downlink signals (e.g., DL-PRS) or uplink signals (e.g., UL-SRS) with a position estimation target terminal and triangulate, the LMF (707) can select the TRPs to be used for position estimation based on the location of the serving gNB (705) of the position estimation target terminal. If the position estimation target terminal operates as a Remote UE (700), the LMF (707) can determine the approximate location of the Remote UE (700) based on the location of the serving gNB (705) of the Relay UE (703) connected to the Remote UE (700).However, if the Remote UE (700) is located outside the coverage of the cell operated by the serving gNB (705) of the Relay UE (703) to which it is connected, and the LMF (707) determines the approximate location of the Remote UE (700) based on the location of the serving gNB (705) of the Relay UE (703) connected to the Remote UE (700) and selects TRPs to be used for location estimation, this may result in a decrease in the accuracy of location estimation or a failure in location estimation. Therefore, the LMF (707) needs to determine whether the target terminal for location estimation operating as the Remote UE (700) is located inside or outside the coverage of the cell operated by the serving gNB (705) of the Relay UE (703) to which the target terminal for location estimation is connected. Accordingly, the LMF (707) can instruct the LPP ProvideCapabilities (715) to report an indicator (e.g., inCoverageIndication) indicating whether the target terminal for location estimation is located within the coverage of the cell operated by the serving gNB (705) of the connected Relay UE (703) by including a specific indicator (e.g., inCoverageIndicationReq) in the LPP RequestCapabilities message.

[0084] The remoteUE-IndicationReq and inCoverageIndicationReq directives to be included in the LPP RequestCapabilities message can be defined as shown in Table 7 below.

[0085]

[0086] In the above-described embodiment, it is assumed that the remoteUE-IndicationReq indicator and the inCoverageIndicationReq indicator are defined separately, but the remoteUE-Indication and the inCoverageIndication may be requested together with a single indicator (for example, either the remoteUE-IndicationReq indicator or the inCoverageIndicationReq indicator).

[0087] - LPP ProvideCapabilities (715): After receiving the LPP RequestCapabilities (710) message sent by the LMF (707), the Remote UE (700) for location estimation can include the requested location estimation-related terminal capability information through the LPP RequestCapabilities (710) message in the LPP ProvideCapabilities (715) message and transmit it to the LMF (707). At this time, the information included in the LPP ProvideCapabilities (715) message can include information identical or similar to that described in the LPP ProvideCapabilities (715) in FIG. 5 described above.

[0088] When the Remote UE (700) is requested to report remoteUE-Indication and inCoverageIndication through the LPP RequestCapabilities (710) message from the LMF (707) (i.e., when the remoteUE-IndicationReq and inCoverageIndicationReq indicators are included in the LPP RequestCapabilities), the Remote UE (700) may transmit the remoteUE-Indication and inCoverageIndication indicators to the LMF (707) in the LPP ProvideCapabilities (715) message as described below.

[0089] 1. remoteUE-Indication: If the position estimation target terminal (700) is requested to report remoteUE-Indication through the LPP RequestCapabilities (710) message from the LMF (707) (in other words, if the remoteUE-IndicationReq indicator is included in the LPP RequestCapabilities), the terminal may optionally include remoteUE-Indication in the LPP ProvideCapabilities (715) message. If the position estimation target terminal (700) is configured and operates as an L2 U2N Remote UE, the terminal may set the value of the remoteUE-Indication indicator to True and include it in the LPP ProvideCapabilities (715) message. Conversely, if the position estimation target terminal (700) is not configured and operates as an L2 U2N Remote UE, the terminal may not include the remoteUE-Indication indicator in the LPP ProvideCapabilities (715) message. Whenever the location estimation target terminal (700) starts or stops operating as an L2 U2N Remote UE, it can set the remoteUE-Indication indicator to an appropriate value and then transmit an LPP ProvideCapabilities (715) message. At this time, the location estimation target terminal (700) can transmit the ProvideCapabilities (715) message without receiving a new LPP RequestCapabilities (710) message from the LMF (707).

[0090] 2. inCoverageIndication: If the position estimation target terminal (700) is requested to report inCoverageIndication through the LPP RequestCapabilities (710) message from the LMF (707) (in other words, if the remoteUE-IndicationReq or inCoverageIndicationReq indicator is included in the LPP RequestCapabilities), the inCoverageIndication may be optionally included in the LPP ProvideCapabilities (715) message. Alternatively, if the position estimation target terminal (700) is requested to report remoteUE-Indication through the LPP RequestCapabilities (710) message from the LMF (707) and includes remoteUE-Indication in the LPP ProvideCapabilities (715) message (in other words, if the position estimation target terminal (700) is operating as a Remote UE), the inCoverageIndication may be optionally included in the LPP ProvideCapabilities (715) message.

[0091] In one embodiment, if a location estimation target terminal (700) operating as a Remote UE is located within the coverage of a Primary cell or camping cell of a connected Relay UE (703), the value of the inCoverage-Indication indicator can be set to True and included in the LPP ProvideCapabilities (715) message.

[0092] A remote UE can be considered to be within the coverage of a specific cell if the following cell selection criterion is satisfied for that cell. The cell selection criterion can be satisfied if both Srxlev and Squal, calculated according to the following formula, are greater than 0.

[0093]

[0094] In the above formula, each variable can be defined as follows:

[0095] - Srxlev: Cell selection RX level value (dB)

[0096] - Squal: Cell selection quality value (dB)

[0097] - Qoffsettemp: Offset temporarily applied to a cell as specified in TS 38.331 (dB)

[0098] - Qrxlevmeas: Measured cell RX level value (RSRP)

[0099] - Qqualmeas: Measured cell quality value (RSRQ)

[0100] - Qrxlevmin: Minimum required RX level in the cell (dBm). If the UE supports SUL frequency for this cell, Qrxlevmin is obtained from q-RxLevMinSUL, if present, in SIB1, SIB2 and SIB4, additionally, if QrxlevminoffsetcellSUL is present in SIB3 and SIB4 for the concerned cell, this cell specific offset is added to the corresponding Qrxlevmin to achieve the required minimum RX level in the concerned cell;

[0101] else Qrxlevmin is obtained from q-RxLevMin in SIB1, SIB2 and SIB4, additionally, if Qrxlevminoffsetcell is present in SIB3 and SIB4 for the concerned cell, this cell specific offset is added to the corresponding Qrxlevmin to achieve the required minimum RX level in the concerned cell.

[0102] - Qqualmin: Minimum required quality level in the cell (dB). Additionally, if Qqualminoffsetcell is signalled for the concerned cell, this cell specific offset is added to achieve the required minimum quality level in the concerned cell.

[0103] - Qrxlevminoffset: Offset to the signalled Qrxlevmin taken into account in the Srxlev evaluation as a result of a periodic search for a higher priority PLMN while camped normally in a VPLMN, as specified in TS 23.122.

[0104] - Qqualminoffset: Offset to the signalled Qqualmin taken into account in the Squal evaluation as a result of a periodic search for a higher priority PLMN while camped normally in a VPLMN, as specified in TS 23.122.

[0105] - Pcompensation: For FR1, if the UE supports the additionalPmax in the NR-NS-PmaxList, if present, in SIB1, SIB2 and SIB4:

[0106] max(PEMAX1 -PPowerClass, 0) - (min(PEMAX2, PPowerClass) - min(PEMAX1, PPowerClass)) (dB);

[0107] else:

[0108] max(PEMAX1 -PPowerClass, 0) (dB)

[0109] For FR2, Pcompensation is set to 0.

[0110] For IAB-MT, Pcompensation is set to 0.

[0111] - PEMAX1, PEMAX2: Maximum TX power level of a UE may use when transmitting on the uplink in the cell (dBm) defined as PEMAX in TS 38.101. If UE supports SUL frequency for this cell, PEMAX1 and PEMAX2 are obtained from the p-Max for SUL in SIB1 and NR-NS-PmaxList for SUL respectively in SIB1, SIB2 and SIB4 as specified in TS 38.331, else PEMAX1 and PEMAX2 are obtained from the p-Max and NR-NS-PmaxList respectively in SIB1, SIB2 and SIB4 for normal UL as specified in TS 38.331.

[0112] - PPowerClass: Maximum RF output power of the UE (dBm) according to the UE power class as defined in TS 38.101-1.

[0113] In one embodiment, a Remote UE may determine that it is located within the coverage of a particular cell if it can receive SSB transmitted by the particular cell.

[0114] In one embodiment, a Remote UE may determine that it is located within the coverage of a specific cell if it can confirm the identity of the specific cell by receiving SSB and SIB transmitted by the specific cell.

[0115] When the location estimation target terminal (700) operating as a Remote UE is located outside the coverage of the Primary cell or camping cell of the connected Relay UE (703), the location estimation target terminal (700) may not include the inCoverageIndication indicator in the LPP ProvideCapabilities (715) message. Whenever the location estimation target terminal (700) enters or leaves the coverage of the Primary cell or camping cell of the connected Relay UE (703), the location estimation target terminal (700) may set the inCoverageIndication indicator to an appropriate value and transmit the LPP ProvideCapabilities (715) message to the LMF (707). At this time, the location estimation target terminal (700) may transmit the ProvideCapabilities (715) message to the LMF (707) without receiving a new LPP RequestCapabilities (710) message from the LMF (707).

[0116] The remoteUE-Indication and inCoverageIndication indicators included in the LPP ProvideCapabilities message can be defined as shown in Table 8 below.

[0117]

[0118] The setting and inclusion conditions of the remoteUE-Indication and inCoverageIndication indicators can be defined as shown in Table 9 below.

[0119]

[0120] - LPP RequestAssistanceData (720): When the Remote UE (700) requires positioning assistance data for signal measurement related to position calculation and position estimation, it can request the necessary information by sending an LPP RequestAssistanceData message to the LMF (707). At this time, the information included in the LPP RequestAssistanceData message may include information identical or similar to that described in LPP RequestAssistanceData (717) in FIG. 5.

[0121] In general, the LMF (707) can receive an LPP ProvideCapabilities message from a terminal for position estimation and can identify terminal capability information related to position estimation of the terminal for position estimation. Thereafter, the LMF (707) can select a position estimation technique (for example, at least one of GNSS, DL-TDOA, or Multi-RTT) to be used for position estimation of the terminal for position estimation. In addition, the LMF can provide the auxiliary information required to use the selected position estimation technique to the terminal for position estimation through the LPP ProvideAssistanceData (725). At this time, the terminal for position estimation does not need to separately request the auxiliary information required for position estimation through the LPP RequestAssistanceData (720). However, the LMF (707) may not provide the auxiliary information required for position estimation, but may instruct the terminal for position estimation to measure a signal related to position estimation through the LPP RequestLocationInformation (730). Alternatively, if the previously received assistance information is no longer valid, the location estimation target terminal can request the necessary assistance information from the LMF (707) via the LPP RequestAssistanceData (720) message to obtain the necessary assistance information.

[0122] When a location estimation target terminal requests location estimation-related assistance information to the LMF (707) through LPP RequestAssistanceData, the location estimation target terminal can also report its current primary cell ID information. This may be to allow the LMF (707) to determine the approximate location of the terminal through the primary cell ID of the terminal and provide valid location estimation assistance information (e.g., DL-PRS configuration information that can be received at the terminal's location) at the determined location. However, when the location estimation target terminal operates as a Remote UE (700), it may be difficult for the location estimation target terminal to report primary cell information to the LMF because it only maintains a connection with the Relay UE (703). Instead, the Remote UE (700) can provide the ID information of the primary cell or camping cell of the connected Relay UE (703) to the LMF (707) through LPP RequestAssistanceData. At this time, the primary cell ID information included in the LPP RequestAssistanceData may be defined as in Table 10 or Table 11 below. The field description of the primaryCellID field in Table 10 below may be newly defined. Additionally, RelayPrimaryCellID may be newly introduced for Remote UE in Table 11.

[0123]

[0124]

[0125] For reference, in the embodiment of Table 11, only the case where NCGI (NR Cell Global Identifier) ​​is used as the primary / camping cell ID of the Relay UE (703) connected to the Remote UE (700) is expressed for ease of explanation, but instead of NCGI, a combination of at least one of SL-AccessInfo-L2U2N IE, CellAccessRelatedInfo IE, and SL-ServingCellInfo IE defined in Table 12 below in the TS 38.331 standard may be used.

[0126]

[0127] - LPP ProvideAssistanceData(725): After receiving the LPP RequestAssistanceData(720) message sent by the Remote UE(700) that is the target of location estimation, the LMF(707) can include the assistance information related to location estimation requested through the LPP RequestAssistanceData(720) message in the LPP ProvideAssistanceData(725) message and transmit it to the Remote UE(700). Alternatively, the LMF(707) can select a location estimation technique to be used for location estimation of the target terminal for location estimation without a separate request from the target terminal for location estimation. In addition, the LMF(707) can provide the assistance information necessary for using the selected location estimation technique to the target terminal for location estimation through the LPP ProvideAssistanceData(725). The information included in the LPP ProvideAssistanceData message can include the same or similar information as described in the LPP ProvideAssistanceData(720) of FIG. 5.

[0128] - LPP RequestLocationInformation (730): LMF (707) can request a report of location estimation results or a report of location estimation-related signal measurement results by sending an LPP RequestLocationInformation message to the Remote UE to estimate the location of the Remote UE (700) that is the target of location estimation. At this time, the information included in the LPP RequestLocationInformation message can include information identical or similar to that described in LPP RequestLocationInformation (725) in FIG. 5.

[0129] - LPP ProvideLocationInformation (735): After receiving the LPP RequestLocationInformation (730) message sent by the LMF (707), the Remote UE (700) for location estimation can include the location estimation result or the location estimation-related signal measurement result requested through the message in the LPP ProvideLocationInformation (735) message and transmit it to the LMF. At this time, the information included in the LPP ProvideLocationInformation message can include information identical or similar to that described in the LPP ProvideLocationInformation (730) in FIG. 5 described above.

[0130] FIG. 8 is a flowchart of a process in which an L2 UE-to-Network remote UE receives auxiliary information necessary for location estimation in an RRC_IDLE / RRC_INACTIVE state according to an embodiment of the present disclosure.

[0131] Referring to FIG. 8, a location estimation target UE (800) operating as a remote UE may request forwarding of location estimation system information (hereinafter referred to as PosSIB) broadcast by a base station (805) to a relay UE (803) in order to perform a location estimation operation in an RRC_IDLE or RRC_INACTIVE state. In addition, if the location estimation assistance information included in the PosSIB includes information created based on the SFN time synchronization information of the cell operated by the gNB (805), a remote UE (800) having only DFN-based time synchronization information may request SFN-DFN offset information from the relay UE (803) in order to obtain SFN-based time synchronization. A specific process for the remote UE (800) to request and receive PosSIB and SFN-DFN offset information from the relay UE (803) may be described as follows.

[0132] - Assistance data request from upper layers (step 815): The RRC layer of the position estimation target UE (800) operating as a remote UE can be requested to acquire PosSIB for position estimation from an upper layer (e.g., an LPP (LTE Positioning Protocol) layer or an application layer which is a layer higher than the RRC layer) in the RRC_IDLE or RRC_INACTIVE state. Depending on the position estimation method to be used (e.g., at least one of GNSS, OTDOA, or DL-TDOA / DL-AoD), the type of posSIB (e.g., posSIB type) required by the position estimation target UE may vary. Accordingly, the upper layer (e.g., LPP layer or application layer) of the position estimation target UE can request the RRC layer to acquire posSIB, and can also transmit information on the type of posSIB (e.g., posSIB type) that matches the position estimation method to be used.

[0133] - RemoteUEInformationSidelink (step 820): When a location estimation target UE (800) operating as a remote UE is requested to acquire specific posSIB types from a higher layer in step 815, if all of the following conditions are satisfied, the remote UE (800) can include a list of posSIBs to be acquired (e.g., sl-RequestedPosSIB-List) in a RemoteUEInformationSidelink message and transmit it to the connected Relay UE (803). The location estimation target UE (800) can request forwarding of posSIBs by transmitting the list of posSIBs to the Relay UE (803).

[0134] Condition 1: Not having a valid version of posSIB information for at least one posSIB type required for position estimation operation.

[0135] Condition 2: At least one posSIB type required for position estimation operation shall not have been indicated in the RemoteUEInformationSidelink message transmitted to the Relay UE (803).

[0136] Condition 3: This must be the case where the posSIB-ForwardingSupported value was set to true in the UECapabilityInformationSidelink message previously transmitted by the Relay UE (803).

[0137] On the other hand, if the remote UE (800) no longer needs to acquire posSIBs, it can set the sl-RequestedPosSIB-List value in the RemoteUEInformationSidelink message to release. Then, the remote UE can cancel the posSIB forwarding request by transmitting a RemoteUEInformationSidelink message including the sl-RequestedPosSIB-List set to release to the relay UE (803).

[0138] - posSIB acquisition (step 823): If the Relay UE (803) receives a RemoteUEinformationSidelink message (820) including sl-RequestedPosSIB-List from the Remote UE (800) and does not have a valid version of the requested posSIBs, the Relay UE (803) may receive a posSIB from the base station (805). However, if the Relay UE (803) has a valid version of the posSIBs requested by the Remote UE (800) through sl-RequestedPosSIB-List, this step may be omitted.

[0139] - UuMessageTransferSidelink (step 825): Relay UE (803) can transfer posSIBs requested through RemoteUEINformationSidelink (820) message to Remote UE (800) through UuMessageTransferSidelink message. At this time, posSIBs transferred to Remote UE (800) can be included in the sl-SystemInformationDelivery field in the UuMessageTransferSidelink message.

[0140] - SFN-DFN offset Request from upper layers (step 830): If the posSIB information acquired (or to be acquired) for position estimation includes SFN-based time synchronization information, the Remote UE (800) may need SFN-DFN offset information to obtain SFN-based time synchronization. More specifically, the RRC layer of the Remote UE (800) may be requested to acquire SFN-DFN offset information from an upper layer (e.g., LPP or application layer) as needed.

[0141] - RemoteUEInformationSidelink (step 831): The RRC layer of the Remote UE (800) can request SFN-DFN offset information from the Relay UE (803) by setting the sl-SFN-DFN-OffsetRequested indicator value in the RemoteUEinformationSidelink message transmitted to the Relay UE (803) to true.

[0142] The sl-SFN-DFN-OffsetRequested directive within the RemoteUEInformationSidelink message can be defined as shown in Table 13 below.

[0143]

[0144] As shown in Table 13, when the data type of sl-SFN-DFN-offsetRequested is defined as ENUMERATED {true} and the Need code is defined as 'R', if the RemoteUEinformationSidelink message transmitted by the Remote UE (800) does not include the sl-SFN-DFN-OffsetRequested indicator, the Relay UE (803) may release the previously stored configuration. In addition, the Relay UE (803) may no longer provide SFN-DFN offset information. Therefore, the RRC layer of the Remote UE (800) may determine whether SFN-DFN offset information is required based on a higher layer request whenever it sends a RemoteUEinformationSidelink message to the Relay UE (803). At this time, if SFN-DFN offset information is required and the Relay UE (803) has set the sfn-DFN-OffsetSupported value to true in the UECapabilityInformationSidelink previously transmitted, the Remote UE (800) may include the sl-SFN-DFN-offsetRequested indicator in the RemoteUEinformationSidelink message. And the Remote UE (800) may set the sl-SFN-DFN-offsetRequested indicator value to true. However, if the Remote UE (800) no longer needs the SFN-DFN offset information, the Remote UE (800) may not include the sl-SFN-DFN-offsetRequested indicator in the RemoteUEinformationSidelink message. And the Remote UE (800) may release the existing configuration by transmitting it to the Relay UE (803).The operation of the remote UE (800) setting the sl-SFN-DFN-offsetRequested indicator may be identical or similar to that described in the specification, as shown in Table 14 below.

[0145]

[0146] Alternatively, the sl-SFN-DFN-OffsetRequested directive within the RemoteUEInformationSidelink message may be defined as shown in Table 15 below.

[0147]

[0148] As shown in Table 15, if the data type of sl-SFN-DFN-offsetRequested is defined as SetupRelase and the Need code is defined as 'M', if the RemoteUEinformationSidelink message transmitted by the Remote UE (800) does not include the sl-SFN-DFN-OffsetRequested indicator, the Relay UE (803) can maintain the previously stored settings. For example, if the RemoteUEinformationSidelink message previously transmitted by the Remote UE (800) to the Relay UE (803) includes the sl-SFN-DFN-OffsetRequested indicator and the sl-SFN-DFN-OffsetRequested indicator value is set to true, the Relay UE (803) can maintain the existing setting value even if the RemoteUEinformationSidelink message transmitted by the Remote UE (800) to the Relay UE (803) does not include the sl-SFN-DFN-OffsetRequested indicator. And the Relay UE (803) can continuously provide SFN-DFN offset information to the Remote UE (800). The RRC layer of the Remote UE (800) can determine whether SFN-DFN offset information is required based on a request from a higher layer each time it sends a RemoteUEinformationSidelink message to the Relay UE (803).At this time, if the Remote UE (800) needs SFN-DFN offset information, if the sl-SFN-DFN-OffsetRequested indicator has not been set to true in the RemoteUEinformationSidelink message that the Remote UE (800) previously transmitted to the Relay UE (803) and the sfn-DFN-OffsetSupported value has been set to true in the UECapabilityInformationSidelink that the Relay UE (803) previously transmitted, the Remote UE (800) may include the sl-SFN-DFN-offsetRequested indicator in the RemoteUEinformationSidelink message. In addition, the Remote UE (800) may set the sl-SFN-DFN-offsetRequested indicator value to true. If the Remote UE (800) no longer needs the SFN-DFN offset information, the Remote UE (800) may set the value of the sl-SFN-DFN-offsetRequested indicator in the RemoteUEinformationSidelink message to release. And Remote UE (800) can release the existing configuration by sending RemoteUEinformationSidelink message including sl-SFN-DFN-offsetRequested indicator set to release to Relay UE (803). The operation of Remote UE (800) setting sl-SFN-DFN-offsetRequested indicator may be identical or similar to that described in the specification as shown in Table 16 below.

[0149]

[0150] In one embodiment, depending on the implementation of the Remote UE (800), the RemoteUEInformationSidelink message (831) for requesting SFN-DFN offset information may be merged with the RemoteUEInformationSidelink message (820) for requesting posSIB forwarding. For example, the sl-RequestedPosSIB-List field and the sl-SFN-DFN-OffsetRequested indicator may be included and set simultaneously within the same RemoteUEInformationSidelink message.

[0151] - RRCReconfigurationSidelink (step 835): Relay UE (803) that has received a request for SFN-DFN offset information from Remote UE (800) through RemoteUEInformationSidelink message (831) can provide SFN-DFN offset information to Remote UE (800) through RRCReconfigurationSidelink message. SFN-DFN offset information in RemoteUEInformationSidelink can be defined as shown in Table 17 below.

[0152]

[0153] The operation of Relay UE (803) providing SFN-DFN offset information to Remote UE (800) through RRCReconfigurationSidelink at the request of Remote UE (800) in step 831 may be the same as or similar to that described in Table 18 below.

[0154]

[0155] FIG. 9 is a flowchart of a process in which an L2 UE-to-Network remote UE receives auxiliary information necessary for location estimation in an RRC _CONNECTED state according to one embodiment of the present disclosure.

[0156] Referring to FIG. 9, a location estimation target UE (900) operating as a remote UE may request location estimation-related assistance information from a base station (905) or an LMF (907) to perform a location estimation operation in an RRC_CONNECTED state. In step 823, if a base station (e.g., a Serving gNB (905), which may be referred to as a base station hereinafter) provides location estimation system information (hereinafter referred to as PosSIB), the remote UE (900) may request the necessary posSIB from the base station (905) in an RRC_CONNECTED state.

[0157] Alternatively, in step 833, if the Remote UE (900) is maintaining an LPP session with the LMF (907), it may request necessary position estimation assistance information from the LMF (907) through an LPP message. In addition, if the position estimation assistance information included in the posSIB (925) received from the base station (905) or the LPP message (935) received from the LMF (907) includes information created based on the SFN time synchronization information of the cell operated by the base station (905), the Remote UE (900) that has only DFN-based time synchronization information may request SFN-DFN offset information from the Relay UE (903) in order to obtain SFN-based time synchronization. A specific process for the Remote UE (900) to obtain the position estimation assistance information and the SFN-DFN offset information may be described as follows.

[0158] - Assistance data request from upper layers (step 915): The RRC layer of the position estimation target UE (900) operating as the remote UE (900) can be requested to acquire PosSIB for position estimation from an upper layer (e.g., an LPP layer or an application layer higher than the RRC layer) in the RRC_CONNECTED state. Depending on the position estimation method to be used (e.g., at least one of GNSS, OTDOA, or DL-TDOA / DL-AoD), the type of posSIB (e.g., posSIB type) that the position estimation target UE needs may vary. Accordingly, the upper layer (e.g., an LPP layer or an application layer) of the position estimation target UE can request the RRC layer to acquire posSIB, and can also transmit the type of posSIB (e.g., posSIB type) that matches the position estimation method to be used. At this time, the remote UE (900) can acquire posSIB as in Case 1 (step 920) below.

[0159] Alternatively, the LPP layer of the position estimation target UE (900) operating as a remote UE may be requested to acquire position estimation-related assistance information for position estimation from a higher layer (e.g., an application layer higher than the LPP layer) in the RRC_CONNECTED state. The type of position estimation assistance information required by the position estimation target UE may vary depending on the position estimation method to be used (e.g., at least one of GNSS, OTDOA, or DL-TDOA / DL-AoD). Therefore, the higher layer (e.g., the application layer) of the position estimation target UE may request the LPP layer to acquire position estimation assistance information, and may also transmit the position estimation method to be used. At this time, the remote UE (900) may acquire position estimation assistance information as in Case 2 (step 930) below.

[0160] Case 1: When the RRC layer of the remote UE (900) requests posSIB from the base station (905) (920)

[0161] - DedicatedSIBRequest (Step 923): When a location estimation target UE (900) operating as a remote UE is requested to acquire specific posSIB types from a higher layer in Step 915, if at least one of the requested posSIBs is included in posSI-SchedulingInfo in the previously stored SIB1 (for example, the remote UE (900) can forward SIB1 through the relay UE (903), the remote UE (900) can request the base station (905) for the required posSIBs through a DedicatedSIBRequest message. At this time, the remote UE (900) can request the base station (905) for posSIBs of a specific type by including the required posSIB type information in the RequestedPosSIB-List in the DedicatedSIBRequest message.

[0162] - RRCReconfiguration (step 925): The base station (905) can provide the posSIBs requested through the DedicatedSIBRequest (923) message to the Remote UE (900) through the RRCReconfiguration message. At this time, the posSIBs provided to the Remote UE (900) can be included in the dedicatedSystemInformationDelivery field in the RRCReconfiguration message.

[0163] Case 2: When requesting location estimation assistance information from LMF (907) in the LPP layer of Remote UE (900) (930)

[0164] - LPP RequestAssistanceData (Step 933): When a location estimation target UE (900) operating as a remote UE is requested to obtain location estimation assistance information necessary for using a specific location estimation method from a higher layer in Step 915, the remote UE (900) may request the necessary information by sending an LPP RequestAssistanceData message to the LMF (907). At this time, the information included in the LPP RequestAssistanceData message may include information identical or similar to that described in LPP RequestAssistanceData (917) in FIG. 5.

[0165] - LPP ProvideAssistanceData (Step 935): The LMF (907) can receive the LPP RequestAssistanceData (933) message sent by the Remote UE (900) that is the target of location estimation. Then, the LMF (907) can include the location estimation-related assistance information requested through the LPP RequestAssistanceData (933) message in the LPP ProvideAssistanceData (935) message and transmit it to the LMF (907). Alternatively, the LMF (907) can select a location estimation technique to be used for location estimation of the target terminal without a separate request from the target terminal. Then, the LMF (907) can provide the assistance information necessary for using the selected location estimation technique to the target terminal through the LPP ProvideAssistanceData (935). The information included in the LPP ProvideAssistanceData message can include the same or similar information as described in the LPP ProvideAssistanceData (920) of FIG. 5.

[0166] - SFN-DFN offset Request from upper layers (step 940): If the posSIB and position estimation assistance information acquired (or to be acquired) for position estimation include SFN-based time synchronization information, the Remote UE (900) may need SFN-DFN offset information to obtain SFN-based time synchronization. More specifically, the RRC layer of the Remote UE (900) may be requested to acquire SFN-DFN offset information from an upper layer (e.g., LPP or application layer) as needed.

[0167] - RemoteUEInformationSidelink (step 943): The RRC layer of the Remote UE (900) can request SFN-DFN offset information from the Relay UE (903) by setting the sl-SFN-DFN-OffsetRequested indicator value in the RemoteUEinformationSidelink message transmitted to the Relay UE (903) to true even in the RRC_CONNECTED state.

[0168] The sl-SFN-DFN-OffsetRequested directive within the RemoteUEInformationSidelink message can be defined as shown in Table 19 below.

[0169]

[0170] As shown in Table 19, when the data type of sl-SFN-DFN-offsetRequested is defined as ENUMERATED {true} and the Need code is defined as 'R', if the RemoteUEinformationSidelink message transmitted by the Remote UE (900) does not include the sl-SFN-DFN-OffsetRequested indicator, the Relay UE (903) can release the previously stored configuration. And the Relay UE (903) may no longer provide SFN-DFN offset information. Therefore, the RRC layer of the Remote UE (900) can determine whether SFN-DFN offset information is required based on a higher layer request whenever it sends a RemoteUEinformationSidelink message to the Relay UE (903). At this time, if SFN-DFN offset information is required and the Relay UE (903) has set the sfn-DFN-OffsetSupported value to true in the UECapabilityInformationSidelink previously transmitted, the Remote UE (900) may include the sl-SFN-DFN-offsetRequested indicator in the RemoteUEinformationSidelink message. In addition, the Remote UE (900) may set the sl-SFN-DFN-offsetRequested indicator value in the RemoteUEinformationSidelink message to true. However, if the Remote UE (900) no longer needs the SFN-DFN offset information, the Remote UE (900) may release the existing configuration by transmitting the sl-SFN-DFN-offsetRequested indicator to the Relay UE (903) without including it in the RemoteUEinformationSidelink message.The operation of the remote UE (900) setting the sl-SFN-DFN-offsetRequested indicator in the RRC_CONNECTED state may be identical or similar to that described in the specification as shown in Table 20 below.

[0171]

[0172] Alternatively, the sl-SFN-DFN-OffsetRequested directive within the RemoteUEInformationSidelink message can be defined as shown in Table 21 below.

[0173]

[0174] As shown in Table 21, if the data type of sl-SFN-DFN-offsetRequested is defined as SetupRelase and the Need code is defined as 'M', if the RemoteUEinformationSidelink message transmitted by the Remote UE (900) does not include the sl-SFN-DFN-OffsetRequested indicator, the Relay UE (903) can maintain the previously stored configuration. For example, if the RemoteUEinformationSidelink message previously transmitted by the Remote UE (900) to the Relay UE (903) includes the sl-SFN-DFN-OffsetRequested indicator and the sl-SFN-DFN-OffsetRequested indicator value is set to true, the Relay UE (903) can maintain the existing configuration value even if the RemoteUEinformationSidelink message transmitted by the Remote UE (900) to the Relay UE (903) does not include the sl-SFN-DFN-OffsetRequested indicator. And the Relay UE (903) can provide SFN-DFN offset information to the Remote UE (900). The RRC layer of the Remote UE (900) can determine whether SFN-DFN offset information is required based on a higher layer request whenever it sends a RemoteUEinformationSidelink message to the Relay UE (903).At this time, if the Remote UE (900) requires SFN-DFN offset information, if the sl-SFN-DFN-OffsetRequested indicator has not been set to true in the RemoteUEinformationSidelink message previously transmitted by the Remote UE (900) to the Relay UE (903) and the sfn-DFN-OffsetSupported value has been set to true in the UECapabilityInformationSidelink previously transmitted by the Relay UE (903), the Remote UE (900) may include the sl-SFN-DFN-offsetRequested indicator in the RemoteUEinformationSidelink message. In addition, the Remote UE (900) may set the sl-SFN-DFN-offsetRequested indicator value in the RemoteUEinformationSidelink message to true. However, if the Remote UE (900) no longer needs the SFN-DFN offset information, it can set the value of the sl-SFN-DFN-offsetRequested indicator in the RemoteUEinformationSidelink message to release. Then, the Remote UE (900) can release the existing setting by transmitting it to the Relay UE (903). The operation of the Remote UE (900) setting the sl-SFN-DFN-offsetRequested indicator in the RRC_CONNECTED state can be the same as or similar to that described in the specification, as shown in Table 22 below.

[0175]

[0176] - RRCReconfigurationSidelink (step 945): The Relay UE (903), which has received a request for SFN-DFN offset information from the Remote UE (900) through the RemoteUEInformationSidelink message (e.g., step 943), may provide the SFN-DFN offset information to the Remote UE (900) through the RRCReconfigurationSidelink message. The SFN-DFN offset information in the RemoteUEInformationSidelink may be defined as shown in Table 23 below.

[0177]

[0178] The operation of Relay UE (903) providing SFN-DFN offset information to Remote UE (900) through RRCReconfigurationSidelink at the request of Remote UE (900) in step 943 may be the same as or similar to that described in Table 24 below.

[0179]

[0180] FIG. 10 is a diagram illustrating a terminal device according to one embodiment of the present disclosure.

[0181] Referring to FIG. 10, the terminal may include an RF (Radio Frequency) processing unit (1010), a baseband processing unit (1020), a storage unit (1030), and a control unit (1040). The configuration of the terminal is not limited to the exemplary configuration illustrated in FIG. 10, and may include fewer or more configurations than the configuration illustrated in FIG. 10.

[0182] The RF processing unit (1010) can perform functions for transmitting and receiving signals through a wireless channel, such as signal band conversion and amplification. For example, the RF processing unit (1010) can up-convert a baseband signal provided from the baseband processing unit (1020) into an RF band signal and transmit it through an antenna, and can down-convert an RF band signal received through the antenna into a baseband signal. For example, the RF processing unit (1010) can include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a digital to analog convertor (DAC), an analog to digital convertor (ADC), etc., but is not limited to these examples. In FIG. 10, only one antenna is illustrated, but the terminal can be equipped with multiple antennas. In addition, the RF processing unit (1010) can include multiple RF chains. Furthermore, the RF processing unit (1010) can perform beamforming. For beamforming, the RF processing unit (1010) can adjust the phase and magnitude of each signal transmitted and received through multiple antennas or antenna elements. In addition, the RF processing unit (1010) can perform MIMO and receive multiple layers when performing MIMO operations.

[0183] The baseband processing unit (1020) can perform a conversion function between a baseband signal and a bit stream according to the physical layer specifications of the system. For example, when transmitting data, the baseband processing unit (1020) can generate complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit (1020) can restore a reception bit stream by demodulating and decoding a baseband signal provided from the RF processing unit (1010). For example, in the case of following the OFDM (orthogonal frequency division multiplexing) method, when transmitting data, the baseband processing unit (1020) can generate complex symbols by encoding and modulating a transmission bit stream, map the generated complex symbols to subcarriers, and then configure OFDM symbols through an inverse fast Fourier transform (IFFT) operation and a cyclic prefix (CP) insertion. In addition, when receiving data, the baseband processing unit (1020) divides the baseband signal provided from the RF processing unit (1010) into OFDM symbol units, restores signals mapped to subcarriers through an FFT (fast Fourier transform) operation, and then restores the received bit string through demodulation and decoding.

[0184] The baseband processing unit (1020) and the RF processing unit (1010) can transmit and receive signals as described above. Accordingly, the baseband processing unit (1020) and the RF processing unit (1010) may be referred to as a transmitter, a receiver, a transceiver, or a communication unit. Furthermore, at least one of the baseband processing unit (1020) and the RF processing unit (1010) may include a plurality of communication modules to support a plurality of different wireless access technologies. In addition, at least one of the baseband processing unit (1020) and the RF processing unit (1010) may include different communication modules to process signals of different frequency bands. For example, the different wireless access technologies may include wireless LAN (e.g., IEEE 802.11), a cellular network (e.g., LTE), etc. Additionally, different frequency bands may include super high frequency (SHF) (e.g., 2.NRHz, NRhz) bands and millimeter wave (mm wave) (e.g., 60GHz) bands. The terminal may transmit and receive signals with the gNB using the baseband processing unit (1020) and the RF processing unit (1010), and the signals may include control information and data.

[0185] The storage unit (1030) can store data such as basic programs, application programs, and setting information for the operation of the terminal. For example, the storage unit (1030) can store data information such as basic programs, application programs, and setting information for the operation of the terminal. In addition, the storage unit (1030) can provide the stored data at the request of the control unit (1040).

[0186] The storage unit (1030) may be configured as a storage medium or a combination of storage media, such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. In addition, the storage unit (1030) may be configured as a plurality of memories. According to one embodiment of the present disclosure, the storage unit (1030) may store a program for performing a handover method according to the present disclosure.

[0187] The control unit (1040) can control the overall operations of the terminal. For example, the control unit (1040) can transmit and receive signals through the baseband processing unit (1020) and the RF processing unit (1010).

[0188] Additionally, the control unit (1040) can record and read data in the storage unit (1030). For this purpose, the control unit (1040) may include at least one processor. For example, the control unit (1040) may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls upper layers such as application programs. Furthermore, according to one embodiment of the present disclosure, the control unit (1040) may include a multi-connection processing unit (1042) configured to process a process operating in a multi-connection mode. Furthermore, at least one component within the terminal may be implemented as a single chip.

[0189] FIG. 11 is a diagram illustrating a base station device according to one embodiment of the present disclosure. The base station of FIG. 11 may be included in the aforementioned network.

[0190] Referring to FIG. 11, the base station may include an RF processing unit (1110), a baseband processing unit (1120), a backhaul communication unit (1130), a storage unit (1140), and a control unit (1150). The configuration of the base station is not limited to the exemplary configuration illustrated in FIG. 11, and the base station may include fewer or more configurations than the configuration illustrated in FIG. 11. The RF processing unit (1110) may perform functions for transmitting and receiving signals through a wireless channel, such as signal band conversion and amplification. For example, the RF processing unit (1110) may up-convert a baseband signal provided from the baseband processing unit (1120) into an RF band signal and then transmit it through an antenna, and may down-convert an RF band signal received through the antenna into a baseband signal. For example, the RF processing unit (1110) may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, etc. In FIG. 11, only one antenna is illustrated, but the RF processing unit (1110) may be equipped with multiple antennas. In addition, the RF processing unit (1110) may include multiple RF chains. Furthermore, the RF processing unit (1110) may perform beamforming. For beamforming, the RF processing unit (1110) may adjust the phase and magnitude of each signal transmitted and received through the multiple antennas or antenna elements. The RF processing unit (1110) may perform a downlink MIMO operation by transmitting one or more layers.

[0191] The baseband processing unit (1120) can perform a conversion function between a baseband signal and a bit stream according to the physical layer standard. For example, when transmitting data, the baseband processing unit (1120) can generate complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit (1120) can restore the reception bit stream by demodulating and decoding the baseband signal provided from the RF processing unit (1110). For example, in the case of following the OFDM method, when transmitting data, the baseband processing unit (1120) can generate complex symbols by encoding and modulating a transmission bit stream, map the generated complex symbols to subcarriers, and then configure OFDM symbols through an IFFT operation and CP insertion. In addition, when receiving data, the baseband processing unit (1120) can divide the baseband signal provided from the RF processing unit (1110) into OFDM symbol units, restore the signals mapped to subcarriers through FFT operation, and then restore the received bit string through demodulation and decoding. The baseband processing unit (1120) and the RF processing unit (1110) can transmit and receive signals as described above. Accordingly, the baseband processing unit (1120) and the RF processing unit (1110) may be referred to as a transmitter, a receiver, a transceiver, a communication unit, or a wireless communication unit. The base station can transmit and receive signals with the terminal using the baseband processing unit (1120) and the RF processing unit (1110), and the signals may include control information and data.

[0192] The backhaul communication unit (1130) may provide an interface for communicating with other nodes within the network. For example, the backhaul communication unit (1130) may convert a bit stream transmitted from a primary base station to another node, such as an auxiliary base station or core network, into a physical signal, and may convert a physical signal received from another node into a bit stream.

[0193] The storage unit (1140) can store data such as basic programs, application programs, and setting information for the operation of the main base station. For example, the storage unit (1140) can store information on bearers assigned to connected terminals, measurement results reported from connected terminals, etc. In addition, the storage unit (1140) can store information that serves as a basis for determining whether to provide or terminate multiple connections to the terminals. In addition, the storage unit (1140) can provide the stored data at the request of the control unit (1150). The storage unit (1140) can be configured as a storage medium or a combination of storage media such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. In addition, the storage unit (1140) can be configured as a plurality of memories. According to one embodiment of the present disclosure, the storage unit (1140) can also store a program for performing a handover according to the present disclosure.

[0194] The control unit (1150) can control the overall operations of the base station. For example, the control unit (1150) can transmit and receive signals through the baseband processing unit (1120) and the RF processing unit (1110) or through the backhaul communication unit (1130). In addition, the control unit (1150) can record and read data in the storage unit (1140). For this purpose, the control unit (1150) can include at least one processor. In addition, according to one embodiment of the present disclosure, the control unit (1150) can include a multi-connection processing unit (1152) configured to process a process operating in a multi-connection mode.

[0195] The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0196] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to the embodiments described in the claims or specification of the present disclosure.

[0197] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage device, compact disc ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage device, magnetic cassette. Or, they may be stored in a memory configured as a combination of some or all of these. In addition, each configuration memory may be included in multiple numbers.

[0198] Additionally, the program may be stored on an attachable storage device that is accessible via a communication network, such as the Internet, an intranet, a local area network (LAN), a wide local area network (WLAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device performing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device performing an embodiment of the present disclosure.

[0199] In this disclosure, the term "computer program product" or "computer-readable medium" is used to collectively refer to media such as memory, a hard disk installed in a hard disk drive, and signals. These "computer program products" or "computer-readable mediums" are components provided in a method for reporting terminal capabilities in a wireless communication system according to the present disclosure.

[0200] A device-readable storage medium may be provided in the form of a non-transitory storage medium. Here, the term "non-transitory storage medium" simply means a tangible device that does not contain signals (e.g., electromagnetic waves). This term does not distinguish between cases where data is permanently stored in the storage medium and cases where data is temporarily stored. For example, a "non-transitory storage medium" may include a buffer in which data is temporarily stored.

[0201] According to one embodiment, the method according to various embodiments disclosed in the present document may be provided as included in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., compact disc read only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) via an application store (e.g., Play Store™) or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product (e.g., a downloadable app) may be temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0202] In the specific embodiments of the present disclosure described above, components included in the invention are expressed in the singular or plural form, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in the plural form may be composed of singular elements, or components expressed in the singular form may be composed of plural elements.

[0203] Meanwhile, the embodiments of the present disclosure disclosed in this specification and drawings are merely specific examples to easily explain the technical contents of the present disclosure and to help understand the present disclosure, and are not intended to limit the scope of the present disclosure. In other words, it will be apparent to those skilled in the art that other modified examples based on the technical idea of ​​the present disclosure are possible. In addition, each embodiment can be combined and operated as needed. For example, parts of one embodiment of the present disclosure and another embodiment can be combined to operate a base station and a terminal. In addition, the embodiments of the present disclosure can be applied to other communication systems, and other modified examples based on the technical idea of ​​the embodiments can also be implemented. For example, the embodiments can be applied to LTE systems, 5G, NR systems, or 6G systems. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be determined not only by the scope of the following claims but also by equivalents of the claims.

Claims

1. A method performed by a first UE (user equipment) in a wireless communication system, A step of receiving first information requesting an indication from an LMF (location management function) entity as to whether the first UE is a remote UE; A step of transmitting information indicating that the first UE is the remote UE to the LMF entity based on the request; When the first UE is the remote UE and is in an RRC (radio resource control) connection state, a step of transmitting second information for requesting an SFN (system frame number)-DFN (direct frame number) offset to the second UE; and A method comprising the step of receiving information regarding the SFN-DFN offset from the second UE.

2. In paragraph 1, A method wherein the first UE is an L2 (layer 2) U2N (UE to network) remote UE, and the second UE is an L2 U2N relay UE.

3. In paragraph 1, A method wherein the second information is transmitted when the first UE requires the SFN-DFN offset and the second UE supports the SFN-DFN offset.

4. In paragraph 1, A method wherein the second information is included in a remote UE information sidelink message.

5. A method performed by a second UE of a wireless communication system, A step of receiving first information for requesting a SFN (system frame number)-DFN (direct frame number) offset from a first UE; and A method comprising the step of transmitting information regarding the SFN-DFN offset to the first UE.

6. In paragraph 5, A method wherein the first UE is an L2 (layer 2) U2N (UE to network) remote UE, and the second UE is an L2 U2N relay UE.

7. In paragraph 5, A method wherein the first information is received when the first UE requires the SFN-DFN offset and the second UE supports the SFN-DFN offset.

8. In paragraph 5, A method, wherein the first information is included in a remote UE information sidelink message.

9. In the first UE of the wireless communication system, Transmitter and receiver; and At least one control unit connected to the above transceiver unit, At least one of the above control units: Receive first information requesting an indication from an LMF (location management function) entity as to whether the first UE is a remote UE; Based on the above request, the first UE transmits information indicating that it is the remote UE to the LMF entity, If the first UE is the remote UE and is in an RRC (radio resource control) connection state, the second information is transmitted to the second UE to request an SFN (system frame number)-DFN (direct frame number) offset, and A first UE configured to receive information regarding the SFN-DFN offset from the second UE.

10. In paragraph 9, A first UE, wherein the first UE is an L2 (layer 2) U2N (UE to network) remote UE, and the second UE is an L2 U2N relay UE.

11. In paragraph 9, The second information is transmitted by the first UE when the first UE requires the SFN-DFN offset and the second UE supports the SFN-DFN offset.

12. In paragraph 9, The second information is included in a remote UE information sidelink message, the first UE.

13. In the second UE of the wireless communication system, Transmitter and receiver; and At least one control unit connected to the above transceiver unit, At least one of the above control units: Receive first information for requesting SFN(system frame number)-DFN(direct frame number) offset from the first UE, and A second UE configured to transmit information regarding the SFN-DFN offset to the first UE.

14. In paragraph 13, A second UE, wherein the first UE is an L2 (layer 2) U2N (UE to network) remote UE, and the second UE is an L2 U2N relay UE.

15. In paragraph 13, The first information is received by the second UE when the first UE requires the SFN-DFN offset and the second UE supports the SFN-DFN offset.

Images