Method and device for allocating sl-PRS transmission resource when performing sidelink positioning in mobile communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method performed by a first terminal in a wireless communication system according to the present disclosure comprises the steps of: receiving assistance information for transmitting a sidelink positioning reference signal (PRS); and transmitting the sidelink PRS to a second terminal when the assistance information includes first information for triggering sidelink PRS transmission of the first terminal.

Description

Method and device for allocating SL-PRS transmission resources when performing sidelink positioning in a mobile communication system

[0001] The present disclosure relates to a method and device for providing sidelink positioning in a mobile communication system.

[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 band (for example, the 3 terahertz (3THz) 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 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 RACH for NR that simplifies random access procedures is also in progress, and standardization of system architecture / services for 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 is also in progress.

[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 operation and internalize end-to-end AI support functions to realize system optimization, 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 next-generation wireless communication system.

[0009] A method performed by a first terminal of a wireless communication system according to the present disclosure for solving the above-described problem may include a step of receiving auxiliary information for transmitting a sidelink PRS (Positioning Reference Signal), and a step of transmitting a sidelink PRS to a second terminal when the auxiliary information includes first information for triggering sidelink PRS transmission of the first terminal.

[0010] The present disclosure provides a device and method capable of effectively providing a service in a next-generation 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 in a next-generation mobile communication system according to one embodiment of the present disclosure.

[0014] FIG. 4 is a diagram illustrating a sidelink positioning service scenario according to one embodiment of the present disclosure.

[0015] FIG. 5 is a diagram illustrating an example of a signal flow for allocating transmission resources of a side link in a wireless communication system according to various embodiments of the present disclosure.

[0016] FIG. 6 is a diagram illustrating an example of a signal flow for performing a sidelink positioning service according to one embodiment of the present disclosure.

[0017] FIG. 7 is a diagram illustrating an example of a MAC CE structure used when allocating SL-PRS transmission resources in a dynamic grant manner according to one embodiment of the present disclosure.

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

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

[0020] 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 the present disclosure.

[0021] The advantages and features of the present disclosure, and methods for achieving them, will become clearer with reference to the embodiments described below in detail 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 is complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Like reference numerals designate like elements throughout the disclosure.

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

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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."

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

[0029] 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.

[0030] 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.

[0031] The present disclosure relates to a method and device for performing sidelink (hereinafter referred to as SL) positioning in a mobile communication system. More specifically, the present disclosure relates to a method and device for performing sidelink positioning (hereinafter referred to as SL-P) by a terminal within a base station communication range in a 3GPP 5GS (5G system).

[0032] The terms used in this disclosure may be defined as follows.

[0033] - Sidelink positioning (hereinafter referred to as SL-P):

[0034] Estimation of the terminal's position using a reference signal transmitted over SL (hereinafter referred to as SL-PRS for ease of explanation). The terminal's position can be absolute positioning information, relative positioning information, or ranging information (e.g., distance / direction information from another terminal). Ranging operations (estimation of distance / direction / relative position between terminals) can be included in the SL-P concept.

[0035] - Target UE: The terminal that is the target of location estimation.

[0036] Anchor UE: A terminal that assists in estimating the target UE's location. (For example, a terminal that transmits and receives reference signals for estimating the target UE's location, a terminal that transmits location-related information to the target UE via SL, etc.)

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

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

[0039] 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, the 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 them in order to service user traffic, thereby supporting a connection between the terminals and a core network (CN; in particular, the CN of NR is referred to as 5GC). Meanwhile, in communication, a user plane (UP) related to transmission of actual user data and a control plane (CP) such as connection management can be configured separately, and in this drawing, 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.

[0040] The above 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 the 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.

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

[0042] 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 the upper layer. In addition, the physical layer also uses HARQ (Hybrid ARQ) for additional error correction, and the receiver transmits 1 bit to indicate whether the packet transmitted by the transmitter was received. This is called HARQ ACK / NACK information. In the case of LTE, downlink HARQ ACK / NACK information for uplink data transmission is transmitted through the PHICH (Physical Hybrid-ARQ Indicator Channel) physical channel, 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 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 a physical channel, such as a PUCCH (Physical Uplink Control Channel) or a PUSCH (Physical Uplink Shared Channel). The PUCCH is typically transmitted on the uplink of the PCell, which will be described later. However, if the base station supports this, it may additionally transmit the PUCCH to the SCell, which will be described later, to the UE. This is referred to as a PUCCH SCell.

[0043] Although not shown in this drawing, 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.

[0044] Meanwhile, the above PHY layer can be composed of one or more frequencies / carriers, and the technology that sets and uses multiple frequencies simultaneously is called carrier aggregation (CA). CA technology can dramatically increase the transmission capacity by the number of secondary carriers by additionally using the primary carrier and one or more secondary carriers instead of using only one carrier for communication between a terminal (or User Equipment, UE) and a base station (E-UTRAN NodeB, eNB). 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).

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

[0046] Referring to FIG. 3, a network for providing LCS in a next-generation mobile communication system may include 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) through the base station (305) and the AMF (310), and exchanges information necessary for location estimation. The roles of each component for providing LCS are as follows.

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

[0048] Additionally, 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.

[0049] In addition, the AMF (310) may perform the role of instructing the provision of a location provision service by receiving an LCS Request message from an LCS requester and then forwarding it to the LMF (315). When the LMF (315) processes the location estimation request and responds with the location estimation result of the terminal, the AMF (310) may forward the result to the LCS requester.

[0050] In addition, 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) provides the terminal (300) with auxiliary information required for position estimation and signal measurement and receives the result value. At this time, the LPP (LTE Positioning Protocol) 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) can be used as a protocol for data exchange, and NRPPa can define a message standard to be exchanged between the base station (305) and the LMF (315).

[0051] FIG. 4 is a diagram illustrating a sidelink positioning service scenario according to one embodiment of the present disclosure.

[0052] Referring to FIG. 4 for the Sidelink Positioning (hereinafter referred to as SL-P) service scenario, three SL-P scenarios can be defined depending on whether the Target / Anchor UE is within the base station communication range (i.e., cell coverage of the base station).

[0053] First, among the three SL-P scenarios, the In-Coverage scenario (100) is explained.

[0054] - In-Coverage Scenario (400):

[0055] In-Coverage scenario (400) may be a scenario in which both the Target UE (403), which is a target of location estimation in SL-P, and the Anchor UE (405), which assists in location estimation, are within the communication range of the base station (410). At this time, the Target / Anchor UE may be connected to a cell operated by the base station and may be in a state in which communication is possible through the UU interface. At this time, the LMF (415) may exchange LPP messages with the Target / Anchor UE for SL-P operation and may participate in the SL-P operation. LPP messages between the LMF and the Target / Anchor UE may be transmitted and received through the UU interface with the base station.

[0056] For SL-P operation, the Target UE can transmit and receive SL-PRS with the Anchor UE through the PC5 interface. In addition, the Target UE and the anchor UE can transmit and receive SL-PRS and control messages for SL-P operation (e.g., SideLink Positioning Protocol, SLPP messages) through the PC5 interface. Mode 1 or Mode 2 can be used as a resource configuration method for sidelink (hereinafter referred to as “SL”) transmission of the Target / Anchor UE.

[0057] In the case of Mode 1, the SL transmission resources for SL-P operation can be directly allocated by the base station to the terminal. At this time, the SL transmission resources can be allocated from licensed carriers dedicated to SL communication or licensed carriers sharing resources between SL and UL transmission. When Mode 1 resource configuration is used, the Target / Anchor UE, which has been instructed to perform SL-P-related transmission (e.g., SL-PRS transmission) through SLPP signaling with the LMF or Server UE, can directly request the SL transmission resources required for the transmission from the base station (417). In this case, the base station can allocate the required SL transmission resources to the terminal according to the UE request (418).

[0058] When Mode 2 is used, the base station allocates a resource pool (sidelink resource pool) that can be used for SL transmission, and the Target / Anchor UE can directly select the transmission resources required for SL-P operation.

[0059] In Mode 1 and Mode 2 resource configurations, a shared resource pool or a dedicated resource pool can be configured as the SL resource pool for SL-P operation. Using a shared SL resource pool means that a resource pool configured for SL communication purposes is used to transmit SL-P-related information, and using a dedicated SL resource pool means that a resource pool configured individually for SL-P functionality is used to transmit SL-P-related information.

[0060] - Partial Coverage Scenario (420):

