Method for determining sidelink transmission-reception distance

Abstract

Systems, methods, and devices for sidelink transmit-receive distance relation determination and operation are provided.SOLUTION: In a communication system, a wireless transmit receive unit (WTRU) receives an indication of a specific range information requirement and determines its own zone location based on configured information and location means (e.g., GPS). Zone location information of the transmitting device may be received and a distance between the WTRU and the transmitting device may be determined.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present invention relates to sidelink transmission-reception distances, and more particularly to systems, methods, and devices for determining and operating sidelink transmission-reception distance relationships. [Background technology]

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

[0003] Systems, methods, and devices for determining and operating a sidelink transmit-receive distance relationship are disclosed herein. In one example, a wireless transmit-receive unit (WTRU) may be configured with a combination of range information and zone configuration. The WTRU receives an indication of a particular range information requirement and determines its own zone location based on the configured information and a location means (e.g., GPS). Additionally, the WTRU may receive zone location information of a transmitting device and determine the distance between the WTRU and the transmitting device.

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which reference characters indicate like elements and in which: [Brief explanation of the drawings]

[0005] [Figure 1A] FIG. 1 is a system diagram of an example communication system in which one or more disclosed aspects may be implemented. [Figure 1B]1B is a system diagram illustrating an example WTRU (Wireless Transmit / Receive Unit) that may be used within the communication system illustrated in FIG. 1A according to one aspect. [Figure 1C] 1B is a system diagram illustrating an example RAN (Radio Access Network) and an example CN (Core Network) that may be used within the communication system illustrated in FIG. 1A according to one embodiment. [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A according to one embodiment. [Figure 1E] FIG. 1 is a system diagram illustrating an example architecture for Vehicle to Everything (V2X) communications. [Figure 2] 10 illustrates an example of determining the TX-RX distance based on a local zone. [Figure 3] 1 illustrates an example of an MCR that includes multiple WTRUs. [Figure 4] Illustrate examples of how different MCRs require different zone configurations. [Figure 5] 1 illustrates an exemplary process for calculating TX-RX distance based on MCR. DETAILED DESCRIPTION OF THE INVENTION

[0006] The following are abbreviations and acronyms that may be mentioned in this specification: 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., depending on the cyclic prefix), Channel Quality Indicator (CQI), Channel Occupancy Ratio (CR), Cyclic Redundancy Check (CRC), Channel State Information (CSI), Device to Device Transmissions (D2D) (e.g., LTE sidelink), Downlink Control Information (DCI), Digital Fourier Transform spread OFDM (DFT-s-OFDM), Downlink (DL), Demodulation Reference Signal (DMRS), Feed Forwarding (FB) Back (Feedback), FDD (Frequency Division Duplexing), FDM (Frequency Division Multiplexing), LBT (Listen-Before-Talk), LLC (Low Latency Communications), LTE (Long Term Evolution) (e.g., 3GPP LTE R8 and later), MAC (Medium Access Control), NACK (Negative ACK), MBB (Massive Broadband Communications), MC (MultiCarrier),Multi-carrier), Modulation and Coding Scheme (MCS), Out-Of-Band (OOB) (e.g., emissions), Total available WTRU power in a given TI (Pcmax), 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-RSRP (PSSCH Reference Signal Received Power), Quality of Service (QoS) (e.g., from a physical layer perspective), Radio Network Identifier (RNTI), Radio Resource Control (RRC), Radio Resource Management (RRM), Receiver (RX), Reference Signal (RS), Round-Trip Time (RTT), and SL Received Signal Strength (S-RSSI). Indicator), SL (Side Link), SS (Synchronization Signal), SSS (Secondary Synchronization Signal), TB (Transport Block), TDD (Time-Division Duplexing), TDM (Time-Division Multiplexing), TTI (Transmission Time Interval), TRP (Transmission / Reception Point), TX (Transmitter), TRX (Transceiver), UL (UplinkUplink), URLLC (Ultra-Reliable and Low Latency Communications), V2X (Vehicular to Everything communications).

[0007] 1A is a system diagram illustrating an example communications system 100 according to an example architecture. Communications system 100 may be a multiple-access system providing content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communications system 100 may enable the multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communications system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (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 (OFDM), filter bank multicarrier (FBMC), etc.

[0008] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and 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 will be understood that any number of WTRUs, base stations, networks, and / or network elements are contemplated for any use case. Each of WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may all be referred to as stations (STAs) and may be configured to transmit and / or receive wireless signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc.

[0009] Sometimes, the WTRU may also be a vehicle or a road side unit (RSU). In one example, the WTRU may be physically integrated into the vehicle, where the components of the WTRU are physically separated. In one example, the WTRU is functionally connected to the vehicle. In one example, the WTRU may be removably attached to the vehicle. In one example, the WTRU may be permanently attached to the vehicle. In one example, the WTRU may be a representation of the vehicle and its physical characteristics (e.g., size, speed, location, etc.). Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a terminal, a device, a UE, or a vehicle.

[0010] Additionally, the communications system 100 may 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 wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNodeB (eNB), a home NodeB, a home eNodeB, a next generation NodeB such as a gNodeB (gNB), a new radio NodeB (NR), a site controller, an access point (AP), a wireless router, etc. While the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0011] The base station 114a may be part of the RAN 104, which may further include other base stations and / or network elements (not shown), such as, for example, a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies and may be referred to as a cell (not shown). The frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services over a particular geographic area, which may be relatively fixed or may change over time. Furthermore, a cell may be partitioned into cell sectors. For example, the cell associated with the base station 114a may be partitioned into three sectors. Thus, in one aspect, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an aspect, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0012] 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., RF (radio frequency), microwave, centimeter wave, micrometer wave, IR (infrared), UV (ultraviolet), visible light, etc.). The air interface 116 may be established using any suitable RAT (radio access technology).

