Method for sidelink transmit-receive distance determination

Abstract

The invention relates to a method for sidelink transmit-receive distance determination. Systems, methods, and devices for sidelink transmit-receive distance related determination and operation are disclosed. In one example, a wireless transmit receive unit (WTRU) may be configured with respect to an association between range information and a zone configuration. The WTRU receives an indication regarding a specific range information requirement and determines its own zone location based on the configuration information and location means (e.g., global positioning system). The WTRU may also receive zone location information about a transmitting device and determine a distance between the WTRU and the transmitting device.

Description

This application is a divisional application of Chinese patent application No. 202080038283.2, filed on April 3, 2020, and entitled “Method for determining side link transmit-receive distance”. The contents of the parent application are incorporated herein by reference. CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 62 / 830,133, filed April 5, 2019, U.S. Provisional Application No. 62 / 886,433, filed August 14, 2019, U.S. Provisional Application No. 62 / 908,206, filed September 30, 2019, and U.S. Provisional Application No. 62 / 930,976, filed November 5, 2019, the contents of which are incorporated herein by reference. Summary of the invention

[0002] Disclosed herein are systems, methods, and devices for sidelink transmit-receive range-related determination and operation. In one example, a wireless transmit receive unit (WTRU) may be configured with an association between range information and a zone configuration. The WTRU receives an indication of a specific range information requirement and determines its own zone location based on the configured information and location means (e.g., global positioning system). The WTRU may also receive zone location information of a transmitting device and determine a distance between the WTRU and the transmitting device. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present invention may be understood in more detail from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0004] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0005] Figure 1B is a diagram showing that according to one embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown;

[0006] Figure 1C is a diagram showing that according to one embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within the communication system shown;

[0007] Figure 1D is a diagram showing that according to one embodiment, Figure 1AA system diagram of another exemplary RAN and another exemplary CN used within the communication system shown;

[0008] Figure 1E is a system diagram illustrating an example architecture related to vehicle-to-everything (V2X) communications;

[0009] Figure 2 An example of determining TX-RX distance based on local zones is shown;

[0010] Figure 3 An example of an MCR with multiple WTRUs is shown;

[0011] Figure 4 An example showing how different MCRs require different zone configurations; and

[0012] Figure 5 An example process for calculating TX-RX distance based on MCR is shown. DETAILED DESCRIPTION

[0013] The following are possible abbreviations and acronyms that may be discussed in this article: Acknowledgement (ACK); Block Error Rate (BLER); Contention-based (CB) (e.g., access, channel, resource); Channel Busy Ratio (CBR); Cyclic Prefix (CP); Orthogonal Frequency Division Multiplexing (OFDM); Conventional OFDM (CP-OFDM) (e.g., relying on cyclic prefix); Channel Quality Indicator (CQI); Channel Occupancy (CR); Cyclic Redundancy Check (CRC); Channel State Information (CSI); Device-to-Device Transmission (D2D) (e.g., LTE sidelink); Downlink Control Information (DCI); Digital Fourier Transform Spread OFDM (DFT-s-OFDM); Downlink (DL); Demodulation Reference Signal (DMRS); Feedback (FB); Frequency Division Duplex (FDD); Frequency Division Multiplexing (FDM); Listen Before Talk (LBT); Low Latency Communication (LLC); Long Term Evolution (LTE) (e.g., from 3GPP LTE R8 and above); Medium Access Control (MAC); Negative ACK (NACK); Massive Broadband (MBB); Multi-Carrier (MC); Modulation and Coding Scheme (MCS); Out-of-Band (OOB) (e.g., transmit); Total Available WTRU Power at a Given TI (Pmax); Packet Delay Budget (PDB); Physical Layer (PHY); Physical SL Control Channel (PSCCH); Physical SL Feedback Channel (PSFCH); Primary Synchronization Signal (PSS); Physical SL Shared Channel (PSSCH); PSSCH Reference Signal Received Power (PSSCH-RSRP); Quality of Service (QoS) (e.g., from the perspective of the physical layer ); Radio Network Identifier (RNTI); Radio Resource Control (RRC); Radio Resource Management (RRM); Receiver (RX); Reference Signal (RS); Round Trip Time (RTT); SL ​​Received Signal Strength Indicator (S-RSSI); Side Link (SL); Synchronization Signal (SS); Secondary Synchronization Signal (SSS); Transport Block (TB); Time Division Duplex (TDD); Time Division Multiplexing (TDM); Transmission Time Interval (TTI); Transmission / Reception Point (TRP); Transmitter (TX); Transceiver (TRX); Uplink (UL); Ultra-Reliable and Low Latency Communication (URLLC); Vehicle-to-Everything Communication (V2X).

[0014] Figure 1A1 is a system diagram illustrating an exemplary communication system 100 according to an exemplary architecture. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word discrete Fourier transform-spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

[0015] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it should be appreciated that any number of WTRUs, base stations, networks, and / or network components are contemplated for any use case. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a station (STA), which may be configured to transmit and / or receive wireless signals, and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices working in an industrial and / or automated processing chain environment), consumer electronic devices, and devices working on commercial and / or industrial wireless networks, etc.

[0016] In some cases, the WTRU may also be a vehicle or a roadside unit (RSU). In one example, the WTRU may be physically integrated into a vehicle, wherein the components of the WTRU are physically separated. In one example, the WTRU is operably connected to a vehicle. In one example, the WTRU may be removably attached to a vehicle. In one example, the WTRU may be permanently attached to a vehicle. In one example, the WTRU may represent a vehicle and its physical attributes (e.g., size, speed, location, etc.). Any WTRU 102a, 102b, 102c, and 102d may be interchangeably referred to as a terminal, device, UE, or vehicle.

[0017] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., the CN 106, the Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102d. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation Node B (such as a gNB), a new radio (NR) Node B, a site controller, an access point (AP), a wireless router, and the like. Although each of the base stations 114a, 114b is depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0018] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies called cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area that is relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., each transceiver corresponds to a sector of the cell. In an embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals may be transmitted and / or received in a desired spatial direction.

[0019] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0020] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish an air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

[0021] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

[0022] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology that may use NR to establish the air interface 116, such as NR radio access.

[0023] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE radio access and NR radio access (e.g., using dual connectivity (DC) principles). Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0024] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), and GSM EDGE (GERAN), among others.

[0025] Figure 1A The base station 114b in the example may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any appropriate RAT to facilitate wireless connectivity in a local area, such as a business location, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In an embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, and the like). As Figure 1A As shown, the base station 114b may be directly connected to the Internet 110. Thus, the base station 114b does not need to access the Internet 110 via the CN 106.