[0061] Partial Coverage Scenario (420) may be a scenario in which a Target UE (423), which is a target of location estimation in SL-P, is located outside the communication range of a base station (430), and an Anchor UE (425), which assists in location estimation, is located within the communication range of the base station (430). At this time, the Anchor UE may be connected to a Cell operated by the base station and may be able to communicate via a UU interface, and the Target UE may be able to communicate via an SL PC5 interface. At this time, the LMF (415) may exchange SLPP messages with the Target / Anchor UE for SL-P operation and may participate in the SL-P operation. SLPP messages between the LMF and the Anchor UE may be transmitted and received via the UU interface with the base station, and SLPP messages between the LMF and the Target UE may be exchanged by a message transfer operation of the Anchor UE. For example, an SLPP message sent by a Target UE to an LMF can be delivered to an Anchor UE via the PC5 interface, and then delivered to the network via the UU interface of the anchor UE.

[0062] For SL-P operation, the Target UE can transmit and receive SL-PRS with the Anchor UE through the PC5 interface. In addition, the Target UE and the anchor UE can exchange control messages for SL-PRS transmission and SL-P execution through the PC5 interface. Mode 1 or Mode 2 can be used as a resource configuration method for sidelink (hereinafter referred to as SL) transmission of the Target / Anchor UE.

[0063] In the case of Mode 1, the SL transmission resources for SL-P operation can be directly allocated by the base station to the terminal. At this time, the SL transmission resources can be allocated from licensed carriers dedicated to SL communication or licensed carriers sharing resources between SL and UL communication. When the Mode 1 resource configuration method is used, the Target / Anchor UE, which has been instructed to perform SL-P-related transmission (e.g., SL-PRS transmission) through SLPP signaling with the LMF or Server UE, can directly request the SL transmission resources required for SL-P-related transmission from the base station (437). In this case, the base station can allocate the required SL transmission resources according to the UE request (438).

[0064] When Mode 2 is used, the base station allocates a resource pool (sidelink resource pool) that can be used for SL transmission, and the Target / Anchor UE can directly select the transmission resources required for SL-P operation.

[0065] In Mode 1 and Mode 2 resource configurations, a shared resource pool or a dedicated resource pool can be configured as the SL resource pool for SL-P operation. Using a shared SL resource pool means that the resource pool configured for SL communication purposes is used to transmit SL-P-related information, and using a dedicated SL resource pool means that the resource pool configured individually for SL-P functionality is used to transmit SL-P-related information.

[0066] - Out-of-coverage scenario (440):

[0067] An out-of-coverage scenario (440) may be a scenario in which both the Target UE (443) and the Anchor UE (445), which are the target locations for SL-P, are located outside the base station communication range. At this time, both the Target UE and the Anchor UE may be unable to communicate with the base station via the UU interface, and the Target UE and the Anchor UE may be able to communicate only via the SL PC5 interface. At this time, the LMF cannot exchange SLPP messages with the Target UE and the Anchor UE for SL-P operation, and therefore cannot directly participate in the SL-P operation. For the SL-P operation, the Target UE can transmit and receive SL-PRS with the Anchor UE via the PC5 interface. In addition, the Target UE and the anchor UE can transmit and receive SL-PRS and control messages for SL-P execution via the PC5 interface. Mode 2 may be used as a resource configuration method for sidelink (hereinafter referred to as “SL”) transmission of the Target / Anchor UE.

[0068] When Mode 2 is used, the base station pre-allocates a resource pool (sidelink resource pool) that can be used for SL transmission (for example, this can be configured when within the base station communication range), and the Target / Anchor UE can directly select the transmission resources required for SL-P operation. A shared resource pool or a dedicated resource pool can be configured as the SL resource pool for SL-P operation. Using a shared SL resource pool means that the resource pool configured for SL communication purposes is used to transmit SL-P related information, and using a dedicated SL resource pool means that the resource pool configured individually for the SL-P function is used to transmit SL-P related information.

[0069] FIG. 5 is a diagram illustrating an example of a signal flow for allocating transmission resources of a side link in a wireless communication system according to various embodiments of the present disclosure.

[0070] More specifically, FIG. 5 illustrates signal exchange between a transmitting terminal (501), a receiving terminal (502), and a base station (503).

[0071] As described below, the method by which a base station allocates transmission resources for sidelink communication may be referred to as Mode 1. Mode 1 may be a method based on scheduled resource allocation by the base station. More specifically, in Mode 1 resource allocation, the base station may allocate resources used for sidelink transmission to RRC-connected terminals according to a dedicated scheduling method. Since the base station can manage sidelink resources, scheduled resource allocation is advantageous for interference management and resource pool management (e.g., dynamic allocation and / or semi-persistent transmission).

[0072] Referring to FIG. 5, in operation 507, a transmitting terminal (501) that is camping on a cell (505) may receive a sidelink SIB from a base station (503). In operation 509, a receiving terminal (502) may receive a sidelink SIB from a base station (503). Here, the receiving terminal (502) refers to a terminal that receives data transmitted by the transmitting terminal (501). The sidelink SIB may be transmitted to the terminal periodically or on demand. In addition, the sidelink SIB may include at least one of sidelink resource pool information for sidelink communication, parameter setting information for sensing operation, information for setting sidelink synchronization, or carrier information for sidelink communication operating at different frequencies. Although operations 507 and 509 have been described sequentially, this is for convenience of explanation, and operations 507 and 509 may be performed in parallel.

[0073] In operation 513, when data traffic for sidelink communication is generated in the transmitting terminal (501), the transmitting terminal (501) may establish an RRC connection with the base station (503). Here, the RRC connection between the transmitting terminal (501) and the base station (503) may be referred to as Uu-RRC. The Uu-RRC connection may be performed before the data traffic of the transmitting terminal (501) is generated. In addition, in case of mode 1, when a Uu-RRC connection is established between the base station (503) and the receiving terminal (502), the transmitting terminal (501) may perform transmission to the receiving terminal (502) via the sidelink. In addition, in case of mode 1, even when a Uu-RRC connection is not established between the base station (503) and the receiving terminal (502), the transmitting terminal (501) may perform transmission to the receiving terminal (502) via the sidelink.

[0074] In operation 515, a transmitting terminal (501) may request a transmission resource for performing sidelink communication with a receiving terminal (502) from a base station (503). At this time, the transmitting terminal (501) may request a transmission resource for the sidelink from the base station (503) using at least one of a physical uplink control channel (PUCCH), an RRC message, or a MAC CE. For example, when a MAC CE is used to request a transmission resource for the sidelink, the MAC CE may be a MAC CE for a buffer status report in a new format that includes at least one of an indicator for indicating that it is a buffer status report (BSR) for sidelink communication and information on the size of data stored in a buffer for device-to-device (D2D) communication (or V2X communication). Such a MAC CE may be referred to as a sidelink BSR MAC CE. Additionally, when PUCCH is used to request transmission resources for sidelink, the transmitting terminal (501) can request sidelink resources through bits of a scheduling request (SR) transmitted through an uplink physical control channel.

[0075] In addition, when RRC is used to request transmission resources for sidelink, the transmitting terminal (501) can transmit to the base station, through Uu-RRC, frequencies for transmission and reception of various types of sidelink communications including sidelink discovery, sidelink data communication, and sidelink relay communication, and information of the receiving terminal (502), and a request for transmission resources for sidelink including at least one of the following information can be transmitted through the same or different RRC messages.

[0076] * Frequency to be used for reception in sidelink communication

[0077] * Frequency to be used for transmission in sidelink communication

[0078] * Types of sidelink data transmitted in sidelink communication

[0079] * Period and size of sidelink data transmitted in sidelink communication

[0080] * Information on the target terminal receiving sidelink data transmitted in sidelink communication (target terminal ID, terminal capability, DRX information, etc.)

[0081] * QoS information of sidelink data transmitted in sidelink communication

[0082] * Cast type of sidelink data transmitted in sidelink communication

[0083] * RLC mode of sidelink data transmitted in sidelink communication

[0084] In operation 515, PUCCH, MAC CE, and RRC messages can be used independently or mixed together depending on the purpose. In addition, operation 515 is described after operation 513, but this is for convenience of explanation, and PUCCH, MAC CE, and RRC messages can also be used for requesting resources for the transmitting terminal (501) to establish PC5-RRC (511) with the receiving terminal (502), and the transmission operation of PUCCH, MAC CE, and RRC messages can be performed in parallel or simultaneously with other operations.