[0013] More specifically, as mentioned above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as, for example, CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. 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 establish the air interface 116 using, for example, wideband CDMA (WCDMA). 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 ​​Uplink (UL) Packet Access (HSUPA).

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

[0015] In an aspect, the base station 114a and the WTRUs 102a, 102b, 102c may establish the air interface 116 using NR and may implement a radio technology such as NR radio access.

[0016] In an aspect, 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 implement both LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized 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).

[0017] In other aspects, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as, for example, IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-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), GERAN (GSM EDGE), etc.

[0018] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as, for example, a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, etc. In one aspect, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as, for example, IEEE 802.11 to establish a wireless local area network (WLAN). In an aspect, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as, for example, IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another aspect, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 through the CN 106.

[0019] The RAN 104 may be in communication with the CN 106 and may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as, for example, different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as, for example, user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 and / or CN 106 may be in direct or indirect communication with other RANs employing the same RAT as the RAN 104 or a different RAT. For example, the CN 106, in addition to being connected to the RAN 104, which may utilize NR radio technology, may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0020] Additionally, the CN 106 may serve 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 providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as transmission control protocol (TCP), user datagram protocol (UDP), and / or IP in the TCP / IP Internet Protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs that may employ the same RAT as the RAN 104 or a different RAT.

[0021] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with separate wireless networks over separate wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and with a base station 114b, which may employ an IEEE 802.11 radio technology.

[0022] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include multiple components / elements, such as, among others, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the above elements without departing from the spirit and scope of the present invention.

[0023] The processor 118 may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in conjunction 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, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0024] The transmit / receive element 122 may be configured to transmit or receive signals to a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0025] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO techniques. Thus, in one aspect, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0026] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, for example, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate over multiple RATs, such as NR and IEEE 802.11.

[0027] The processor 118 of the WTRU 102 may be coupled to and may receive user input data via a speaker / microphone 124, a 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). Further, the processor 118 may output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 may access information and store data in any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), 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, etc. In other aspects, the processor 118 may access information and store data in memory that is not physically located in the WTRU 102, such as in a server or host computer (not shown).

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

[0029] Additionally, the processor 118 may be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals being received from two or more neighboring base stations. It will be understood that the WTRU 102 may obtain location information through any suitable location-determination method without departing from the spirit or scope of the present invention.

[0030] Additionally, the processor 118 may be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0031] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the UL (e.g., for transmission) and DL (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference, either by hardware (e.g., a choke) or signal processing by a processor (e.g., a separate processor (not shown) or by the processor 118). In an aspect, the WTRU 102 may include a half-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be half-duplex.

[0032] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an example architecture. As mentioned above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. Additionally, the RAN 104 may be in communication with the CN 106.

[0033] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it will be understood that the RAN 104 may include any number of eNode-Bs without departing from the spirit and scope of the present invention. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one aspect, the eNode-Bs 160a, 160b, and 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.

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

[0035] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the above-mentioned elements are depicted as part of the CN 106, it will be understood that any of the just-mentioned elements may be owned and / or operated by an entity other than the CN operator.

[0036] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. 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.

[0037] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. In general, the SGW 164 may route and forward user data packets to the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as, for example, anchoring the user plane during inter-eNode B handovers, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

[0038] The SGW 164 may be connected to a PGW 166 that may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0039] The CN 106 may facilitate communication 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 communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IMS (IP Multimedia Subsystem) server) that serves 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.

[0040] Although the WTRU is described as a wireless terminal in the examples herein, it is expected that in certain scenarios, such a terminal may use a wired communication interface with the communication network (e.g., temporarily or permanently).

[0041] In a typical aspect, the other network 112 may be a WLAN.

[0042] A WLAN in 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 have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and out of the BSS. Traffic to a STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within a BSS may be routed through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be routed between (e.g., directly between) a source and destination STA via a direct link setup (DLS). In one exemplary aspect, the DLS may use 802.11e DLS or 802.11z TDLS (tunneled DLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication is sometimes referred to herein as an "ad hoc" mode of communication.

[0043] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically configured width. The primary channel may be the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In a typical aspect, CSMA / CA (Carrier Sense Multiple Access / Collision Avoidance) may be implemented, for example, in an 802.11 system. With CSMA / CA, STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may backoff. One STA (e.g., only one station) may transmit in a given BSS at any given time.

[0044] For example, a HT (high throughput) STA may use a 40 MHz wide channel for communication by combining a 20 MHz primary channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0045] A Very High Throughput (VHT) STA may support channels of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz width. A 40 MHz and / or 80 MHz channel may be constructed by combining contiguous 20 MHz channels. A 160 MHz channel may be constructed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, sometimes referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may proceed to a segment parser, which may segment the data into two streams. IFFT (inverse fast Fourier transform) processing and time-domain processing may be performed on each stream separately. The streams may be mapped onto two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations for the 80+80 configuration described above may be reversed and the combined data may be sent to the MAC (Media Access Control).