[0026] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or may perform advanced security functions such as user authentication. Although in Figure 1AAlthough not shown, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104. For example, in addition to being connected to the RAN 104 employing NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0027] The CN 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer network devices that use common communication protocols, such as TCP, User Datagram Protocol (UDP), and / or IP in the Transmission Control Protocol / Internet Protocol (TCP / IP) Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, where the one or more RANs may use the same RAT or a different RAT as the RAN 104.

[0028] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0029] Figure 1B is a system diagram illustrating an exemplary WTRU 102. Figure 1B As shown, the WTRU 102 may include a number of components / parts, such as a processor 118, a transceiver 120, a transmit / receive component 122, a speaker / microphone 124, a numeric keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing components while remaining consistent with an embodiment.

[0030] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, however it should be appreciated that the processor 118 and the transceiver 120 may also be integrated together in one electronic component or chip.

[0031] The transmit / receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive component 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in another embodiment, the transmit / receive component 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, the transmit / receive component 122 may be configured to transmit and / or receive RF and light signals. It should be appreciated that the transmit / receive component 122 may be configured to transmit and / or receive any combination of wireless signals.

[0032] Although in Figure 1B 102 as a single component, but the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0033] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive component 122 and to demodulate signals received by the transmit / receive component 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

[0034] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a numeric keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from these components. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store information in any suitable memory such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as, for example, on a server or a home computer (not shown).

[0035] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power for use by other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0036] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may acquire location information via any suitable positioning method while remaining consistent with an embodiment.

[0037] The processor 118 may also be coupled to other peripheral devices 138, wherein the peripheral devices may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, FM radio units, digital music players, media players, video game console modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, and activity trackers, etc. The peripheral device 138 may include one or more sensors. The sensor may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geographic location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and a humidity sensor, etc.

[0038] The WTRU 102 may include a full-duplex radio in which reception or transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous for the radio. A full-duplex radio may include an interference management unit that reduces and / or substantially eliminates self-interference by means of hardware (e.g., chokes) or by signal processing by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio that transmits and receives some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)).

[0039] Figure 1C 1 is a system diagram showing the RAN 104 and the CN 106 according to an exemplary architecture. As described above, the RAN 104 may be in communication with the WTRUs 102a, 102b, 102c using an E-UTRA radio technology over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0040] The RAN 104 may include eNode-Bs 160a, 160b, 160c, however it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0041] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0042] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing components are described as being part of the CN 106, it should be appreciated that any of these components may be owned and / or operated by an entity other than the CN operator.

[0043] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation / deactivation processing, selecting a particular serving gateway during an initial attach procedure for the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0044] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may also perform other functions, such as anchoring the user plane during an inter-eNB handover, triggering paging processing when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the contexts of the WTRUs 102a, 102b, 102c, and the like.

[0045] The SGW 164 may be connected to the PGW 146, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0046] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, and the IP gateway may serve as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0047] Although the WTRU is described in the examples herein as a wireless terminal, it should be appreciated that in certain scenarios such a terminal may use a (eg, temporary or permanent) wired communication interface with a communication network.

[0048] In a representative embodiment, the other network 112 may be a WLAN.

[0049] A WLAN using an infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access or be connected to a distributed system (DS) or other types of wired / wireless networks that send traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for the STA may arrive through the AP and be delivered to the STA. Traffic originating from the STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be sent through the AP, for example, under the condition that the source STA may send traffic to the AP and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. The point-to-point traffic may be sent between the source and destination STAs (e.g., directly therebetween) using a direct link establishment (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z channelized DLS (TDLS)). For example, a WLAN using an independent BSS (IBSS) mode does not have an AP, and STAs (e.g., all STAs) within or using the IBSS can communicate directly with each other. Here, the IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode.

[0050] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., a primary channel). The primary channel may have a fixed width (e.g., a bandwidth of 20 MHz) or a dynamically set width. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access (CSMA / CA) with collision avoidance (e.g., in an 802.11 system) may be implemented. For CSMA / CA, STAs (e.g., each STA) including the AP may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA may back off. In a specified BSS, one STA (e.g., only one station) transmits at any given time.

[0051] A high throughput (HT) STA may communicate using a 40 MHz wide channel (eg, by combining a 20 MHz wide primary channel with a 20 MHz wide adjacent or non-adjacent channel to form a 40 MHz wide channel).

[0052] Very high throughput (VHT) STA can support channels with widths of 20MHz, 40MHz, 80MHz and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels or by combining two discontinuous 80MHz channels (this combination can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be transmitted and passed through a segment parser, which can separate the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed separately on each stream. The stream can be mapped on two 80MHz channels, and the data can be transmitted by the STA performing the transmission. At the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0053] 802.11af and 802.11ah support working modes below 1 GHz. Compared with 802.11n and 802.11ac, the channel working bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices can have certain capabilities, such as limited capabilities including support (e.g., only support) certain and / or limited bandwidths. MTC devices can include a battery, and the battery life of the battery is higher than a threshold (e.g., for maintaining a very long battery life).

[0054] For WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), these systems include channels that can be designated as primary channels. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a certain STA, where the STA originates from all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz and / or other channel bandwidth operating modes, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the width of the primary channel can be 1MHz. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy (e.g., because a STA (which only supports the 1MHz operating mode) transmits to the AP), then all available frequency bands can be considered busy even if most of the available frequency bands remain idle.

[0055] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.

[0056] Figure 1D 1 is a system diagram showing the RAN 104 and the CN 106 according to an exemplary architecture. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c using NR radio technology over the air interface 116. The RAN 104 may also communicate with the CN 106.

[0057] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may use beamforming processing to transmit and / or receive signals to and / or from the gNBs 180a, 180b, 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a, and receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0058] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable digital configuration. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or lasting different absolute time lengths).

[0059] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing other RANs (e.g., the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect to the gNB 180a, 180b, 180c while communicating / connecting to another RAN (e.g., the eNode-B 160a, 160b, 160c). For example, the WTRU 102a, 102b, 102c may communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c in a substantially simultaneous manner by implementing the DC principle. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.

[0060] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network slicing, DC, implement interworking between NR and E-UTRA, route user plane data to user plane functions (UPFs) 184a, 184b, and route control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other through the Xn interface.

[0061] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may include a data network (DN) 185a, 185b. Although the foregoing components are described as part of the CN 106, it should be understood that any of these components may be owned and / or operated by an entity other than the CN operator.

[0062] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, and mobility management, etc. The AMF 182a, 182b may use network slicing processing to customize the CN support provided to the WTRU 102a, 102b, 102c based on the type of service used by the WTRU 102a, 102b, 102c. As an example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and services for MTC access, etc. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that use other radio technologies (e.g., LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).

[0063] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and may configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0064] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N3 interface, which can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks (e.g., the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions such as routing and forwarding packets, implementing user plane policies, supporting multi-host PDU sessions, processing user plane QoS, buffering DL packets, and providing mobility anchor processing, etc.

[0065] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the DNs 185a, 185b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the local DNs 185a, 185b and through the UPFs 184a, 184b.

[0066] In some cases, one or more simulation devices (not shown) may perform the functions described herein, such as: WTRU 102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or one or more other devices described herein. These simulation devices may be one or more devices configured to simulate one or more or all of the functions described herein. For example, these simulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0067] The simulation device can be designed to implement one or more tests about other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being implemented and / or deployed as a part of a wired and / or wireless communication network in whole or in part to test other devices inside the communication network. The one or more simulation devices can perform one or more or all functions while being temporarily implemented or deployed as a part of a wired and / or wireless communication network. The simulation device can be directly coupled to other equipment to perform the test, and / or use over-the-air wireless communication to perform the test.