[0085] In operation 517, the base station (503) may transmit DCI (downlink control information) to the transmitting terminal (501) via the PDCCH. That is, the base station (503) may instruct the transmitting terminal (501) to perform final scheduling for sidelink communication with the receiving terminal (502). More specifically, the base station (503) may allocate sidelink transmission resources to the transmitting terminal (501) according to at least one of a dynamic grant (DG) method or a configured grant (CG) method.

[0086] In the case of the dynamic grant (DG) scheme, the base station (503) can allocate resources for one TB (transport block) transmission by transmitting DCI to the transmitting terminal (501). Sidelink scheduling information included in the DCI can include at least one of resource pool information, parameters related to initial transmission time and / or retransmission transmission time, or parameters related to a frequency allocation location information field. The DCI for the dynamic grant scheme can be CRC (cyclic redundancy check) scrambled based on a sidelink radio network temporary identifier (SL-RNTI) to indicate that the transmission resource allocation scheme is the dynamic grant scheme.

[0087] In the case of the configured grant (CG) scheme, resources for transmitting multiple TBs can be periodically allocated by setting a semi-persistent scheduling (SPS) interval in Uu-RRC. In this case, the base station (503) can allocate resources for the multiple TBs by transmitting a DCI to the transmitting terminal (501). The sidelink scheduling information included in the DCI can include at least one of a parameter related to an initial transmission occasion, a retransmission transmission occasion, or a parameter related to a frequency allocation location information field. In the case of the configured grant scheme, the initial transmission occasion and / or the retransmission transmission occasion and frequency allocation location can be determined according to the transmitted DCI, and the resources can be repeated at the SPS interval. The DCI for the configured grant scheme can be CRC scrambled based on the SL-CS-RNTI to indicate that the transmission resource allocation scheme is the configured grant scheme. Additionally, the configuration grant method can be divided into type 1 CG and type 2 CG. In the case of type 2 CG, the base station (503) can activate and / or deactivate the resources set by the configuration grant through DCI. Therefore, in the case of mode 1, the base station (503) can instruct the transmitting terminal (501) to perform the final scheduling for sidelink communication with the receiving terminal (502) by transmitting the DCI through the PDCCH.

[0088] When broadcast transmission is performed between terminals (501, 502), in operation 519, the transmitting terminal (501) can broadcast SCI to the receiving terminal (502) via the PSCCH without additional PC5-RRC configuration (operation 511). In addition, in operation 521, the transmitting terminal (501) can broadcast data to the receiving terminal (502) via the PSSCH.

[0089] When unicast or groupcast transmission is performed between terminals (501, 502), in operation 511, the transmitting terminal (501) can perform an RRC connection one-to-one with other terminals (e.g., the receiving terminal (502)). In this case, to distinguish it from Uu-RRC, the RRC connection between terminals (501, 502) can be referred to as PC5-RRC. In the case of groupcast transmission, the PC5-RRC connection can be individually established between terminals within a group. Referring to FIG. 5, although the PC5-RRC connection (operation 511) is depicted as an operation after the transmission of the sidelink SIB (operations 507 and 509), the PC5-RRC connection (step 911) may be performed before the transmission of the sidelink SIB or before the broadcast of the SCI (operation 519).

[0090] If an RRC connection between terminals is required, a PC5-RRC connection of the sidelink is performed, and in operation 519, the transmitting terminal (501) can transmit SCI to the receiving terminal (502) through the PSCCH as a unicast or groupcast. At this time, the groupcast transmission of the SCI can be understood as group SCI. In addition, in operation 521, the transmitting terminal (501) can transmit data to the receiving terminal (502) through the PSSCH as a unicast or groupcast. In the case of mode 1, the transmitting terminal (501) can identify sidelink scheduling information included in the DCI received from the base station (503) and perform scheduling for the sidelink based on the sidelink scheduling information. The SCI can be divided into a 1st-stage SCI transmitted through the PSCCH and a 2nd-stage SCI transmitted through the PSSCH, and the 1st-stage SCI can include at least one or more of the following information.

[0091] * Priority

[0092] * Frequency resource assignment

[0093] * Time resource allocation

[0094] * Resource reservation period

[0095] * DMRS (de-modulation reference signal) pattern

[0096] * 2nd-stage SCI format

[0097] * Beta_offset indicator

[0098] * Number of DMRS ports

[0099] * Modulation and coding scheme

[0100] * Additional MCS table indicators

[0101] * PSFCH overhead indication

[0102] * Reserved

[0103] * Conflict information receiver flag

[0104] Priority information can be transmitted from the upper layer, and can be included as a 3-bit priority value, such as 000 for 1 and 001 for 2.

[0105] The information field for indicating the reservation interval is indicated as a single value with a fixed interval between TBs when resources for multiple TBs (i.e., multiple MAC PDUs (protocol data units)) are selected, and when resources for one TB are selected, '0' can be indicated as the value of the interval between TBs.

[0106] The 2nd-stage SCI may be included in the PSSCH resource indicated in the 1st-stage SCI transmitted in operation 519, and is transmitted together with the data in operation 521. The 2nd-stage SCI may include at least one of the following information:

[0107] * HARQ process number

[0108] * New data indicator

[0109] * Redundancy version

[0110] * Source ID

[0111] * Destination ID

[0112] * HARQ feedback enabled / disabled indicator

[0113] * Cast type indicator

[0114] * CSI request

[0115] * Zone ID

[0116] * Communication range requirement

[0117] * Providing / Requesting indicator

[0118] * Resource combinations

[0119] * First resource location

[0120] * Reference slot location

[0121] * Resource set type

[0122] * Lowest subChannel indices

[0123] * Priority

[0124] * Number of subchannels

[0125] * Resource reservation period

[0126] * Resource selection window location

[0127] * Resource set type

[0128] * Padding bits

[0129] In operation 523, the receiving terminal (502) can transmit to the transmitting terminal (501) whether the demodulation / decoding of the data received in operation 521 was successful or not through the first HARQ feedback information. Here, the first HARQ feedback information includes ACK (success) or NACK (failure) information, and the receiving terminal (502) transmits the first HARQ feedback information to the transmitting terminal (501) through the PSFCH channel. In operation 525, the transmitting terminal (501) transmits the transmission result to the base station (503) as second HARQ feedback information based on the first HARQ feedback information received from the receiving terminal (502). The second HARQ feedback is transmitted to the base station through the PUCCH. At this time, the second HARQ feedback information may or may not be the same as the first HARQ feedback information.

[0130] In addition, the second HARQ feedback information may include a plurality of first HARQ feedback information. The plurality of first HARQ feedback information may include a plurality of HARQ feedback information received from one receiving terminal, or may include one or a plurality of HARQ feedback information received from multiple terminals. Through the second HARQ feedback information, the base station may be able to allocate resources for retransmission to the transmitting terminal (501), allocate resources for new transmission, or stop resource allocation when there are no more transmission resources to allocate to the transmitting terminal (501). The PUCCH (525) transmission resource may be determined by DCI information that the base station transmits to the transmitting terminal on the PDCCH (517). The PSFCH (523) transmission resource may be determined by the SCI of the PSCCH (519) or may be determined by a transmission resource region in which the PSSCH (521) is transmitted and received.

[0131] FIG. 6 is a diagram illustrating an example of a signal flow for performing a sidelink positioning service according to one embodiment of the present disclosure.

[0132] More specifically, FIG. 6 illustrates an example of a signal flow for requesting SL-PRS transmission and allocating SL-PRS transmission resources during sidelink-based position estimation (hereinafter referred to as SL-P) in a wireless communication system according to various embodiments of the present disclosure. FIG. 6 illustrates signal exchange between a server UE (600) controlling the overall SL-P procedure, an SL-PRS transmitting terminal (603), an SL-PRS receiving terminal (605), and a base station (607). In this drawing, for convenience of explanation, the terminals participating in the SL-P procedure are expressed as SL-PRS transmitting terminals or SL-PRS receiving terminals, but each terminal may perform SL-PRS transmission and SL-PRS reception simultaneously depending on the actual SL-PRS position estimation method. For example, the SL-P procedure of the SL-RTT scheme is a method of estimating the position of a target UE by calculating the distance between the terminals based on the time (round trip time) required for the SL-PRS to be transmitted / received between the two terminals (Target UE and Anchor UE) after the target UE transmits / receives SL-PRS to / from other terminals (Anchor UEs). In the SL-P procedure of the SL-RTT scheme, the target UE and anchor UE participating in the SL-P procedure may act as SL-PRS transmitting terminals and SL-PRS receiving terminals at the same time.