[0046] Sub-1 GHz modes of operation are supported by 802.11af and 802.11ah. The operating bandwidths of the channels and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TVWS (TV White Space) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support Meter Type Control / Machine-Type Communications (MTC), such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including support (e.g., only support) for limited and / or limited bandwidths. An MTC device may include a battery with a battery life above a threshold (eg, to maintain a very long battery life).

[0047] A WLAN system that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, includes a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, the primary channel may be 1 MHz wide for a STA (e.g., an MTC-type device) that supports (e.g., only supports) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration may depend on the state of the primary channel. If the primary channel is busy, for example, due to a STA (that only supports a 1 MHz mode of operation) transmitting to the AP, then all available frequency bands may be considered busy even if most of the available frequency bands remain idle.

[0048] In the United States, the available frequency bands that may be used by 802.11ah are 902 MHz to 928 MHz. In South Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0049] 1D is a system diagram illustrating the RAN 104 and the CN 106 according to an example architecture. As mentioned above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. Additionally, the RAN 104 may be in communication with the CN 106.

[0050] The RAN 104 may include gNBs 180a, 180b, and 180c, although it will be understood that the RAN 104 may include any number of gNBs without being inconsistent with an aspect. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one aspect, the gNBs 180a, 180b, and 180c may implement MIMO techniques. For example, the gNBs 180a, 180b may utilize beamforming to transmit and / or receive signals to the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit and / or receive wireless signals to the WTRU 102a. In an aspect, the gNBs 180a, 180b, and 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of the just-mentioned component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an aspect, the gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0051] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for separate transmissions, separate cells, and / or separate portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or various absolute time lengths).

[0052] 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 another RAN (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as an eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput in serving the WTRUs 102a, 102b, 102c.

[0053] 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, scheduling of users in the UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0054] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one SMF (Session Management Function) 183a, 183b, and possibly a DN (Data Network) 185a, 185b. While the above-mentioned elements are depicted as part of the CN 106, it will be understood that any of the just-mentioned elements may be owned and / or operated by an entity other than the CN operator.

[0055] 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 WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling sessions of separate protocol data units (PDUs) with separate requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service being utilized for the WTRUs 102a, 102b, 102c. For 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, services for MTC access, etc. The AMFs 182a, 182b may provide control plane functionality for switching between the RAN 104 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0056] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. Additionally, the SMFs 183a, 183b may be connected to the UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as, for example, managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0057] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface and 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. The UPFs 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, etc.

[0058] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IMS (IP Multimedia Subsystem) 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 aspect, the WTRUs 102a, 102b, 102c may be connected to the local DNs 185a, 185b through an N3 interface to the UPFs 184a, 184b, and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0059] At times, one or more emulation devices (not shown) may perform the functions described herein, such as, for example, the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein. An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device may be used to test other devices and / or to simulate network and / or WTRU functionality.

[0060] The emulation device may be designed to implement one or more tests of other devices in a lab environment and / or in an operator's network environment. For example, one or more emulation devices may perform one or more, or all, functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communications network to test other devices in the communications network. One or more emulation devices may perform one or more, or all, functions while temporarily implemented / deployed as part of a wired and / or wireless communications network. The emulation device may be directly coupled to another device for purposes of testing and / or testing using over-the-air (OTA) wireless communications.

[0061] The one or more emulation devices may perform one or more functions, inclusive, while not implemented / deployed as part of a wired and / or wireless communications network. For example, the emulation devices may be utilized in testing scenarios in a testing laboratory and / or in an undeployed (e.g., testing) wired and / or wireless communications network to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may, for example, include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0062] 1E is a system diagram illustrating an example architecture for vehicle-to-everything (V2X) communications. In a V2X scenario, a WTRU 102a may communicate with one or more WTRUs 102b, 102c, 102d via sidelink (SL) communications using an air interface 116. There may be several types of SL communications, such as unicast, broadcast, groupcast, etc. The 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 described herein.

[0063] In the context of V2X communications, a WTRU may select a transmission resource pool to communicate with another WTRU or a base station. The transmission resource pool may correspond to the identity of the 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 discussed herein, WGS84 is a known model and may generally include support for a mapping technique, e.g., an Earth-related coordinate system, and a positioning system, e.g., satellite navigation (e.g., GPS).

[0064] The WTRU may receive the area (pre)configuration in a message (e.g., SystemInformationBlockType21 or SL-V2X-Preconfiguration), which may include one or more of the following parameters: L: zoneLength in meters, W: zoneWidth in meters, NX: zoneIDLongiMod, and / or NY: zoneIDLatiMod.

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

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

[0067] At times, during wireless communications, such as the example of FIG. 1E, one or more factors may cause errors when receiving a transmission. For example, there may be environmental interference that may degrade signal quality and / or reception capability, which may ultimately result in errors in the transmission. To address the just-mentioned errors, a Hybrid Automatic Repeat Request (HARQ) process may be utilized. HARQ may be used in various wireless communications 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 with errors. For example, the feedback may indicate that certain components of the transmission were not received and / or need to be retransmitted.