[0068] The one or more simulation devices can perform one or more functions, including all functions, while not being implemented or deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test lab and / or a test scenario of a wired and / or wireless communication network that is not deployed (e.g., tested) to implement tests on one or more components. The one or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication with the aid of RF circuits (e.g., which can include one or more antennas).

[0069] Figure 1E is a system diagram illustrating an example architecture related to vehicle-to-everything (V2X) communications. In the V2X case, the WTRU 102a may communicate with one or more WTRUs 102b, 102c, 102d via sidelink (SL) communications over the wireless interface 116. There may be several types of SL communications, such as unicast, broadcast, and multicast. SL communications may be considered a form of device-to-device (D2D) communications. Additionally and / or alternatively, the WTRU 102a may communicate with a base station 114 via a wireless interface, as discussed herein.

[0070] In a V2X communication scenario, the WTRU may select a transmission resource pool for communicating with another WTRU or a base station. The transmission resource pool may correspond to an identifier of a geographic zone in which the WTRU is located. The WTRU may determine the Area_ID based on its geographic coordinates and an area (pre-) configuration. The WTRU may obtain coordinates (X, Y) in meters according to the WGS84 model, where X may be the geodesic distance in longitude between the WTRU's current location and the geographic coordinate (0, 0), and Y may be the geodesic distance in latitude between the WTRU's current location and the geographic coordinate (0, 0). As described herein, WGS84 is a known model and may generally include mapping techniques such as a coordinate system relative to the earth and support location determination systems such as satellite navigation (e.g., GPS, etc.).

[0071] The WTRU may receive the zone (pre)configuration in a message (e.g., SystemInformationBlockType21 or SL-V2X-Preconfiguration), which may include one or more of the following parameters: L, which is the zoneLength in meters; W, which is the zoneWidth in meters; N X , which is zoneIDLongiMod; and / or N Y , which is zoneIDLatiMod.

[0072] Therefore, the WTRU may calculate / determine the Zone_ID based on the coordinates and the above parameters as follows: X1=Floor(X / L)ModN X ; Y1 = Floor (Y / W) Mod N Y ; Zone_ID = Y1*N X +X1.

[0073] The WTRU may select a transmission resource pool with a (pre-)configured Zone_ID that is equal to the calculated Zone_ID. In one example, the zoneLength and zoneWidth values ​​may be [5, 10, 20, 50, 100, 200, 500] meters, and the zoneIDLongiMod and zoneIDLatiMod values ​​may be [1, 2, 3, 4]. The WTRU may determine which resource to use based on the resources available in the pool, or may be pre-configured to use a specific resource or range of resources given certain parameters. Once the resource is determined, the WTRU may use the resource for transmitting and / or receiving information from another WTRU(s) or a base station.

[0074] In some cases, during wireless communication, e.g. Figure 1E In some embodiments, one or more factors may cause errors in receiving a transmission. For example, there may be environmental interference that may degrade the signal quality and / or reception capability, which may ultimately cause errors in the transmission. To counteract these errors, a hybrid automatic repeat request (HARQ) process may be utilized. HARQ may be used in various wireless communication scenarios, such as those described herein, where feedback may be sent back to a transmitting device (e.g., a WTRU, a base station, etc.) if a transmission is received in error. For example, the feedback may indicate that certain components of the transmission were not received and / or need to be resent.

[0075] For some transmission types, the use of HARQ may be based on information related to distance and / or signal-to-noise ratio information. For example, SL multicast transmissions may use HARQ to resolve any potential transmission issues between two or more WTRUs. Similarly, for SL broadcast transmissions, HARQ may be used for potential transmission issues between two or more WTRUs, while for SL unicast transmissions, HARQ may be used for potential transmission issues between two WTRUs. In some cases, the WTRU may determine to use HARQ feedback based on transmit-receive (TX-RX) distance and / or RSRP. For example, when a V2X WTRU (e.g., in NR) receives a packet, it may know the distance between itself and the V2X WTRU that sent the packet. This feature may help to assess whether one or some NR V2X quality of service (QoS) requirements (e.g., the range of a multicast transmission) are met. Given the high WTRU mobility that can be supported in V2X advanced use cases, the TX-RX distance may change at a rapid rate, so it is important that the V2X WTRU updates the TX-RX distance in a timely manner and with a certain degree of accuracy. Therefore, there is a need for a WTRU to be able to determine its position (eg, TX-RX distance) relative to another WTRU, and to do so in an efficient manner.

[0076] In some examples, the TX-RX distance may not be derived using PHY measurements, such as SL-RSRP. SL-RSRP is based on a linear average of the power of resource elements occupied by the physical SL feedback channel (PSSCH) DMRS within the physical resource blocks (PRBs) assigned in the associated physical SL control channel (PSCCH). SL-RSRP can be used to estimate path loss or "radio distance", but it is not necessarily transferable to geographic distance because the SL-RSRP measurement (one or more) takes into account radio signal propagation including blocking, shadowing, and multipath conditions. Therefore, one or more techniques are needed to obtain the geographic TX-RX distance.

[0077] Additionally, in some examples, dynamically determining the TX-RX distance may result in signaling overhead. Since the TX-RX distance may be used to determine whether a HARQ feedback transmission should be used for a received PSSCH transmission, the WTRU may evaluate the TX-RX distance on some basis (e.g., a per-transmission block (TB) basis taking into account the high speed of a V2X WTRU, or LTE, or NR, etc.). Therefore, the dynamic determination of the TX-RX distance and associated information may need to be sent using radio layer signaling such as sidelink control information (SCI). Therefore, one or more techniques are needed to reduce the signaling overhead incurred.

[0078] As discussed herein, when describing HARQ transmissions in a physical SL feedback channel (PSFCH) and its associated data transmissions in a PSSCH, a WTRU that transmits a PSSCH and an associated PSCCH may be referred to as a TX WTRU. A WTRU that receives the PSCCH and PSSCH and therefore transmits an associated PSFCH may be referred to as a RX WTRU. Additionally, as discussed herein, zones, local zones, sub-zones, and PHY zones may be used interchangeably.