[0133] To perform SL-P, the Server UE can instruct the SL-PRS transmitting terminal to transmit SL-PRS through an SLPP message (620). In addition, the SL-PRS receiving terminal can also instruct the SL-PRS transmitting terminal to transmit SL-PRS through an SCI (640). The SL-PRS transmitting terminal can request the base station to allocate transmission resources required for SL-PRS transmission through a MAC CE (650) or a UAI message (653). The base station can allocate transmission resources required for SL-PRS transmission to the SL-PRS transmitting terminal through a DCI (655) or an RRCReconfiguration message (657).

[0134] In operation 610, terminals (600, 603, 605) participating in the SL-P procedure can perform a sidelink discovery procedure to identify each other's existence and create a PC5 connection between them. In FIG. 6, for convenience of explanation, the entity (100) controlling the SL-P procedure is illustrated as a Server UE, but the actual entity may be an LMF. In this case, a terminal that transmits an SLPP message transmitted by the LMF to a transmitting terminal (603) and a receiving terminal (605) performs a discovery procedure, creates a PC5 connection with other terminals (the transmitting terminal (603) and the receiving terminal (605)), and then transmits the SLPP message that the LMF intends to transmit / receive to the transmitting terminal (603) and the receiving terminal (605) to the transmitting terminal (603) and the receiving terminal (605). Therefore, in the case where the LMF controls the SL-P procedure instead of the Server UE, the SLPP message exchange operation between the Server UE (600) and the transmitting terminal (603) and the receiving terminal (605) illustrated in FIG. 6 can be equally applied to the SLPP message exchange between the LMF and the transmitting terminal (603) and the receiving terminal (605).

[0135] Thereafter, terminals (600, 603, 605) participating in the SL-P procedure can exchange terminal capability information related to the SL-P operation through the above discovery process and SLPP Capability transfer procedure.

[0136] In operation 620, the Server UE (600) may send an SLPP ProvideAssistanceData message to the transmitting terminal (603) to provide information required for SL-PRS transmission. If the transmitting terminal (603) needs to transmit multiple SL-PRSs to different receiving terminals, one or more SL-PRS assistance information (e.g., SL-PRS-AssistanceData IE) may be included in the SLPP ProvideAssistance Data message. In addition, the SL-PRS assistance information may include a combination of at least one of the following information required for SL-PRS transmission.

[0137] ● applicationLayerID: A value indicating the application layer ID of the terminal to which the SL-PRS-AssistanceData is applied. According to the current standard, this may mean the application layer ID of the SL-PRS transmission terminal (603).

[0138] ● SL-PRS-Sequence ID: ID value required when the transmitting terminal (603) generates an SL-PRS sequence for SL-PRS transmission. It can have an integer value from 0 to 4095.

[0139] ● SL-PRS-Priority: This is information used when a transmitting terminal (603) requests SL-PRS transmission resources from a base station using UE assistance information or MAC CE, and indicates the priority of each SL-PRS transmission. It can have an integer value from 1 to 8, with 1 representing the highest priority and 8 representing the lowest priority.

[0140] ● SL-PRS-DelayBudget: This is information used when a transmitting terminal (603) requests SL-PRS transmission resources from a base station using UE assistance information, and indicates the delay budget of each SL-PRS transmission. It can have an integer value from 0 to 1023, and the unit can be one of sec, msec, and 10 msec.

[0141] ● SL-PRS-BW: This is information used when a transmitting terminal (603) requests SL-PRS transmission resources from a base station using UE assistance information or MAC CE, and indicates the size of the bandwidth (BandWidth) required for each SL-PRS transmission. At this time, one of the options below can be used as a method for indicating the size of the required bandwidth.

[0142] - Option 1: The required bandwidth can be indicated in units of PRB (Physical resource blocks). For this purpose, a 9-bit INTEGER type field can be defined that indicates an integer value in the range of (10..275) to indicate values ​​from 10 PRB to 275 PRB. In addition, since indicating the required bandwidth in units of 1 PRB may excessively increase the signaling load for requesting SL-PRS transmission resources, an INTERGER type field can be defined to indicate the required bandwidth value in units of N PRBs to solve the problem of excessively increasing the signaling load. In this case, when N is 4, field value 1 ('0000000') can indicate 10 PRBs, 2 ('0000001') can indicate 14 PRBs, and 3 ('0000010') can indicate 18 PRBs, and a 7-bit INTEGER type can be used. For reference, 1 PRB corresponds to 12 REs (Resource Elements), and the bandwidth occupied by each RE may be equal to the Subcarrier Spacing (SCS). Therefore, when the Server UE indicates the required bandwidth in PRB units, the required bandwidth may differ depending on which SCS value (e.g., 15 kHz, 30 kHz, 60 kHz, 120 kHz, 480 kHz, 960 kHz) the UE receiving the information calculates the required bandwidth based on, which may cause ambiguity. That is, even if the same number of PRBs is indicated to the UE, the required bandwidth value calculated based on the SCS value of 15 kHz and the required bandwidth value calculated based on the SCS value of 30 kHz may be different. To solve the problem that the value of the required bandwidth calculated according to the SCS value varies, in addition to the value for the required bandwidth PRB, an SCS value (e.g., 15 kHz, 30 kHz, 60 kHz, 120 kHz, 480 kHz, 960 kHz) that serves as a basis for calculating the required bandwidth value can be indicated together.Alternatively, the SCS value that serves as the basis for calculating the required bandwidth value may be specified in the specification. For example, the SCS value of the current serving cell SSB of the terminal that received information on the value for the required bandwidth PRB may be specified in the specification to serve as the basis for calculating the required bandwidth.

[0143] - Option 2: The required bandwidth can be indicated in MHz units. To eliminate the ambiguity that arises in Option 1, the required bandwidth can be indicated in MHz units. In this case, a field defined as an integer type can be used to indicate the required bandwidth in 1MHz units. Alternatively, to reduce signaling load, a field of the ENUMERATED type can be defined to indicate one of several bandwidth candidate values ​​(e.g., mhz5, mhz10, mhz15, mhz20, mhz25, mhz30, mhz35, mhz40, mhz45, mhz50, mhz60, mhz70, mhz80, mhz90, mhz100, etc.). In addition, as the requirement for improving the position estimation accuracy of the terminal increases in the future, SL-P performance in the FR2-2 band (i.e., the band above 71GHz) may become necessary. At this time, since higher bandwidth values ​​can be introduced, fields defined as ENUMERATED type can be defined to include spare values ​​or extension marks (i.e., '...' in the ASN.1 code) so that necessary values ​​can be added in the future. By introducing a device for adding necessary values ​​in the future (including spare values ​​and adding extension marks) as described above, problems such as defining a new separate field and adding unnecessary signaling load when a new value needs to be added in the future can be prevented in advance.

[0144] ● SL-PRS-Tx-triggering indicator: The Server UE (600) can transmit a ProvideAssistanceData message (620) including the information (SL-PRS sequence ID, SL-PRS-Priority, SL-PRS-DelayBudget, SL-PRS-BW, etc.) necessary for transmission of the SL-PRS described above to the SL-PRS transmitting terminal (603). At this time, the Server UE (600) can instruct the SL-PRS transmitting terminal (603) whether to immediately trigger SL-PRS transmission using the information necessary for transmission of the SL-PRS, or to store the information necessary for transmission of the SL-PRS and use it when another terminal triggers SL-PRS transmission of the transmitting terminal (603) via SCI. The operation of another terminal triggering the SL-PRS transmission of the transmitting terminal (603) via SCI is specifically described in operation 640 below. In order to indicate whether the transmission of the SL-PRS of the SL-PRS transmitting terminal (603) is immediately triggered, a separate indicator (e.g., SL-PRS-Tx-triggering) may be set in the SL-PRS-AssistanceData unit. If the indicator for indicating whether the transmission of the SL-PRS of the SL-PRS transmitting terminal (603) is immediately triggered is not introduced, after the transmitting terminal (603) receives the ProvideAssistanceData message (620), it may be difficult to determine whether the information necessary for the SL-PRS transmission included in the SL-PRS-AssistanceData unit in the ProvideAssistanceData message (620) is provided in advance for the transmission of the SL-PRS to be triggered later, or for immediately triggering the SL-PRS transmission.To resolve this ambiguity, a 1-bit indicator may be included in the ProvideAssistanceData message to explicitly indicate to the terminal whether or not SL-PRS transmission should be triggered. If SL-PRS triggering is indicated by the indicator, the SL-PRS transmitting terminal (603) may (immediately) trigger SL-PRS transmission after receiving the ProvideAssistanceData message. Conversely, if SL-PRS triggering is not indicated by the indicator, the SL-PRS transmitting terminal (603) may store the SL-PRS-AssistanceData information included in the ProvideAssistanceData message after receiving the ProvideAssistanceData message and may not trigger SL-PRS transmission.