[0068] For some transmission types, the use of HARQ may be based on distance information and / or signal-to-noise information. For example, SL groupcast transmissions may use HARQ to address 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, and for SL unicast transmissions, HARQ may be used for potential transmission issues between two WTRUs. Sometimes, a WTRU may decide to employ 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 have knowledge of the distance between itself and the V2X WTRU that sent the packet. The just-mentioned features may be useful when evaluating whether certain NR V2X quality of service (QoS) requirement(s) (e.g., range for groupcast transmissions) are met. Given the high WTRU mobility that may be supported in advanced V2X use cases, it is important for a V2X WTRU to update the TX-RX distance in a timely manner and with a degree of accuracy, as the TX-RX distance may change at a rapid rate. Thus, a WTRU needs to be able to determine its position (e.g., TX-RX distance) relative to another WTRU, and to be able to do so in an efficient manner.

[0069] In some cases, the TX-RX distance may not be derived using PHY measurements, such as SL-RSRP, which is based on a linear average by power of resource elements occupied by a physical SL feedback channel (PSSCH) DMRS within a physical resource block (PRB) assigned to an associated physical SL control channel (PSCCH). SL-RSRP may be used to estimate path loss or "radio distance," but may not necessarily be translatable to geographic distance because the SL-RSRP measurement(s) take into account radio signal propagation, including interference, shadowing, and multipath conditions. Therefore, one or more techniques for obtaining geographic TX-RX distance are required.

[0070] Furthermore, in some cases, the dynamic determination of the TX-RX distance may incur signaling overhead. Since the TX-RX distance may be used to determine whether a HARQ feedback transmission is used for a received PSSCH transmission, the WTRU may evaluate the TX-RX distance on some basis (e.g., on a per transport block (TB) basis considering the high speed nature of the V2X WTRU, or in LTE, or NR, etc.). Therefore, the dynamic determination of the TX-RX distance together with related information may need to be transmitted using radio layer signaling, such as sidelink control information (SCI). Therefore, one or more techniques to reduce the incurred signaling overhead are needed.

[0071] As described herein, when describing HARQ transmissions on a Physical SL Feedback Channel (PSFCH) and associated data transmissions on a PSSCH, a WTRU transmitting a PSSCH and associated PSCCH may be referred to as a TX WTRU. A WTRU receiving a PSCCH and PSSCH, and therefore an associated PSFCH, may be referred to as an RX WTRU. Additionally, as described herein, zone, local zone, subzone, and PHY zone may be used interchangeably.

[0072] In general, the WTRU may determine and / or (pre-)configure an association (e.g., a mapping and / or table) between zone size and QoS range requirements 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.

[0073] In one approach to determining the TX-RX distance, the WTRU may partition the geographical area in which the WTRU resides (e.g., SL area) into zones (e.g., local zones). FIG. 2 illustrates an example of determining the TX-RX distance based on local zones. 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 the length and width of the zone, QoS range requirements, and / or TX-RX distance accuracy. Each local zone may have a length and width, such as a local zone length 235 and a local zone width 234. Each area may have its own set of local zones.

[0074] As shown, there may be one or more WTRUs, such as WTRU 201, WTRU 202, WTRU 203, and WTRU 204. In the example just described, WTRU 201 is in communication with WTRU 202, and WTRU 203 is in communication with WTRU 204.

[0075] Thus, the WTRU may determine the denominator (N) of the local zones and divide an area into N x N local zones; in the example shown, the division may have an equal number of local zones in both longitude and latitude; however, in other examples not shown, the division may not be equal for longitude and latitude. Thus, the length and width of a local zone may be Area_Length / N and Area_Width / N meters, respectively. For purposes of the current example, the area is square and may have the same number of local zones in latitude as in longitude.

[0076] The WTRU may assign a Local_Zone_ID to each local zone based on one or more (pre-)configured rules. In one approach, the WTRU may be (pre-)configured to assign integers as Local_Zone_IDs, starting from zero and continuing upward, first for longitude and then latitude. For the example in FIG. 2, arrow 241 indicates that the Local_Zone ID starts at 0, increments by 1 for each local zone, moving to the right and then upward as it reaches the edge of the area. In the example just given, the WTRU may divide the area into 64 local zones (i.e., N=8) and assign a Local_Zone_ID to each local zone as illustrated, thus starting with a Local_Zone ID of 0 at the bottom left and the final Local_Zone ID being 63 at the top right.

[0077] In another approach, the WTRU may be (pre-)configured to assign an integer to the Local_Zone_ID that includes the Area_ID. For example, the WTRU may assign a Local_Zone_ID equal to Local_Zone_ID+Area_ID*N2. What has just been mentioned may differ in that signaling may be added to carry the Local_Zone_ID information.

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

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

[0080] The RX WTRU may determine the TX-RX distance based on the inter-Local-Zone distance, as in 236a and 236b. First, the RX WTRU may determine whether the RX WTRU and the TX WTRU are located in the same area based on the received Area_ID information of the TX WTRU.

[0081] If the TX WTRU and RX WTRU are not in the same area, then the RX WTRU may determine delta 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.

[0082] At times, the RX WTRU may calculate RX_X1 and RX_Y1 as described herein and derive TX_X1 and TX_Y1 based on TX_X1=TX WTRU Area_ID ModNX, TX_Y1=Floor(TX WTRU Area_ID / NX). Alternatively, TX_X1 and TX_Y1 may be indicated in a PSCCH associated with a PSSCH transmission. For example, the WTRU may indicate each value in a 2-bit field of the SCI.

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

[0084] If the RX WTRU and the TX WTRU are located in the same area (e.g., the TX Area_ID is equal to the RX Area_ID), the WTRU may determine the TX-RX distance based on: TX-RX distance ≈ 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).

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