[0079] Typically, the WTRU may determine and / or be (pre)configured with an association (e.g., a mapping and / or table) between the zone size and the QoS range requirement and / or TX-RX distance accuracy. For example, the higher the TX-RX distance accuracy that may be required, the smaller the zone size that may be selected.

[0080] In one method of determining the TX-RX distance, the WTRU may divide the geographic area (eg, SL area) where the WTRU is located into multiple zones (eg, local zones). Figure 2 An example of determining TX-RX distance based on local zones is shown. The WTRU may determine to divide the (pre-)configured area 210 into a grid of local zones 220 based on one or more factors, such as zone length and width, QoS range requirements, and / or TX-RX distance accuracy. Each local zone may have a length and a width, such as localzonelength 235 and localzonewidth 234. Each area may have its own set of local zones.

[0081] As shown, there may be one or more WTRUs, such as WTRU 201, WTRU 202, WTRU 203, and WTRU 204. In this example, WTRU 201 communicates with WTRU 202, and WTRU 203 communicates with WTRU 204.

[0082] Therefore, the WTRU may determine the local zone denominator (N) and divide an area into N times N local zones; note that in the example shown, the division may have an equal number of local zones in longitude and latitude, however, in other examples not shown, the division may not be equal for longitude and latitude. Therefore, the length and width of the local zone may be Area_Length / N and Area_Width / N meters, respectively. For the purpose of this example, the area may be square and have the same number of local zones in latitude as in longitude.

[0083] The WTRU may assign a Local_Zone_ID to each local zone based on one or more (pre)configured rules. In one method, the WTRU may be (pre)configured to assign integers as Local_Zone_IDs, starting from zero and ascending by longitude first and latitude second. Figure 2 , arrow 241 shows that the Local_Zone ID starts at 0 and moves to the right, increasing by one for each local zone, and then moves upward once the edge of the region is reached. In this example, the WTRU may divide the region into 64 local zones (i.e., N=8), and assign a Local_Zone_ID to each local zone as shown; thus, by starting with Local_Zone ID 0 in the lower left corner, the final Local_Zone ID is 63 in the upper right corner.

[0084] In another method, the WTRU may be (pre-)configured to assign an integer including the Area_ID for the Local_Zone_ID. For example, the WTRU may be assigned a Local_Zone_ID equal to Local_Zone_ID+Area_ID*N2. This may be different because signaling may be increased to carry the Local_Zone_ID information.

[0085] The WTRU may determine the TX-RX distance based on the local zone, such as Figure 2 As shown. Typically, the WTRU may include the TX WTRU Local_Zone_ID in the PSCCH transmission. For example, the WTRU may transmit the Local_Zone_ID in the SCI bits field in the PSCCH associated with the PSSCH transmission. In one example, 6 bits of Local_Zone_ID information may be sent in the PSCCH. In another example, the WTRU may transmit the Local_Zone_ID in the PSSCH. The WTRU may determine the TX-RX distance based on one or more factors, such as: TX Local_Zone_ID; RX Local_Zone_ID; TX WTRU Area_ID information (e.g., Area_ID, TX_X1 and TX_Y1); and / or RX WTRU Area_ID.

[0086] In one example, the RX WTRU may determine the TX WTRU Area_ID implicitly based on a received PSSCH resource allocation. In another example, the RX WTRU may determine the TX WTRU Area_ID based on an explicit indication in a received PSCCH and / or PSSCH.

[0087] The RX WTRU may determine the TX-RX distance based on the inter-Local-Zone distances (eg, 236a and 236b). Initially, the RX WTRU may determine whether the RX WTRU and the TX WTRU are located in the same area based on the received TX WTRU Area_ID information.

[0088] When the TX WTRU and RX WTRU are not in the same region, the RX WTRU may determine the difference values: Delta_X1, which is the difference between TX_X1 and RX_X1; and Delta_Y1, which is the difference between TX_Y1 and RX_Y1.

[0089] In some cases, the RX WTRU may calculate RX_X1 and RX_Y1 as discussed herein and based on TX_X1=TX WTRU Area_ID Mod N X ,TX_Y1=Floor(TX WTRU Area_ID / N X ) to derive TX_X1 and TX_Y1. Alternatively, TX_X1 and TX_Y1 may be indicated in the PSCCH associated with the PSSCH transmission. For example, the WTRU may indicate each value in a 2-bit field in the SCI.

[0090] When the TX WTRU and the RX WTRU are not in the same area, the RX WTRU may determine the local inter-zone distance based on one or more factors, such as the TX Local_Zone_ID and the RX Local_Zone_ID, and / or Delta_X1 and Delta_Y1.