[0145] Additionally, the indicator may be commonly included (i.e., included within the CommonSL-PRS-MethodsIEsProvideAssistanceData IE) regardless of the position estimation technique used for SL-P. Alternatively, considering that SL-PRS transmission triggering via SCI is mainly used for the SL-RTT position estimation method in which terminals must exchange SL-PRS with each other, the indicator may be set only for a specific position estimation technique. For example, rather than being included in the configuration information that is applied regardless of the position estimation technique used for SL-P, the indicator may be separately included in the assistance information for the SL-RTT position estimation technique (within the SL-RTT-ProvideAssistanceData IE).

[0146] ● SL-PRS-TxTime: The Server UE (600) may transmit the ProvideAssistanceData message to instruct the transmitting terminal (603) to start (trigger) SL-PRS transmission. At this time, time information for indicating a specific time at which SL-PRS transmission should be started or performed may be set for each SL-PRS-AssistanceData included in the ProvideAssistanceData. The field for indicating the SL-PRS transmission start time information may be defined to indicate the SL-PRS transmission start time according to at least one of the following options.

[0147] - Option 1: Specify an absolute time value in UTC time format. This can be specified using the existing UTCTime IE.

[0148] - Option 2: Indicate based on system frame timing. This can be done using the existing SL-TimeStamp IE.

[0149] - Option 3: Instructs transmission to begin after a specific time difference from the time ProvideAssistanceData is received. The time difference information can be specified in units such as seconds, minutes, or hours.

[0150] Additionally, if the SL-PRS-TxTime field is introduced, the SL-PRS-Tx-triggering indicator for indicating whether to trigger SL-PRS transmission of the transmitting terminal (603) described above may not be necessary. For example, if the SL-PRS-TxTime field is included in SL-PRS-AssistanceData in the ProvideAssistanceData message, the SL-PRS transmitting terminal that has received the ProvideAssistanceData message can trigger SL-PRS transmission at the time indicated by the SL-PRS-TxTime field. Conversely, if the ProvideAssistanceData message does not include the SL-PRS-TxTime field, the SL-PRS transmitting terminal that has received the ProvideAssistanceData message can store only the information necessary for SL-PRS transmission included in the ProvideAssistanceData message, and wait until SL-PRS transmission is triggered later via SCI. Accordingly, when the SL-PRS-TxTime field is introduced, there may be no need for an indicator to explicitly indicate whether SL-PRS transmission should be triggered.

[0151] ● Information for Periodic SL-PRS Transmission: Repeated SL-PRS transmission and measurement may be required to improve position estimation accuracy when performing SL-P. To this end, the Server UE (600) may instruct the SL-PRS transmitting terminal (603) to periodically transmit SL-PRS. To instruct periodic SL-PRS transmission, at least one of the following information may be included in the ProvideAssistanceData message as a SL-PRS-AssistanceData unit.

[0152] - Periodic SL-PRS Tx indicator: A 1-bit indicator may be included to indicate whether SL-PRS transmission should be performed periodically. In addition, in order to reduce signaling overhead, if information such as the SL-PRS transmission period and the number of SL-PRS transmissions below is included, this indicator may be omitted in the ProvideAssistanceData message, and a terminal that receives a ProvideAssistanceData message in which this indicator is omitted and information such as the SL-PRS transmission period and the number of SL-PRS transmissions below is included may expect that SL-PRS transmission should be performed periodically.

[0153] - SL-PRS Transmission Cycle: Information indicating the SL-PRS transmission cycle may be included. At this time, the transmission cycle may be set in units of msec, sec, minute, hour, frame, slot, and symbol.

[0154] - SL-PRS transmission count: Information indicating the number of times SL-PRS transmission will be performed may be included.

[0155] - SL-PRS transmission start time information: Information indicating the start time of periodic SL-PRS transmission may be included. At least one of the options described in the SL-PRS-TxTime report may be used as a method for indicating the start time of transmission. Alternatively, the SL-PRS-TxTime field described above may be reused without defining a new field.

[0156] - SL-PRS transmission end time information: Information indicating the end time of periodic SL-PRS transmission may be included. At least one of the options described in the SL-PRS-Tx time information may be used as a method for indicating the end time of transmission.

[0157] - SL-PRS Transmission Duration: Information indicating the length of time (duration) for which periodic SL-PRS transmissions should be performed may be included. The information may be set in units of msec, sec, minute, hour, frame, slot, and symbol.

[0158] ● RxUE-ID: When the Server UE (600) instructs the SL-PRS transmitting terminal (603) to transmit SL-PRS through the ProvideAssistanceData message, it may include the ID value (application ID or L2 ID) of the terminal (605) that will receive the SL-PRS. For reference, when the transmitting terminal (603) requests SL-PRS transmission resources in operations 630 and 650 described below, it may request each SL-PRS transmission resource for each receiving terminal based on the ID value of the receiving terminal (605). Therefore, a field for indicating the ID of the SL-PRS receiving terminal (605) per SL-PRS-AssistanceData may be newly defined in the ProvideAssistanceData message. Alternatively, considering the signaling load, the meaning of the applicationLayerID field, which is a value indicating the application layer ID of the terminal to which SL-PRS-AssistanceData is applied, may be redefined as in Table 1 below. The redefined applicationLayerID field may mean that it indicates the ID of the SL-PRS receiving terminal if the SL-PRS-AssistanceData in the ProvideAssistanceData message contains information required for SL-PRS transmission (i.e., SL-PRS-TxInfo), and otherwise it indicates the ID of the SL-PRS transmitting terminal.

[0159] applicationLayerIDThis field provides the application layer ID as defined in TS 23.287 [9] for which the SL-PRS-AssistanceData is applicable.The application layer ID is used to identify a SL-PRS Rx UE (or anchor UE) when SL-PRS-TxInfo is present. Otherwise, it is used to indentify a SL-PRS Tx UE.

[0160] If the ProvideAssistanceData message includes SL-PRS-TxInfo, this means that the ProvideAssistanceData message is used by the Server UE (600) to provide the SL-PRS transmitting terminal (603) with information necessary for SL-PRS Tx, and therefore, the ProvideAssistanceData message does not need to include the application ID of the SL-PRS transmitting terminal (603). Accordingly, if the ProvideAssistanceData message includes SL-PRS-TxInfo, the applicationLayerID field can be used to indicate the application ID of the SL-PRS receiving terminal (605). Meanwhile, if the Server UE (600) transmits ProvideAssistanceData for the purpose of providing the SL-PRS receiving terminal (605) with information necessary for SL-PRS reception, as in operation 622 described below, the receiving terminal (605) must know the ID of the transmitting terminal (603) to receive the SL-PRS. Therefore, in this case, the applicationLayerID field can be used to indicate the application ID of the SL-PRS transmitting terminal (603).

[0161] In operation 622, the Server UE (600) may transmit SLPP ProvideAssistanceData to the SL-PRS receiving terminal (605) to provide information necessary for SL-PRS reception. At this time, if the SL-PRS receiving terminal (605) needs to receive multiple SL-PRSs from different transmitting terminals, one or more SL-PRS assistance information (e.g., SL-PRS-AssistanceData IE) may be included in the SLPP ProvideAssistanceData message. In addition, the SL-PRS assistance information may include a combination of at least one of the following information necessary for SL-PRS reception.

[0162] ● applicationLayerID: A value indicating the application layer ID of the terminal to which the SL-PRS-AssistanceData is applied. According to the current standard, it refers to the application layer ID of the SL-PRS transmission terminal (603).