[0086] If the RX WTRU and TX WTRU are located in different areas (i.e., the TX Area_ID may not be equal to the RX Area_ID), the WTRU may determine the TX-RX distance based on: TX-RX distance ≈ 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).

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

[0088] Note that when using zones as described herein, 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.

[0089] In one approach to determining TX-RX distance, an area may be partitioned into a grid of geographic boundaries (e.g., zones, local zones, sub-zones, etc.), resulting in a sub-zone configuration, which may be based on range requirements dictated by the network. Furthermore, each sub-zone configuration is specific to a V2X service, and each may have different minimum communication range (MCR) requirements. FIG. 3 illustrates an example of an MCR that includes multiple WTRUs. The MCR 311 is shown as a circle with a dashed line, indicating the minimum distance for one WTRU 301 communicating with one or more other WTRUs (e.g., WTRUs 302, 303, 304, and / or 305). The WTRU TX-RX distance may be shown with a solid line for each WTRU communicating with WTRU 301. For the example just described, WTRU 301 is the origin of the MCR 311. As shown, WTRUs 302 and 303 are outside of MCR 311 and would not be able to perform certain functions (e.g., HARQ) with respect to WTRU 301. Additionally, WTRUs 304 and 305 are within the MCR and therefore would be able to communicate with WTRU 301.

[0090] FIG. 4 illustrates an example of how different MCRs require different zone configurations. Generally, a WTRU may be (pre-)configured with a set of subzone configurations. Each subzone configuration may include modulo and dimension parameters. The dimension parameters may include, for example, length and width for a rectangular subzone configuration. In one example (e.g., shown in FIG. 4), a rectangular subzone may be a square with each subzone having the same length and width. In another example, a subzone configuration may include side lengths for an octagonal subzone. Sometimes, the WTRU may determine the subzone configuration with each configured V2X service based on the MCR requirements of the V2X service. For example, a V2X service with a small MCR requirement may require better distance measurement accuracy, and therefore smaller subzones may be used.

[0091] In the example of FIG. 4, two MCRs 411, 421 are shown. For each exemplary MCR, the entire area may have the same or approximately the same dimensions 406X and 406Y. Depending on the MCR, the area may be partitioned differently, with each subzone having a different length and width, as shown in 430. Note that for demonstration purposes, each WTRU (401, 402, 403, 404, 405) may be in the same location in a given area, so that different subzone configurations may be illustrated. As shown, MCR 411 may represent a V2X service with smaller MCR requirements, which demand better distance measurement accuracy, compared to MCR 421.

[0092] At times, the WTRU may use the subzone configuration associated with the smallest MCR configured for any active sidelink radio bearer (SLRB) at the WTRU. Alternatively, the WTRU may use different subzone configurations, where each subzone configuration is used for transmitting data associated with each SLRB or group of SLRBs.

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

[0094] 5 illustrates an example process for calculating the TX-RX distance based on the MCR. Generally, the RX WTRU may determine the subzone ID of the RX WTRU to use based on the MCR indicated in the received PSCCH, and calculate the TX-RX distance using the determined subzone ID of the RX WTRU and the subzone ID of the TX WTRU received on the PSCCH (e.g., SCI). The RX WTRU may determine the subzone configuration to use based on the MCR indicated in the PSCCH received from the TX WTRU. The RX WTRU may calculate the subzone ID of the RX WTRU based on the determined subzone configuration (e.g., using a rectangular configuration).

[0095] 5 provides an example process with steps in a particular order, those skilled in the art will understand that any steps may be optional and may be performed in a different order than given. Initially, the RX WTRU may be (pre-)configured with one or more MCR(s). In one example, each MCR may be associated with a subzone configuration that defines how the area in question is partitioned and identified to the associated WTRU, as will now be described further herein. At 501, the RX WTRU may receive control information (e.g., SCI) on a control channel (e.g., PSCCH) from the TX WTRU. The control information may include an indication of the TX WTRU's MCR and / or subzone ID. In one example, the MCR may be specific to the TB's V2X service transmitted on the associated PSSCH. At 502, the RX WTRU may determine a subzone configuration based on the received MCR. At 503, the RX WTRU may determine its own subzone ID based on the determined subzone configuration and the WGS84 model. In some cases, a set of RX WTRU subzone IDs may be calculated and updated for each supported MCR, and the RX WTRU may select one RX WTRU subzone ID based on the MCR indicated in the PSCCH from the TX WTRU.