[0091] When the RX WTRU and the TX WTRU are located in the same area (e.g., TX Area_ID is equal to RX Area_ID), the WTRU may determine the TX-RX distance based on: TX-RX distance ≈ inter-local zone distance = SQRT(((ABS(Floor(TX Local_Zone_ID, N)-Floor(RX Local_Zone_ID, N))*W) 2 +(ABS(MOD(TX Local_Zone_ID,N)-MOD(RX Local_Zone_ID,N))*L) 2 ).

[0092] Therefore, for WTRU 201 and WTRU 202, the TX-RX distance may be SQRT((ABS(Floor(49,8)-Floor(29,8))*W) 2+(ABS(MOD(49,8)-MOD(RX 29,8))*L) 2 )=SQRT((3*W) 2 +(4*L) 2 ).

[0093] When the RX WTRU and TX WTRU are located in different areas (i.e., TX Area_ID may not be equal to RX Area_ID), the WTRU may determine the TX-RX distance based on: TX-RX distance ≈ Inter-Local-Zone distance = SQRT(((ABS(Delta_X1*N+Floor(TX Local_Zone_ID,N)-Floor(RX Local_Zone_ID,N)))*W) 2 +ABS(((Delta_Y1*N+(MOD(TX Local_Zone_ID,N)-MOD(RX Local_Zone_ID,N))))*L) 2 ).

[0094] Therefore, for WTRU 203 to WTRU 204, the TX-RX distance may be = SQRT(((ABS(8+Floor(13,8)-Floor(18,8)))*W) 2 +ABS(((0+(MOD(13,8)-MOD(18,8)))*L) 2 )=SQRT((7*W) 2 +(3*L) 2 ).

[0095] Note that, as discussed herein, when zones are used, the TX-RX distance may be determined from the center of each zone. For example, WTRU 202 is slightly to the right of the local zone, however, the TX-RX distance measured to WTRU 201 is measured from the center of local zone 13 to the center of local zone 49.

[0096] In one method of determining the TX-RX distance, the area may be divided into a grid of geographic boundaries (e.g., zones, local zones, sub-zones, etc.), thereby generating sub-zone configurations; the division may be based on range requirements specified by the network. In addition, each sub-zone configuration may be dedicated to V2X services, each with a different minimum communication range (MCR) requirement. Figure 3311 is an example of an MCR with multiple WTRUs. MCR 311 is shown as a dashed circle and shows the minimum distance for one WTRU 301 to communicate with one or more other WTRUs (e.g., WTRUs 302, 303, 304, and / or 305). The WTRUTX-RX distances are shown as solid lines for each WTRU to communicate with WTRU 301. For this example, WTRU 301 is the origin of MCR 311. As shown, WTRUs 302 and 303 are outside of MCR 311 and will not be able to perform certain functions (e.g., HARQ) with respect to WTRU 301. In addition, WTRUs 304 and 305 are within the MCR and are therefore able to communicate with WTRU 301.

[0097] Figure 4 An example of how different MCRs may require different zone configurations is shown. In general, a WTRU may be (pre-)configured with a set of sub-zone configurations. Each sub-zone configuration may include a modulus and a dimension parameter. The dimension parameter may include, for example, a length and a width for a rectangular zone configuration. In one example (e.g., Figure 4 ), the rectangular sub-zones may be squares, where each sub-zone has the same length and width. In another example, the sub-zone configuration may include a side length of an octagonal sub-zone. In some cases, the WTRU may determine the sub-zone configuration with each configured V2X service, which may be based on the MCR requirement of the V2X service. For example, a V2X service with a small MCR requirement may require better range measurement accuracy, and therefore may use a smaller sub-zone.

[0098] exist Figure 4 In the example of FIG. 4 , two MCRs 411 and 421 are shown. For each example MCR, the total area may have the same or substantially the same dimensions 406X and 406Y. Depending on the MCR, the area may be divided differently, with each sub-zone having a different length and width, as shown at 430. Note that for demonstration purposes, each WTRU (401, 402, 403, 404, 405) may be at the same location in a given area so that different sub-zone configurations may be illustrated. As shown, MCR 411 may represent a V2X service with a smaller MCR requirement, which requires better range measurement accuracy than MCR 421.

[0099] In some cases, the WTRU may use a sub-zone configuration associated with the smallest MCR configured for any active side link radio bearer (SLRB) at the WTRU. Alternatively, the WTRU may use different sub-zone configurations, where each sub-zone configuration is used for transmission of data associated with each SLRB or SLRB group.

[0100] In some cases, sub-zone information for a TB for a corresponding V2X service may be sent. As described herein, a V2X service may be supported by the transmission of data associated with specific requirements (e.g., QoS, latency, bandwidth, etc.). The RX WTRU may calculate and maintain sub-zone information, such as a sub-zone ID, for a corresponding V2X service based on the configured / determined sub-zone configuration and / or geographic information. For a PSSCH transmission of a TB, the WTRU may determine the V2X service applicable to the TB and select the appropriate sub-zone information. The TX WTRU may indicate such sub-zone information (e.g., sub-zone ID) in the SCI transmitted in the PSCCH associated with the PSSCH carrying the TB.

[0101] Figure 5 An example process for calculating a TX-RX distance based on an MCR is shown. In general, the RX WTRU may determine the RX WTRU sub-zone ID to use based on the MCR indicated in the received PSCCH and calculate the TX-RX distance using the determined RX WTRU sub-zone ID and the TX WTRU sub-zone ID received in the PSCCH (e.g., SCI). The RX WTRU may determine the sub-zone configuration to use based on the MCR indicated in the PSCCH received from the TX WTRU. The RX WTRU may calculate the RX WTRU sub-zone ID based on the determined sub-zone configuration (e.g., using a rectangular configuration).

[0102] Although Figure 5An example process is presented with steps in a particular order, but one of ordinary skill in the art will appreciate that any of the steps may be optional and they may be performed in an order different from that presented. Initially, the RX WTRU may be (pre-)configured with one or more MCRs. In an example, each MCR may be associated with a sub-zone configuration that defines how the area in question will be divided and identified to any associated WTRU; this will be further described herein. At 501, the RX WTRU may receive control information (e.g., SCI) from the TX WTRU on a control channel (e.g., PSCCH). The control information may include a sub-zone ID of the TX WTRU and / or an indication of the MCR. In an example, the MCR may be specific to the V2X service of the TB to be sent in the associated PSSCH. At 502, the RX WTRU may determine the sub-zone configuration based on the received MCR. At 503, the RX WTRU may determine its own sub-zone ID based on the determined sub-zone configuration and the WGS84 model. In some cases, a set of RX WTRU sub-zone IDs may be calculated and updated for each supported MCR, and the RX WTRU may select one based on the MCR indicated in the PSCCH from the TX WTRU.

[0103] At 504, the RX WTRU may determine a TX-RX distance based on the TX WTRU sub-zone ID and the RX WTRU sub-zone ID. At 505, the RX WTRU may receive a data transmission associated with control information previously received from the TX WTRU (e.g., a TB in the PSSCH). At 506, the RX WTRU may perform HARQ for the data transmission based on the TX-RX distance. In one example, the RX WTRU may determine not to transmit a HARQ ACK / NACK when the determined WTRU TX-RX distance exceeds the MCR received from the TX WTRU in the PSCCH.

[0104] In with Figure 5 In a related example, to determine the sub-zone ID, the RX WTRU may calculate as follows (eg, rectangular case): X1 = Floor (X / L) Mod N X and Y1=Floor(Y / W)Mod N Y , so RX WTRU sub-zone ID = Y1*N X+X1. For these calculations, X may be the geodesic distance in longitude between the current location of the RX WTRU and the geographic coordinate (0,0), and Y may be the geodesic distance in latitude between the current location of the RX WTRU and the geographic coordinate (0,0). Additionally, L may be the SubzoneLength in meters, W may be the SubzoneWidth in meters, and N may be the distance in latitude between the current location of the RX WTRU and the geographic coordinate (0,0). X Can be SubzoneIdLongiMod, and N Y It can be SubzoneIdLatiMod. In some cases, each sub-zone can be a square with the same length and width.

[0105] In with Figure 5 In a related example, once the sub-zone ID is determined, the WTRU may determine the TX-RX distance. The RXWTRU may calculate the TX-RX distance based on the difference between the TX sub-zone ID and the RX sub-zone ID. In one example, the RXWTRU may look up a mapping between the difference of the pre-calculated sub-zone IDs and the geographical distance. In another example, the RXWTRU may calculate the distance based on the following equation: WTRU TX-R distance ≈ inter-sub-zone distance = SQRT(((ABS(Floor(TXsub_zone_ID, N X )-Floor(RX sub-zone_ID,N X ))*W) 2 +(ABS(MOD(TX sub_Zone_ID,N Y )-MOD(RX sub_Zone_ID,N Y ))*L) 2 ).

[0106] In one example, the WTRU may determine a different sub-zone ID from the reference point. The WTRU may transmit the sub-zone information using a differential sub-zone ID. For example, the WTRU may be (pre-)configured with a local reference point, such as a gNB, a group leader V2X WTRU, and / or a V2X WTRU configured as a synchronization source. The WTRU may calculate its own sub-zone ID (which may be used for each applicable sub-zone configuration) and transmit a different sub-zone ID, such as the difference between the WTRU's sub-zone ID and the sub-zone ID of the local reference point in the SCI transmission. This may reduce the L1 signaling overhead.

[0107] In one method of determining the TX-RX distance, the WTRU TX-RX distance may be determined based on a geodesic distance, such as an absolute geodesic distance or a differential geodesic coordinate.

[0108] To calculate the TX-RX distance based on the absolute geodetic distance, the WTRU may determine the TX-RX distance based on the geographic coordinates (X, Y) in meters according to the WGS84 model, where X is the longitude geodetic distance between the WTRU's current location and the geographic coordinates (0, 0), and Y is the latitude geodetic distance between the WTRU's current location and the geographic coordinates (0, 0).

[0109] For this case, the RX WTRU may calculate the distance between the TX WTRU and the RX WTRU based on the coordinates of the TX WTRU (i.e., TX_X / TX_Y) and the coordinates of the RX WTRU (i.e., RX_X / RX_Y) by applying TX-RX distance = SQRT((TX_X – RX_X) 2 +(TX_Y-RX_Y) 2 ), determine the TX-RX distance. In addition, the TX WTRU may communicate the absolute geodesic distance (e.g., X and Y) to the RX WTRU via PHY and / or higher layer signaling. However, the distance value may be very large and require a large number of bits in the signaling.

[0110] To calculate the TX-RX distance based on the differential geodesic distance, the WTRU may determine the differential geodesic coordinates based on the zone configuration in order to reduce PHY signaling for dynamic transmission of geographic information. The WTRU may determine the differential geodesic coordinates (X2, Y2) based on: X2 = X Mod L, and Y2 = Y Mod W, where L and W may be the (pre-)configured zoneLength and zoneWidth in meters, respectively.

[0111] The RX WTRU may determine the TX-RX distance based on the received differential geodesic coordinates (TX_X2, TX_Y2), its own geodesic coordinates (X, Y), and the Area ID. The RX WTRU may determine whether the RX WTRU and the TX WTRU are in the same area based on the received TX WTRU Area_ID. When the TX WTRU and the RX WTRU are not in the same area, the RX WTRU may determine the difference as follows, where Delta_X1 is the difference between TX_X1 and RX_X1, and Delta_Y1 is the difference between TX_Y1 and RX_Y1.

[0112] The RX WTRU may calculate RX_X1 and RX_Y1 as discussed herein and derive TX_X1 and TX_Y1 based on: TX_X1 = TX WTRU Area_ID Mod N X , and TX_Y1=Floor(TX WTRU Area_ID / N X ).

[0113] In some cases, TX_X1 and TX_Y1 may be indicated in the PSCCH associated with the PSSCH transmission. For example, the WTRU may indicate each value in a 2-bit field in the SCI.

[0114] The RX WTRU may then determine TX_X / TX_Y based on: TX_X = (Floor(RX_X / L) + Delta_X1)*L + TX_X2, and TX_Y = (Floor(RX_Y / W) + Delta_Y1)*W + TX_Y2. The RX WTRU may determine the TX-RX distance based on: TX-RX distance = SQRT((TX_X - RX_X) 2 +(TX_Y-RX_Y) 2 ).

[0115] Alternatively, the WTRU may determine the differential geodesic coordinates (X2, Y2) based on a (pre-)configured local geo-reference point. In one example, the local geo-reference point may be (X_gNB, Y_gNB) of a gNB where the WTRU may reside. In another example, the local geo-reference point may be a group leader in a multicast transmission. In another example, the local geo-reference point may be a V2X WTRU providing a synchronization source. The WTRU may receive such geographic information via downlink higher layer signaling and determine the differential geodesic coordinates (X2, Y2) based on: X2 = X_WTRU–X_gNB and Y2 = Y_WTRU–Y_gNB.

[0116] The RX WTRU may determine the TX-RX distance based on the received differential geodesic coordinates (TX_X2, TX_Y2), its own geodesic coordinates (X, Y), and the region ID, where the RX WTRU may determine TX_X / TX_Y based on TX_X=X_gNB+TX_X2 and TX_Y=Y_gNB+TX_Y2, and TX_X / TX_Y based on TX-RX distance=SQRT((TX_X-RX_X) / TX_Y / TX_Y / TX_Y / TX_X ...X / TX_Y / TX_Y / TX_X / TX_Y / TX_Y / TX_X / TX_Y / TX_X / TX_Y / TX_ 2 +(TX_Y-RX_Y) 2 ) to determine the TX-RX distance.

[0117] The WTRU may include the TX WTRU differential geodesic distance field in the PSCCH transmission. In one example, the WTRU may transmit TX_X2 and TX_Y2 in the SCI bits field in the PSCCH associated with the PSSCH transmission. In another example, the WTRU may include such information in higher layer signaling (e.g., MAC CE and / or RRC signaling).

[0118] In one method of determining the TX-RX distance, the WTRU may base the TX-RX distance determination on a WTRU ID. The WTRU may be (pre)configured with WTRU identification (ID) information (e.g., WTRU source ID and destination ID) at both higher layers and the PHY layer. Additionally, in a multicast transmission, the group member WTRUs may be configured (e.g., by higher layers) with a group-specific WTRU ID.

[0119] In one case, the WTRU may associate the WTRU ID with the WTRU location information, for example, based on a band ID, a sub-band ID, geographic coordinates, etc. For unicast transmissions, the WTRU may select an L1 source ID based on the WTRU location information. For example, the RX WTRU may obtain the source ID information of the TX WTRU via RRC signaling during the unicast transmission establishment. For groupcast transmissions, the RX WTRU may be assigned a group-specific WTRU ID by the group leader TX WTRU based on the WTRU location information (e.g., position in a queue). The RX WTRU may determine the location of the TX WTRU based on the group-specific WTRU ID of the TX WTRU.

[0120] In order to keep the associated WTRU location information up to date, the WTRU may periodically update its location information. In one example, the WTRU may transmit the zone ID, sub-zone ID and / or geographic location information in MAC CE or RRC signaling. In another example, the WTRU may transmit its location information (e.g., zone ID and sub-zone ID) and its L1 source ID in a PHY feedback channel.

[0121] In some cases, the WTRU may determine location information based on one or more PSFCH resources. In addition, the location information of the WTRU (e.g., band ID and sub-band ID) may be associated with the PSFCH resources (e.g., including time domain, frequency domain, and code domain). In this case, the location information may not be sent explicitly in the PHY feedback channel, but may be transmitted in an implicit manner. For example, time-frequency resource 1 may be used for a subset of band IDs or sub-band IDs, while time-frequency resource 2 may be used for another subset of band IDs or sub-band IDs. By detecting which PSFCH resources are occupied by the PHY feedback, the RX WTRU may know the location information of the TX WTRU performing the PSFCH transmission.

[0122] In another case, the WTRU may update the WTRU location information associated with its L1 source ID, which may occur when one or more conditions occur, such as: a WTRU ID change performed by higher layers for security reasons (e.g., the WTRU source ID may be changed); a TX-RX distance exceeding a (pre-)configured threshold; a WTRU speed exceeding a (pre-)configured threshold; a CSI report request; and / or periodically, whereby the periodicity of such updates may depend on the WTRU speed (e.g., a WTRU with a higher speed may update its location information associated with the L1 ID more frequently).

[0123] In some cases, implicit WTRU location indication using WTRU L1 ID may use a bit field in the SCI to convey WTRU location information and improve L1 signaling efficiency.The RX WTRU may determine the WTRU TX-RX distance based on the L1 Source ID information included in the SCI associated with the TB transmission.

[0124] In another case, the WTRU may transmit the location in the SCI for some scenarios (e.g., where it is not possible for the WTRU to associate its location information with a source ID), while in other scenarios (e.g., where it is possible to associate the source ID with location information), it may transmit only the L1 source ID. For example, the WTRU may use different SCI formats for the two scenarios. Alternatively, the WTRU may use the same format and may or may not indicate the type of ID being transmitted. The WTRU may use location-dependent vs. non-location-dependent depending on the following scenarios: transmission vs. retransmission, where the WTRU may use a non-location-based L1 ID for transmission and a location-based ID for retransmission, which may have the advantage of being able to provide the location of the WTRU without additional overhead (e.g., based on the association of transmission and retransmission resources known by the RX WTRU); QoS of the transmission, where the WTRU may transmit a location-associated L1 ID for transmissions associated with an MCR; data vs. control, where the WTRU may transmit a location-associated L1 ID only for control transmissions (e.g., PC5 RRC) and not for data, or vice versa; and / or, depending on the WTRU speed.

[0125] For any of the TX-RX distance determination methods discussed herein, in some cases, the location of the TX WTRU or the RX WTRU may be unknown.

[0126] In one case, the TX WTRU may indicate an "unknown location" status to the RX WTRU(s). For example, the TX WTRU may use a code point in one bit field (e.g., location information bit field) of the first or second level SCI to indicate the "unknown location" status to the RX WTRU(s). Alternatively, the TX WTRU may use one bit in the first level SCI to indicate one or more of: whether location information is available; and / or, the second level SCI may or may not include the TX WTRU location information.

[0127] In some cases where the TX WTRU indicates to the RX WTRU in the SCI that it is “unknown location”, the RX WTRU may transmit a NACK when the RX WTRU cannot decode the message, regardless of other parameters, such as the MCR. Figure 5 As further described in the example of , the RX WTRU may determine to send HARQ NACK feedback when it is able to decode the SCI. Specifically, the WTRU may perform NACK-based feedback for unicast / multicast, where the WTRU may transmit a NACK only when it is unable to decode a message. If the location information of the TX WTRU is indicated in the SCI, the WTRU may send a NACK when the WTRU is unable to decode the message and the TX-RX distance is less than the MCR indicated in the SCI.

[0128] In some cases where the TX WTRU indicates an "unknown location" in the SCI to the RX WTRU, the WTRU may use the SL-RSRP to determine the transmission of HARQ NACK feedback. Alternatively, the WTRU may use the path loss between the TX WTRU and the RX WTRU to determine the transmission of HARQ NACK feedback. Specifically, when the TX WTRU indicates an "unknown location" state in the SCI, the RX WTRU may transmit a NACK when the SL-RSRP of the PSSCH / PSCCH is greater than a threshold or the path loss between the TX WTRU and the RX WTRU is less than a threshold. Conversely, when the SCI does contain the TX WTRU location, the RX WTRU may determine to send HARQ NACK feedback based on the SL-RSRP of the PSSCH / PSCCH or the path loss between the TX WTRU and the RX WTRU. Additionally or alternatively, when the location information of the TX WTRU is indicated in the SCI, the RX WTRU may use the TX-RX distance to determine the transmission of HARQ NACK feedback.

[0129] In some cases where the TX WTRU indicates an "unknown location" in the SCI to the RX WTRU, the RX WTRU may determine to send a HARQ NACK feedback based on location information obtained from a previously received location of the TX WTRU. For example, the RX WTRU may determine to use the TX WTRU location information previously received from the TX WTRU to calculate the TX-RX distance associated with the received TB. In addition, the RX WTRU may determine whether the time period between the receipt of the TX WTRU location and the TB transmission exceeds a threshold; the threshold may be (pre)configured or determined by the RX WTRU based on one or all of the WTRU's speed, channel conditions, and / or QoS requirements (e.g., reliability).

[0130] In some cases where the TX WTRU may indicate "unknown location" to the RX WTRU in the SCI, the TX WTRU may determine whether to perform a retransmission based on feedback from the RX WTRU. In one example, the TX WTRU may be configured with two retransmission procedures, one of which may be used when the TX WTRU location information is available and another of which may be used when the location information is not available.

[0131] In another example, the TX WTRU may be configured with more than one maximum number of retransmissions, for example, one value may be used when location information is available and another value may be used when the TX WTRU location information is not available.

[0132] In another example, the TX WTRU may determine to perform feedback-based HARQ retransmissions based on the RSRP / RSSI of the PSFCH. Specifically, if the RSRP / RSSI of the PSFCH is greater than a threshold, the TX WTRU may perform retransmissions, and if the RSRP / RSSI of the PSFCH is less than a threshold, the TX WTRU may not perform retransmissions. Alternatively, when the TX WTRU location information is not available, the TX WTRU may perform a fixed number of retransmissions. The fixed number of retransmissions may be determined based on the QoS of the TB and / or the CBR of the resource pool.

[0133] For any of the TX-RX distance determination methods discussed herein, in some cases, the WTRU may use a (pre-)configured and / or determined area (e.g., area, SL zone, sub-zone, local zone, etc.) for resource pool selection.

[0134] In one scenario, a WTRU may be configured with a band-based TX resource pool configuration and another TX resource pool configuration that is not band-based, and the WTRU may determine whether to use the band-based TX pool configuration or the non-band-based TX pool configuration based on the type of data to be transmitted. Specifically, the WTRU may decide to use a TX resource pool to transmit a first type of data, the TX resource pool being configured based on the WTRU's geographic location and the determination of the WTRU's current band (e.g., LTE). For a second type of data, the WTRU may be configured to use a TX resource pool configuration that is not band-based, where the WTRU is configured with a single TX pool that will be used regardless of the WTRU's location.

[0135] In some cases, the WTRU may choose whether to transmit data using a zone-based TX resource pool or a non-zone-based TX resource pool based on any one or any combination of the following aspects related to the type of data: the size of the data packet transmission, the periodicity of the data transmission, the speed of the WTRU and / or QoS parameters.

[0136] For example, for the size of data packet transmission, the WTRU may be configured to transmit small packets over a zone-based pool configuration. Specifically, the WTRU may be configured with a threshold packet size and may use the zone-based TX resource pool to transmit all packets with a size below the threshold.

[0137] For example, for periodicity of data transmission, the WTRU may be configured to transmit all periodic transmissions on a zone-based TX resource pool configuration. For example, the WTRU may perform all transmissions associated with a periodic resource reservation performed by the WTRU on a zone-based TX resource pool.

[0138] For the speed of the WTRU, for example, the WTRU may decide whether to use the zone-based TX resource pool configuration to transmit a specific data packet based on the current speed of the WTRU. Specifically, a WTRU traveling at a speed above a threshold may not perform transmission on the zone-based TX resource pool.

[0139] For QoS parameters, for example, the WTRU may determine whether to perform data transmission associated with the QoS on a zone-based TX resource pool based on one or more QoS parameters.

[0140] In the case where the WTRU decides whether to use zone-based resource pool selection based on a data type, in some cases, the data type may be implicitly mapped to a logical channel (LCH). For example, in the case where the WTRU decides whether to use zone-based resource pool selection, the WTRU may determine whether to perform zone-based pool configuration based on the LCH mapping and / or restrictions on the TX resource pool configuration. For example, the WTRU may be (pre-)configured with an explicit mapping of SLRBs or LCHs to TX resource pool configurations (e.g., zone-based or non-zone-based) to be used. The WTRU may also be configured with multiple conditions (e.g., speed, pool congestion, etc.) under which such explicit mappings may or may not be applied to a particular LCH. Alternatively, the WTRU may be (pre-)configured with an attribute of the LCH that implicitly results in mapping the attribute to a zone-based TX resource pool configuration. Such configuration of the attributes for the LCH may be obtained from a dedicated configuration SIB or (pre-)configuration.

[0141] In the case where the WTRU decides whether to use a zone-based resource pool selection based on the data type, in some cases, the logical channel prioritization (LCP) restriction may be based on the data type. The WTRU may be configured with an LCP restriction based on the data type, whereby the data type is determined by any of the techniques described herein. For example, the WTRU may select the first LCH during the LCP, and may only select subsequent LCHs with the same selected attributes after the LCP. Alternatively, the WTRU may receive an indication of a grant type during the execution of the LCP. The grant type may indicate that the resource is associated with a zone-based TX pool or a non-zone-based TX pool. The grant type may implicitly indicate a mapping to a zone-based TX resource pool. For example, the grant may indicate a mapping to a specific LCH based on the size of the grant and / or the nature of the grant (e.g., LTE-like grant, traditional-like grant, etc.), which is intended for transmission on a zone-based TX resource pool. The WTRU may be allowed to select from the LCHs for the LCP corresponding to a specific grant type. Specifically, for a grant associated with a zone-based TX resource pool, the WTRU may select data only from LCHs that are allowed (eg, by pre-configuration) to be transmitted on such a TX resource pool.

[0142] In the case where the WTRU decides whether to use band-based resource pool selection based on data type, in some cases, the resource selection may take the data type into account. The WTRU may trigger resource (re)selection by taking into account the data type and its association with the band-based TX resource pool. For example, for certain LCHs that meet the data type criteria or are (pre)configured with a specific explicit / implicit indication, the WTRU may perform resource selection on the band-based TX resource pool when data for the LCH arrives and a band-based TX resource pool Mode 2 grant does not yet exist. Alternatively, the WTRU may perform resource selection for all periodic resource reservations on the band-based TX resource pool and any one-time or asynchronous resource selection on the non-band-based resource pool. The WTRU may then determine on which resource pool to perform resource selection based on the logical channel that has data available in the buffer.

[0143] Although the features, techniques, methods, examples, situations, circumstances, and elements are described above in specific combinations, it will be understood by those of ordinary skill in the art that each of these features, techniques, methods, examples, situations, circumstances, and elements may be used alone or in any combination with other features, techniques, methods, examples, situations, circumstances, and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware that is incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a first wireless transmit receive unit (WTRU), the method comprising: receiving configuration information, wherein the configuration information includes a set of zone configurations, wherein each zone configuration in the set of zone configurations is associated with a corresponding communication range requirement, wherein each zone configuration in the set of zone configurations has a corresponding zone-associated length; determining a zone-associated length from the set of zone configurations based on a communication range requirement of a transport block (TB) associated with a vehicle-to-everything (V2X) service; determining a zone ID associated with transmission of the TB based on the zone-associated length and based on the location information of the first WTRU; as well as The determined zone ID associated with the transmission of the TB is transmitted.

2. The method according to claim 1, wherein: The determined zone ID is included in the control information.

3. The method according to claim 2, wherein: The control information is SL control information (SCI) on a physical sidelink control channel, and wherein the control information includes first-level SL control information and second-level SL control information.

4. The method according to claim 1, wherein: The transmission of the TB is a multicast transmission and is sent on a shared channel.

5. The method of claim 4, wherein the transmission of the TB is to a second WTRU.

6. A first wireless transmit / receive unit (WTRU), the WTRU comprising: processor, and a transceiver coupled to the processor, The processor and transceiver are configured to receive configuration information, wherein the configuration information includes a set of zone configurations, wherein each zone configuration in the set of zone configurations is associated with a corresponding communication range requirement, wherein each zone configuration in the set of zone configurations has a corresponding zone-associated length; The processor and transceiver are configured to determine a zone-related length from the set of zone configurations based on a communication range requirement of a transport block (TB), wherein the TB is associated with a vehicle-to-everything (V2X) service; The processor and transceiver are configured to determine a zone ID associated with transmission of the TB based on the zone-associated length and based on location information of the first WTRU; and The processor and transceiver are configured to transmit the determined zone ID associated with the transmission of the TB.

7. The first WTRU of claim 6, wherein the determined zone ID is included in control information.

8. The first WTRU according to claim 7, wherein the control information is SL control information (SCI) on a physical sidelink control channel, and wherein the control information includes first-level SL control information and second-level SL control information.

9. The first WTRU of claim 6, wherein the transmission of the TB is a multicast transmission and is transmitted on a shared channel.

10. The first WTRU of claim 8, wherein the transmission of the TB is to a second WTRU.

Images