[0163] ● SL-PRS-Sequence ID: This refers to the ID value used by the transmitting terminal (603) when generating the SL-PRS sequence for SL-PRS transmission. It can have an integer value from 0 to 4095. The SL-PRS receiving terminal (605) can identify the sequence used by the transmitting terminal (603) when transmitting SL-PRS based on the ID value, and can detect SL-PRS reception using the sequence.

[0164] In step 625, the Server UE (600) may transmit an SLPP RequestLocationInformation message to the SL-PRS receiving terminal (605) to instruct the SL-PRS receiving terminal (605) to receive the SL-PRS and report the measurement result value. The SL-PRS receiving terminal (605) instructed to receive the SL-PRS and report the measurement result value through the RequestLocationInformation message may receive the necessary SL-PRSs by utilizing the information required for SL-PRS reception provided from the Server UE (600) in step 622.

[0165] In operation 630, the SL-PRS transmitting terminal (603) may transmit a SidelinkUEInformationNR message to the base station (607) to request Sidelink Tx resource pool configuration required for SL-PRS transmission. To this end, a list (e.g., SL-PosTxResourceReqList) including one or more SL-PRS transmission resource requests (e.g., SL-PosTxResourceReq IE) may be included in the SidelinkUEInformationNR message. Each SL-PRS resource request information (e.g., SL-PosTxResourceReq IE) included in the list may include at least one of the following parameters.

[0166] □ sl-PosDestinationIdentity: Indicates the destination of the requested / allocated SL-PRS transport resource.

[0167] □ sl-PosCastType: Cast type corresponding to the destination of the requested SL-PRS transmission resource.

[0168] □ sl-PosQoS-InfoList: A list of QoS (Quality of Service) information corresponding to the requested SL-PRS transmission resource. Each QoS information included in the list may include SL-PRS transmission priority and SL-PRS transmission DelayBudget information.

[0169] The SL-PRS transmission terminal (603) can determine the sl-PosDestinationIdentity and SL-PRS QoS information in the SidelinkUEInformationNR message based on the information (e.g., RxUE-ID, SL-PRS-priority, SL-PRS-DelayBudget, etc.) required for SL-PRS transmission included in the SLPP ProvideAssistanceData message received from the Sever UE (600) in operation 620.

[0170] In operation 633, the base station (607) may transmit an RRCReconfiguration message including resource pool configuration information (e.g., SL-PRS-TxPoolDedicated IE) for SL-PRS transmission to the SL-PRS transmission terminal (603).

[0171]

[0172] In operation 640, the SL-PRS receiving terminal (605) can instruct the SL-PRS transmitting terminal (603) to trigger SL-PRS transmission via SCI. For this purpose, a 1-bit indicator for a SL-PRS transmission request (e.g., SL PRS request) can be included in the SCI. The SCI information can be provided to the transmitting terminal (603) in two stages, 1st SCI and 2nd SCI, as in operations 519 and 521 of FIG. 5. In FIG. 6, for convenience of explanation, the SCI information provided in two stages is expressed as one SCI (640). The SL-PRS transmitting terminal (603) that has been instructed to transmit SL-PRS through SCI (640) sent by the SL-PRS receiving terminal (605) can recognize the ID of the SL-PRS receiving terminal (605) that requests SL-PRS transmission based on the Source ID in the SCI.

[0173] Thereafter, the SL-PRS transmitting terminal (603) can find the SL-PRS assistance information corresponding to the SL-PRS receiving terminal that transmitted the SCI among the SL-PRS assistance information (e.g., SL-PRS-AssistanceData IE) included in the ProvideAssistanceData received from the Server UE (600) in operation 620. More specifically, the SL-PRS transmitting terminal (603) can compare the applicationLayerID (or RxUE-ID when a new RxUE-ID is introduced) included in each SL-PRS assistance information with the Source ID (or application ID corresponding to the Source ID) in the SCI to find the SL-PRS assistance information that matches each other. Thereafter, the SL-PRS transmitting terminal (603) can perform the SL-PRS transmission resource request operation in the following operations 650 and 653 based on the information required for SL-PRS transmission (e.g., SL-PRS-priority, SL-PRS-DelayBudget, etc.) included in the SL-PRS auxiliary information corresponding to the SL-PRS receiving terminal that transmitted the SCI.

[0174] Meanwhile, if there are multiple pieces of auxiliary information corresponding to the Source ID in the SCI among the SL-PRS auxiliary information included in the ProvideAssistanceData received from the Server UE (600) in step 620, it may be difficult for the SL-PRS transmitting terminal (603) to determine which of the multiple pieces of SL-PRS auxiliary information corresponding to the Source ID in the SCI should use the information (information required for SL-PRS transmission) included in the SL-PRS auxiliary information. In order to eliminate ambiguity when there are multiple pieces of SL-PRS auxiliary information corresponding to the Source ID in the SCI, if the SL-PRS auxiliary information (e.g., SL-PRS-AssistanceData IE) included in the SLPP ProvideAssistanceData includes information required for SL-PRS transmission, a constraint may be added so that there is only one piece of SL-PRS auxiliary information corresponding to the same applicationLayerID (or RxUE-ID if RxUE-ID is newly introduced). Alternatively, if there are multiple pieces of auxiliary information corresponding to the Source ID in the SCI among the SL-PRS auxiliary information included in the ProvideAssistanceData, a new field (e.g., RequestByLowerLayerSignalingAllowed) may be defined in the SL-PRS auxiliary information (e.g., SL-PRS-AssistanceData IE) to explicitly indicate that only one of the multiple pieces of auxiliary information corresponding to the Source ID is to be used when SL-PRS transmission is triggered from the lower layer.That is, among the multiple auxiliary information corresponding to the Source ID, only one auxiliary information to be used when SL-PRS transmission is triggered from a lower layer can include the new field (e.g., RequestByLowerLayerSignalingAllowed), and only one auxiliary information including the new field can be used when SL-PRS transmission is triggered.

[0175] In operation 650, the SL-PRS transmission terminal (603) can request allocation of operation resources required for SL-PRS transmission by transmitting an SL-PRS Resource Request MAC CE to the base station (607). The MAC CE may include information required for the resource request, such as an SL-PRS Destination index, SL-PRS Priority, and SL-PRS Bandwidth, and a detailed description of each piece of information will be described later with reference to FIG. 7.

[0176] In operation 620, when SL-PRS transmission is triggered through SL-PRS assistance information (SL-PRS-AssistanceData) included in the ProvideAssistanceData message transmitted by the Server UE (600), the SL-PRS transmission terminal (603) can set information (such as SL-PRS Destination index, SL-PRS Priority, and SL-PRS Bandwidth) within the MAC CE based on information required for SL-PRS transmission (such as applicationID, SL-PRS-prirority, and SL-PRS-DelayBudget) included in the SL-PRS assistance information.

[0177] In operation 640, if SL-PRS transmission is triggered by SCI transmitted by the SL-PRS receiving terminal (605), the SL-PRS transmitting terminal (603) can find SL-PRS assistance information (SL-PRS-AssistanceData) corresponding to the SL-PRS receiving terminal (605) that transmitted the SCI as described in operation 640. Thereafter, the SL-PRS transmitting terminal (603) can set information (such as SL-PRS Destination index, SL-PRS Priority, and SL-PRS Bandwidth) within the MAC CE based on information required for SL-PRS transmission (such as applicationID, SL-PRS-priority, and SL-PRS-DelayBudget) included in the corresponding SL-PRS assistance information.

[0178] In operation 653, the SL-PRS transmitting terminal (603) can request resources required for periodic SL-PRS transmission by transmitting a UEAssistanceInformation (UAI) message (653) to the base station (607). More specifically, periodic SL-PRS transmission can be triggered through SL-PRS assistance information (SL-PRS-AssistanceData) included in the ProvideAssistanceData message transmitted by the Server UE (600) in operation 620. At this time, the SL-PRS transmission terminal (603) may request resources required for periodic SL-PRS transmission by including information required for periodic SL-PRS transmission (e.g., SL-PRS-Periodicity, SL-PRS-priority, SL-PRS-DelayBudget, SL-PRS-Bandwidth) included in the SL-PRS auxiliary information in a UAI message and transmitting it to the base station (107). The SL-PRS-Bandwidth field indicates the size of the bandwidth (BandWidth) required for each SL-PRS transmission. At this time, one of the following methods may be used as a method for indicating the size of the required bandwidth.