[0096] At 504, the RX WTRU may determine a TX-RX distance based on the TX WTRU's subzone ID and the RX WTRU's subzone ID. At 505, the RX WTRU may receive a data transmission associated with previously received control information from the TX WTRU (e.g., a TB on 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 decide not to send a HARQ ACK / NACK if the determined WTRU TX-RX distance exceeds the MCR received on the PSCCH from the TX WTRU.

[0097] 5, to determine the subzone ID, the RX WTRU may calculate the following (e.g., a rectangular scenario): X1=Floor (X / L) Mod NX and Y1=Floor (Y / W) Mod NY, and the RX WTRU's subzone ID=Y1*NX+X1. For the calculation just described, X may be the geodesic distance in longitude between the RX WTRU's current location and the geographic coordinate (0,0), and Y may be the geodesic distance in latitude between the RX WTRU's current location and the geographic coordinate (0,0). Additionally, L may be the SubzoneLength in meters, W may be the SubzoneWidth in meters, NX may be SubzoneIdLongiMod, and NY may be SubzoneIdLatiMod. Sometimes, each subzone may be a square with a length the same as its width.

[0098] In the example for FIG. 5, once the subzone ID is determined, the WTRU may determine the TX-RX distance. The RX WTRU may calculate the TX-RX distance based on the delta between the TX subzone ID and the RX subzone ID. In one example, the RX WTRU may look up a pre-calculated mapping between the subzone ID delta and the geographical distance. In another example, the RX WTRU may calculate the distance based on the following formula: WTRU TX-RX distance ≈ inter-subzone distance = SQRT(((ABS(Floor(TX sub_zone_ID,NX) - Floor(RX sub_zone_ID,NX))*W)² + (ABS(MOD(TX sub_Zone_ID,NY) - MOD(RX sub_Zone_ID,NY))*L)²).

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

[0100] In one approach to determining the TX-RX distance, the WTRU TX-RX distance may be determined based on geodesic distance, such as absolute geodesic distance or differential geodesic coordinates.

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

[0102] For the just-described scenario, the RX WTRU may determine the TX-RX distance by applying TX-RX distance = SQRT((TX_X-RX_X)² + (TX_Y-RX_Y)²) 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). Furthermore, the TX WTRU may transmit 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 many bits of signaling.

[0103] To calculate the TX-RX distance based on the differential geodesic distance, the WTRU may determine the differential geodesic coordinates based on the area configuration 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.

[0104] The RX WTRU may determine the TX-RX distance based on the received differential geodetic coordinates (TX_X2, TX_Y2), its own geodetic coordinates (X, Y), and the Area ID. The RX WTRU may determine whether the RX WTRU and the TX WTRU are located in the same area based on the received Area_ID of the TX WTRU. If the TX WTRU and the RX WTRU are not in the same area, the RX WTRU may determine a delta value 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:

[0105] The RX WTRU may calculate RX_X1 and RX_Y1 as described herein and derive TX_X1 and TX_Y1 based on TX_X1=TX WTRU Area_ID ModNX, and TX_Y1=Floor(TX WTRU Area_ID / NX).

[0106] In some circumstances, TX_X1 and TX_Y1 may be indicated on a PSCCH associated with a PSSCH transmission, for example, the WTRU may indicate each value in a 2-bit field of the SCI.

[0107] The RX WTRU may then determine TX_X / TX_Y based on the following, where 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).

[0108] Alternatively, the WTRU may determine the differential geodetic coordinates (X2, Y2) based on a (pre-)configured local geographical reference point. In one example, the local geographical reference point may be (X_gNB, Y_gNB) of the gNB on which the WTRU is camped. In another example, the local geographical reference point may be a group leader in a groupcast transmission. In another example, the local geographical reference point may be a V2X WTRU providing a synchronization source. The WTRU may receive the above geographical information via downlink higher layer signaling and determine the differential geodetic coordinates (X2, Y2) based on X2 = X_WTRU - X_gNB and Y2 = Y_WTRU - Y_gNB.

[0109] The RX WTRU may determine the TX-RX distance based on the received differential geodetic coordinates (TX_X2, TX_Y2), its own geodetic coordinates (X, Y), and the Area 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 similarly may determine the TX-RX distance based on TX-RX distance=SQRT((TX_X-RX_X)2+(TX_Y-RX_Y)2).

[0110] 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 bit field of the PSCCH associated with the PSSCH transmission. In another example, the WTRU may include the above information in higher layer signaling (e.g., MAC CE and / or RRC signaling).