[0179] - Option 1: The required bandwidth can be indicated in units of PRB (Physical resource blocks). For this purpose, a 9-bit INTEGER type field can be defined that indicates an integer value in the range of (10..275) to indicate values ​​from 10 PRB to 275 PRB. In addition, since indicating the required bandwidth in units of 1 PRB may excessively increase the signaling load for requesting SL-PRS transmission resources, an INTERGER type field can be defined to indicate the required bandwidth value in units of N PRBs to solve the problem of excessively increasing the signaling load. In this case, when N is 4, field value 1 ('0000000') can indicate 10 PRBs, 2 ('0000001') can indicate 14 PRBs, and 3 ('0000010') can indicate 18 PRBs, and a 7-bit INTEGER type can be used. For reference, 1 PRB corresponds to 12 REs (Resource Elements), and the bandwidth occupied by each RE may be equal to the Subcarrier Spacing (SCS). Therefore, when the Server UE indicates the required bandwidth in PRB units, the required bandwidth may differ depending on which SCS value (e.g., 15 kHz, 30 kHz, 60 kHz, 120 kHz, 480 kHz, 960 kHz) the UE receiving the information calculates the required bandwidth based on, which may cause ambiguity. That is, even if the same number of PRBs is indicated to the UE, the required bandwidth value calculated based on the SCS value of 15 kHz and the required bandwidth value calculated based on the SCS value of 30 kHz may be different. To solve the problem that the value of the required bandwidth calculated according to the SCS value varies, in addition to the value for the required bandwidth PRB, an SCS value (e.g., 15 kHz, 30 kHz, 60 kHz, 120 kHz, 480 kHz, 960 kHz) that serves as a basis for calculating the required bandwidth value can be indicated together.Alternatively, the SCS value that serves as the basis for calculating the required bandwidth value may be specified in the specification. For example, the SCS value of the current serving cell SSB of the terminal that received information on the value for the required bandwidth PRB may be specified in the specification to serve as the basis for calculating the required bandwidth.

[0180] - Option 2: The required bandwidth can be indicated in MHz units. To eliminate the ambiguity that arises in Option 1, the required bandwidth can be indicated in MHz units. In this case, a field defined as an integer type can be used to indicate the required bandwidth in 1MHz units. Alternatively, to reduce signaling load, a field of the ENUMERATED type can be defined to indicate one of several bandwidth candidate values ​​(e.g., mhz5, mhz10, mhz15, mhz20, mhz25, mhz30, mhz35, mhz40, mhz45, mhz50, mhz60, mhz70, mhz80, mhz90, mhz100, etc.). In addition, as the requirement for improving the position estimation accuracy of the terminal increases in the future, SL-P performance in the FR2-2 band (i.e., the band above 71GHz) may become necessary. At this time, since higher bandwidth values ​​can be introduced, fields defined as ENUMERATED type can be defined to include spare values ​​or extension marks (i.e., '...' in the ASN.1 code) so that necessary values ​​can be added in the future. By introducing a device for adding necessary values ​​in the future (including spare values ​​and adding extension marks) as described above, problems such as defining a new separate field and adding unnecessary signaling load when a new value needs to be added in the future can be prevented in advance.

[0181] In operation 655, the base station (607) can dynamically allocate resources required for SL-PRS transmission to the SL-PRS transmitting terminal (603) in a DG (Dynamic grant) manner by transmitting DCI. More specifically, the base station (607) can receive the MAC CE sent by the SL-PRS transmitting terminal (603) in operation 650 and identify the SL-PRS transmission resource request of the transmitting terminal (603). Thereafter, the base station can perform SL-PRS transmission resource allocation required for the SL-PRS transmitting terminal (603) based on information (SL-PRS Destination index, SL-PRS Priority, SL-PRS Bandwidth) in the MAC CE received from the transmitting terminal (603).

[0182] In operation 657, the base station (607) can allocate resources required for periodic SL-PRS transmission to the SL-PRS transmitting terminal (603) in a CG (Configured grant) manner by transmitting an RRCReconfiguration message. More specifically, in operation 653, the base station (607) can receive a UEAssistanceInformation (hereinafter referred to as “UAI”) message sent by the SL-PRS transmitting terminal (603) and identify an SL-PRS transmission resource request of the SL-PRS transmitting terminal (603). Thereafter, the base station can perform SL-PRS transmission resource allocation required for the SL-PRS transmitting terminal (603) based on the information (SL-PRS Destination index, SL-PRS Priority, SL-PRS Bandwidth) in the UAI.

[0183] In operation 660, the SL-PRS transmitting terminal (603) can perform SL-PRS transmission. More specifically, the SL-PRS transmitting terminal (603) can be requested to perform SL-PRS transmission through operations 620 and 640 and can trigger SL-PRS transmission. Thereafter, in order to be allocated SL-PRS transmission resources, the SL-PRS transmitting terminal (603) can request SL-PRS transmission resource allocation to the base station (607) through operations 650 and 653. Thereafter, the SL-PRS transmitting terminal (603) can be allocated transmission resources required for SL-PRS transmission from the base station (607) through operations 655 and 657 and can perform SL-PRS transmission using the allocated resources. In Fig. 6, for convenience of explanation, the SL-PRS transmission of the SL-PRS transmitting terminal (603) is illustrated only once, but if periodic SL-PRS transmission is requested, the SL-PRS transmission of the SL-PRS transmitting terminal (603) may be performed multiple times. The SL-PRS receiving terminal (605) may receive the SL-PRS as instructed by the Server UE (600) through the RequestLocationInformation message in operation 625 and calculate the necessary measurement values.

[0184] In operation 670, the SL-PRS receiving terminal (605) can transmit the SL-PRS measurement result value to the Server UE (600) through the SLPP ProvideLocationInformation message. More specifically, in operation 625, the SL-PRS receiving terminal (605) can report the requested SL-PRS measurement result value to the Server UE (600) as instructed by the Server UE (600) through the SLPP RequestLocationInformation message.

[0185] FIG. 7 is a diagram illustrating an example of a MAC CE structure used when allocating SL-PRS transmission resources in a dynamic grant manner according to one embodiment of the present disclosure.

[0186] When MAC CE is used as an SL-PRS transmission resource request message as in operation 650 of the above-mentioned FIG. 6, the MAC CE for the SL-PRS transmission resource request may be defined as 700. At this time, an (e)LCID value corresponding to the MAC CE (700) may be defined together. The MAC CE may include the following field values.

[0187] * Destination Index (701): In operation 630 of FIG. 6, the index value of the entry included in the sl-PRS-ResourceReqList included in the SidelinkUEInformationNR message of the terminal may be included in the Destination Index (701) field. If the base station indicates the destination with the Entry index value, the terminal may interpret the sl-DestinationIdentity in the SL-PRS-ResourceRequest IE corresponding to the index as the destination ID. A 5-bit field may be included in the MAC CE to indicate the destination index value.

[0188] * SL-PRS priority (703): A 3-bit field may be included in the MAC CE to indicate the priority of SL-PRS transmissions waiting to be transmitted.

[0189] * SL-PRS BW (705): The size of the (minimum) bandwidth (BW, Bandwidth) required for SL-PRS transmission waiting for transmission may be included in the MAC CE. Since the accuracy of sidelink positioning varies depending on the size of the BW in which the SL-PRS is transmitted, the requirement for SL-PRS bandwidth may be set to the terminal by upper layer signaling (SLPP), as in operation 620 of FIG. 6, and the terminal may include information about the requirement for SL-PRS bandwidth when requesting SL-PRS transmission resources. Since there may be cases where there is no requirement for SL-PRS transmission BW, the SL-PRS BW (705) field may be defined as an optional field. The specific encoding method of the SL-PRS BW (705) field may be the same as the SL-PRS-Bandwidth field included in the UEAssistanceInformation message of operation 653 of FIG. 6.

[0190] When the MAC CE of the 700 structure of FIG. 7 is used, the MAC CE can be configured to include multiple Destination Indexes (701) and corresponding additional information (703, 705) in order to support a terminal requesting allocation of one or more SL-PRS transmission resources through a single MAC CE transmission.

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

[0192] Referring to FIG. 8, the terminal may include an RF (Radio Frequency) processing unit (810), a baseband processing unit (820), a storage unit (830), and a control unit (840). The configuration of the terminal is not limited to the exemplary configuration illustrated in FIG. 8, and may include fewer or more configurations than the configuration illustrated in FIG. 8.