[0111] In one approach to determining TX-RX distance, the WTRU may base the TX-RX distance determination on the WTRU ID. The WTRU may be (pre-)configured with WTRU identity information (e.g., the WTRU's source ID and destination ID) at both the upper layer and the PHY layer. Additionally, in groupcast transmissions, group member WTRUs may be configured (e.g., by upper layers) with a group-specific WTRU ID.

[0112] In one case, the WTRU may associate a WTRU ID with the WTRU's location information based on, for example, a zone ID, a subzone ID, geographic coordinates, etc. For unicast transmissions, the WTRU may select an L1 source ID based on the WTRU's location information. For example, the RX WTRU may obtain the TX WTRU's source ID information via RRC signaling during 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's location information (e.g., location within the platoon). The RX WTRU may determine the TX WTRU's location based on the TX WTRU's group-specific WTRU ID.

[0113] To keep the location information of an associated WTRU up to date, the WTRU may periodically update the location information. In one example, the WTRU may transmit the zone ID, subzone ID, and / or geolocation information in MAC CE or RRC signaling. In another example, the WTRU may transmit the location information, such as the zone ID and subzone ID, along with the L1 source ID in the PHY feedback channel.

[0114] Sometimes, the WTRU may determine location information based on one or more PSFCH resources. Furthermore, the WTRU's location information, such as zone ID and subzone ID, may be associated with the PSFCH resource (e.g., including the time domain, frequency domain, and code domain). In the present case, the location information may not be explicitly transmitted in the PHY feedback channel, but rather may be conveyed in an implicit manner. For example, time-frequency resource 1 may be for a subset of zone IDs or subzone IDs, while time-frequency resource 2 may be for another subset of zone IDs or subzone IDs. By detecting which PSFCH resource the PHY feedback occupies, the RX WTRU may know the TX WTRU location information for the PSFCH transmission.

[0115] In other cases, the WTRU may update its location information associated with its L1 source ID when one or more conditions occur, such as when the WTRU ID is changed by higher layers for security reasons (e.g., the WTRU's source ID may be changed), the TX-RX distance exceeds a (pre-)configured threshold, the WTRU's speed exceeds a (pre-)configured threshold, the CSI reports a request, and / or periodically, where the periodicity of the above updates may depend on the WTRU's speed (e.g., a faster WTRU may update its location information associated with its L1 ID more frequently).

[0116] Sometimes, implicit WTRU location indication using the WTRU's L1 ID may use a bit field in the SCI to convey the WTRU's 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.

[0117] In another case, the WTRU may transmit location information in the SCI for some scenarios (e.g., when the location information cannot be associated with the source ID), while transmitting only the L1 source ID in other scenarios (e.g., the source ID can be associated with the location information). 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 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 WTRU's location without additional overhead (e.g., based on association known by the RX WTRU of transmission and retransmission resources); QoS of transmission, where the WTRU may send a location-related L1 ID for transmissions associated with an MCR; data vs. control, where the WTRU may send a location-related L1 ID only for control transmissions (e.g., PC5 RRC) and not for data, or vice versa; and / or location-associated vs. non-location-associated, depending on the speed of the WTRU.

[0118] For any of the TX-RX distance determination approaches described herein, in some situations the location of either the TX WTRU or the RX WTRU may be unknown.

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

[0120] If the TX WTRU indicates "unknown location" to the RX WTRU in the SCI, the RX WTRU may send a NACK if it is not able to decode the message, regardless of other parameters, such as the MCR. Conversely, as further described in the example of FIG. 5, the RX WTRU may decide to send HARQ NACK feedback if it is able to decode the SCI. Specifically, the WTRU may provide NACK-based feedback for unicast / groupcast, and the WTRU may only send a NACK if it is not able to decode the message. If the location information of the TX WTRU is indicated in the SCI, the WTRU may send a NACK if it is not able to decode the message and the TX-RX distance is less than the MCR indicated in the SCI.

[0121] When the TX WTRU indicates "unknown location" to the RX WTRU in the SCI, the WTRU may use the SL-RSRP to decide to send HARQ NACK feedback. Alternatively, the WTRU may use the path loss between the TX WTRU and the RX WTRU to decide to send HARQ NACK feedback. Specifically, when the TX WTRU indicates an "unknown location" state in the SCI, the RX WTRU may send a NACK if 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 includes the TX WTRU location, the RX WTRU may decide 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, if the location information of the TX WTRU is indicated in the SCI, the RX WTRU may use the TX-RX distance to decide to send HARQ NACK feedback.

[0122] If the TX WTRU indicates "unknown location" to the RX WTRU in the SCI, the RX WTRU may decide to send HARQ NACK feedback based on location information obtained from a previously received location for the TX WTRU. For example, the RX WTRU may decide to use the TX WTRU's location information previously received from the TX WTRU to calculate the TX-RX distance associated with the received TB. Additionally, the RX WTRU may determine whether the time period from receipt of the TX WTRU location to transmission of the TB exceeds a threshold, which 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).

[0123] If the TX WTRU is able to indicate "unknown location" to the RX WTRU in the SCI, the TX WTRU may decide whether to retransmit based on feedback from the RX WTRU. In one example, the TX WTRU may be configured with two retransmission procedures, where one procedure may be used when the TX WTRU's location information is available and the other procedure may be used when the location information is not available.

[0124] In another example, the TX WTRU may be configured with a maximum number of retransmissions greater than one, e.g., one value may be used for cases where location information is available and another value may be used for cases where location information for the TX WTRU is not available.

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

[0126] For any of the TX-RX distance determination approaches described herein, in some circumstances, the WTRU may use a (pre-)configured and / or determined zone (e.g., area, SL zone, subzone, local zone, etc.) for resource pool selection.

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

[0128] In some situations, the WTRU may select whether to use a zone-based or non-zone-based TX resource pool for transmitting data based on any of the following aspects related to the type of data: size of the data packet transmission; periodicity of the data transmission; speed of the WTRU; and / or QoS parameters, or any combination of the above factors.

[0129] Regarding the size of data packet transmissions, for example, the WTRU may be configured to transmit small packets in a zone-based pool configuration. Specifically, the WTRU may be configured with a threshold packet size and may transmit all packets with a size below the threshold using a zone-based TX resource pool.

[0130] Regarding the periodicity of data transmissions, for example, the WTRU may be configured to transmit all periodic transmissions in a zone-based TX resource pool configuration, e.g., the WTRU may make all transmissions associated with periodic resource reservations made by the WTRU in a zone-based TX resource pool.

[0131] Regarding the speed of the WTRU, for example, the WTRU may decide whether to transmit a particular data packet using a zone-based TX resource pool configuration depending on the WTRU's current speed. Specifically, a WTRU traveling at a speed above a threshold may not transmit in a zone-based TX resource pool.

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

[0133] In situations where the WTRU decides whether to use zone-based resource pool selection based on the type of data, sometimes the data type may be implicitly mapped to a logical channel (LCH). For example, when the WTRU decides whether to use zone-based resource pool selection, the WTRU may decide 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 the TX resource pool configuration (e.g., zone-based or not zone-based) to be used. Furthermore, the WTRU may be configured with conditions (e.g., speed, pool congestion, etc.) under which the above explicit mapping may or may not apply to a particular LCH. Alternatively, the WTRU may be (pre-)configured with LCH properties that implicitly result in mapping the properties to a zone-based TX resource pool configuration. The aforementioned configuration for LCH properties may be obtained from a dedicated configuration, a SIB, or a (pre-)configuration.

[0134] In situations where the WTRU decides whether to use zone-based resource pool selection based on the type of data, sometimes 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 a first LCH during the LCP and may only select subsequent LCHs with the same selection properties following this LCP. Alternatively, the WTRU may receive an indication of the grant type during performance of the LCP. The just-mentioned grant type may indicate that the resources are associated with a zone-based TX pool or a non-zone-based TX pool. The just-mentioned grant type may implicitly indicate a mapping to a zone-based TX resource pool. For example, a grant may indicate a mapping to a specific LCH that implies transmission in a zone-based TX resource pool based on the size of the grant and / or the nature of the grant (e.g., LTE-like grant, legacy-like grant, etc.). The WTRU may be allowed to select from the LCHs for an LCP corresponding to a particular grant type. Specifically, for a grant associated with a zone-based TX resource pool, the WTRU may only select data from the LCHs that are allowed (e.g., by pre-configuration) for transmission in that TX resource pool.

[0135] In situations where the WTRU decides whether to use zone-based resource pool selection based on the data type, resource selection may sometimes take the data type into consideration. The WTRU may trigger resource (re)selection by taking into consideration the data type and association to a zone-based TX resource pool. For example, for a certain LCH that meets the data type criteria or is (pre-)configured by a specific explicit / implicit indication, the WTRU may perform resource selection in the zone-based TX resource pool when data arrives on the LCH and a Mode 2 grant for the zone-based TX resource pool does not yet exist. Alternatively, the WTRU may perform resource selection for all periodic resource reservations in the zone-based TX resource pool and any one-shot or asynchronous resource selection in a non-zone-based resource pool. The WTRU may then determine from which resource pool to perform resource selection based on the logical channels that have data available in their buffers.

[0136] Although the features, techniques, approaches, examples, cases, circumstances, and elements are described above in particular combinations, those skilled in the art will understand that each of the just-described features, techniques, approaches, examples, cases, circumstances, and elements may be used alone or in any combination with the other features, techniques, approaches, examples, cases, circumstances, and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electrical signals (transmitted over wired or wireless connections) and computer-readable recording media. Examples of computer-readable recording 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, and optical media such as magneto-optical media, e.g., 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. [Explanation of symbols]

[0137] 102a WTRU 102b WTRU 102c WTRU 102d WTRU 108 PSTN 110 Internet 112 Network 114 Base Station 116 Air Interface

Claims

1. 1. A method implemented by a first wireless transmit receive unit (WTRU), comprising: receiving configuration information, the configuration information including a set of zone configurations, each zone configuration in the set of zone configurations associated with a respective communication range requirement, each zone configuration in the set of zone configurations having a respective zone-associated length; determining a zone-related length from the set of zone configurations based on a communication range requirement of a transport block (TB), the TB being associated with a vehicle-to-everything (V2X) service; determining a zone ID associated with transmission of the TB based on the length of the zone association and based on location information of the first WTRU; transmitting the determined zone ID associated with the transmission of the TB; A method comprising:

2. 2. The method of claim 1, wherein the determined zone ID is included in control information transmitted on a physical sidelink (SL) control channel.

3. 2. The method of claim 1, wherein the transmission of the TB is a groupcast transmission.

4. 2. The method of claim 1, wherein the transmission of the TB is a data transmission transmitted on a shared channel.

5. 3. The method of claim 2, wherein the control information is SL Control Information (SCI) of a physical sidelink control channel.

6. 10. The method of claim 1, wherein the determined zone ID is transmitted to a second WTRU.

7. 7. The method of claim 6, wherein the transmission of the TB is for the second WTRU.

8. 3. The method of claim 2, wherein the control information includes first stage SL control information and second stage SL control information.

9. a first wireless transmit receive unit (WTRU), a processor; a transceiver connected to said processor; Equipped with the processor and transceiver are configured to receive configuration information, the configuration information including a set of zone configurations, each zone configuration in the set of zone configurations associated with a respective communication range requirement, each zone configuration in the set of zone configurations having a respective zone-associated length; The processor and transceiver are configured to determine a zone-associated length from the set of zone configurations based on a communication range requirement of a transport block (TB), the TB being 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 length of the zone association and based on location information of the first WTRU; The processor and transceiver are configured to transmit the determined zone ID associated with the transmission of the TB. A first WTRU.

10. The first WTRU of claim 9, wherein the determined zone ID is included in control information transmitted on a physical sidelink (SL) control channel.

11. 10. The first WTRU of claim 9, wherein the transmission of the TB is a groupcast transmission.

12. 10. The first WTRU of claim 9, wherein the transmission of the TB is a data transmission transmitted on a shared channel.

13. 11. The first WTRU of claim 10, wherein the control information is SL control information (SCI) of a physical sidelink control channel.

14. 10. The first WTRU of claim 9, wherein the determined zone ID is transmitted to a second WTRU.

15. 15. The first WTRU of claim 14, wherein the transmission of the TB is for the second WTRU.

Images