[0193] The RF processing unit (810) 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 (810) may up-convert a baseband signal provided from the baseband processing unit (820) into an RF band signal and 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 (810) may 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. 2, only one antenna is illustrated, but the terminal may be equipped with multiple antennas. In addition, the RF processing unit (810) may include multiple RF chains. Furthermore, the RF processing unit (810) may perform beamforming. For beamforming, the RF processing unit (810) can adjust the phase and magnitude of each signal transmitted and received through multiple antennas or antenna elements. In addition, the RF processing unit (810) can perform MIMO and receive multiple layers when performing MIMO operations.

[0194] The baseband processing unit (820) 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 (820) can generate complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit (820) can restore a reception bit stream by demodulating and decoding a baseband signal provided from the RF processing unit (810). For example, in the case of following the OFDM (orthogonal frequency division multiplexing) method, when transmitting data, the baseband processing unit (820) 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 (820) divides the baseband signal provided from the RF processing unit (810) into OFDM symbol units, restores signals mapped to subcarriers through FFT (fast Fourier transform) operation, and then restores the received bit string through demodulation and decoding.

[0195] The baseband processing unit (820) and the RF processing unit (810) can transmit and receive signals as described above. Accordingly, the baseband processing unit (820) and the RF processing unit (810) may be referred to as a transmitter, a receiver, a transceiver, or a communication unit. Furthermore, at least one of the baseband processing unit (820) and the RF processing unit (810) 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 (820) and the RF processing unit (810) 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 (820) and the RF processing unit (810), and the signals may include control information and data.

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

[0197] The storage unit (830) 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 (830) may be configured as a plurality of memories. According to one embodiment of the present disclosure, the storage unit (830) may store a program for performing a handover method according to the present disclosure.

[0198] The control unit (840) can control the overall operations of the terminal. For example, the control unit (840) can transmit and receive signals through the baseband processing unit (820) and the RF processing unit (810).

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

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

[0201] The base station of FIG. 9 may be included in the aforementioned network.

[0202] As illustrated in FIG. 9, the base station may include an RF processing unit (910), a baseband processing unit (920), a backhaul communication unit (930), a storage unit (940), and a control unit (950). The configuration of the base station is not limited to the exemplary configuration illustrated in FIG. 3, and the base station may include fewer or more configurations than the configuration illustrated in FIG. 3. The RF processing unit (910) 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 (910) may up-convert a baseband signal provided from the baseband processing unit (920) 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 (910) may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, and the like. In FIG. 3, only one antenna is illustrated, but the RF processing unit (910) may be equipped with multiple antennas. In addition, the RF processing unit (910) may include multiple RF chains. Furthermore, the RF processing unit (910) may perform beamforming. For beamforming, the RF processing unit (910) may adjust the phase and magnitude of each signal transmitted and received through the multiple antennas or antenna elements. The RF processing unit (910) may perform a downlink MIMO operation by transmitting one or more layers.

[0203] The baseband processing unit (920) 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 (920) can generate complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit (920) can restore the reception bit stream by demodulating and decoding the baseband signal provided from the RF processing unit (910). For example, in the case of following the OFDM method, when transmitting data, the baseband processing unit (920) 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 (920) can divide the baseband signal provided from the RF processing unit (910) 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 (920) and the RF processing unit (910) can transmit and receive signals as described above. Accordingly, the baseband processing unit (920) and the RF processing unit (910) 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 (920) and the RF processing unit (910), and the signals may include control information and data.

[0204] The backhaul communication unit (930) may provide an interface for communicating with other nodes within the network. For example, the backhaul communication unit (930) may convert a bit stream transmitted from the 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.

[0205] The storage unit (940) 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 (940) can store information on bearers assigned to connected terminals, measurement results reported from connected terminals, etc. In addition, the storage unit (940) 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 (940) can provide the stored data according to a request from the control unit (950). The storage unit (940) 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 (940) can be configured as a plurality of memories. According to one embodiment of the present disclosure, the storage unit (940) can also store a program for performing a handover according to the present disclosure.

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

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

[0208] 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 claims or embodiments of the present disclosure.

[0209] 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.

[0210] Additionally, the program may be stored in 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.

[0211] 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.

[0212] 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.

[0213] 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.

[0214] In the specific embodiments of the present disclosure described above, components included in the disclosure 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.

[0215] Meanwhile, the embodiments of the present disclosure disclosed in this disclosure and the 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, the above-described embodiments 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 are applicable to other communication systems, and other modified examples based on the technical idea of ​​the embodiments may also be implemented. For example, the embodiments may 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 defined not only by the scope of the following claims but also by equivalents thereof.

Claims

1. A method performed by a first terminal of a wireless communication system, A step of receiving auxiliary information for transmitting a sidelink PRS (Positioning Reference Signal); A method comprising the step of transmitting the sidelink PRS to a second terminal when the auxiliary information includes first information for triggering the sidelink PRS transmission of the first terminal.

2. In paragraph 1, If the above auxiliary information does not include the above first information: A step of storing the above auxiliary information; A step of receiving sidelink control information for triggering the sidelink PRS transmission from the second terminal; and A method further comprising the step of transmitting the sidelink PRS to the second terminal based on the sidelink control information.

3. In paragraph 1, The above auxiliary information further includes second information about the period of the sidelink PRS transmission of the first terminal, A method wherein the second information comprises a period of at least one millisecond (ms).

4. In paragraph 1, The above auxiliary information includes third information about a bandwidth for the sidelink PRS transmission of the first terminal, A method wherein the third information comprises a bandwidth in units of at least one megahertz (MHz).

5. In a method performed by a second terminal of a wireless communication system, A step of receiving auxiliary information for receiving a sidelink PRS (Positioning Reference Signal); A method comprising the step of receiving the sidelink PRS from the first terminal, when the auxiliary information includes first information for triggering the sidelink PRS transmission of the first terminal.

6. In paragraph 5, If the above auxiliary information does not include the above first information: A step of transmitting sidelink control information to the first terminal to trigger the sidelink PRS transmission of the first terminal; and A method further comprising the step of receiving the sidelink PRS from the first terminal.

7. In paragraph 5, The above auxiliary information further includes second information about the period of the sidelink PRS transmission of the first terminal, A method wherein the second information comprises a period of at least one millisecond (ms).

8. In paragraph 5, The above auxiliary information includes third information about a bandwidth for the sidelink PRS transmission of the first terminal, A method wherein the third information comprises a bandwidth in units of at least one megahertz (MHz).

9. In the first terminal of the wireless communication system, Transmitter and receiver; and Includes a control unit connected to the above transmitter and receiver, The above control unit, Receive auxiliary information for transmitting a sidelink PRS (Positioning Reference Signal) from a first network entity, A first terminal configured to transmit the sidelink PRS to a second terminal when the auxiliary information includes first information for triggering the sidelink PRS transmission of the first terminal.

10. In paragraph 9, the control unit, If the above auxiliary information does not include the above first information: Store the above auxiliary information, Receive sidelink control information for triggering the sidelink PRS transmission from the second terminal, and A first terminal configured to transmit the sidelink PRS to the second terminal based on the sidelink control information.

11. In paragraph 9, The above auxiliary information further includes second information about the period of the sidelink PRS transmission of the first terminal, The first terminal, wherein the second information comprises a period of at least one millisecond (ms).

12. In paragraph 9, The above auxiliary information includes third information about a bandwidth for the sidelink PRS transmission of the first terminal, The third information comprises a bandwidth of at least one megahertz (MHz) unit, the first terminal.

13. In the second terminal of the wireless communication system, Transmitter and receiver; and Includes a control unit connected to the above transmitter and receiver, The above control unit, Receive auxiliary information for receiving a sidelink PRS (Positioning Reference Signal) from a first network entity, A second terminal configured to receive the sidelink PRS from the first terminal, when the auxiliary information includes first information for triggering the sidelink PRS transmission of the first terminal.

14. In the 13th paragraph, the control unit, If the above auxiliary information does not include the above first information: Transmitting sidelink control information to the first terminal to trigger the sidelink PRS transmission of the first terminal, and A second terminal configured to receive the sidelink PRS from the first terminal.

15. In paragraph 13, The auxiliary information further includes second information about the period of the sidelink PRS transmission of the first terminal and third information about the bandwidth for the sidelink PRS transmission of the first terminal, The second information includes a period of at least one millisecond (ms), A second terminal, wherein the third information comprises a bandwidth in units of at least one megahertz (MHz).

Images