TW201941555A - Data transmission associated with NR V2X - Google Patents

Abstract

Systems, methods, and instrumentalities are disclosed for data transmission schemes for vehicle/platooning scenarios, e.g., in NR vehicle-to-everything (V2X). V2X communications may support network coding based data transmissions. Channel encoding, channel decoding, and/or signaling are provided, e.g., to support network coding. Sidelink (SL) code block group (CBG) based data transmissions may be supported (e.g. by signaling). Resources may be allocated for V2X transmission modes (e.g. mode 3, mode 4). A resource selection window may be determined (e.g. for mode 4). A redundancy version (RV) may be selected, for example, based on a selected resource. A group-based handover may be supported for vehicle platooning.

Description

NR V2X related data transmission

Cross-reference to related applications

This application claims the priority and rights of US Provisional Application No. 62 / 630,474, filed on February 14, 2018, which is incorporated herein by reference.

Mobile communications continue to evolve. The fifth generation can be called 5G. Previous (traditional) generation mobile communications may be, for example, the fourth generation (4G) long-term evolution (LTE). Mobile radios implement various radio access technologies (RATs), such as new radios (NR). Use cases for NR can include, for example, enhanced mobile broadband (eMBB), ultra-high reliability and low latency communication (URLLC), and large-scale machine-type communication (mMTC).

Systems, methods, and tools are disclosed for wireless data transmission (eg, associated with NR Vehicle to Everything (V2X)). For example, in a platoon scenario, a wireless transmit / receive unit (WTRU) (e.g., a vehicle, a WTRU associated with a vehicle, a WTRU associated with a user of the vehicle, etc.) may transmit data intended for one or more Information about other WTRUs (for example, one or more other vehicles). A WTRU may include a receiver, a transmitter, a processor, and the like, for example, to implement the features described herein. In an example, the WTRU may have a transmission block (TB) to send. The WTRU may append CRC bits to the TB. The WTRU may perform segmentation on the TB with the additional CRC bits. This segment can create multiple code blocks (CB). For example, using network coding as described herein, the WTRU may perform coding associated with the multiple CBs, which may generate multiple network-coded CBs (NC-CB).

Network coding may include one or more of the following. The WTRU that is performing network coding may select a random number of CBs from the plurality of CBs. The WTRU may perform an XOR operation on the random number of CBs. The WTRU may append CRC bits to the result of the XOR operation. The selection of the random number of CBs, the execution of the XOR operation, and the addition of the CRC bit to the result of the XOR operation may be performed multiple times. In an example, the multiple times (eg, a degree distribution) may be determined.

For example, after the network is coded, the WTRU may apply LDPC coding to the multiple NC-CBs. The LDPC code used for LDPC encoding may be based on a sub-matrix of a parity check matrix. The WTRU may apply channel interleavers and / or perform modulation. The WTRU can send information (eg, multicast, multicast, etc.).

A detailed description of illustrative examples will now be described with reference to the various drawings. Although the description provides detailed examples, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

FIG. 1A is a diagram illustrating an exemplary communication system 100 that can implement the disclosed embodiments. The communication system 100 may be a multiple access system that provides multiple wireless users with content such as voice, data, video, messaging, and broadcasting. The communication system 100 can 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 DFT extended OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtering OFDM, and filter bank multi-carrier (FBMC), etc. Wait.

As shown in FIG. 1A, the communication system 100 may include a wireless transmission / reception unit (WTRU) 102a, 102b, 102c, 102d, RAN 104/113, CN 106/115, a public switched telephone network (PSTN) 108, the Internet Circuit 110 and other networks 112, however it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, 102d (each of which may be referred to as a "station" and / or "STA") may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile station, fixed or mobile subscriber unit, subscription-based unit, pager, mobile phone, personal digital assistant (PDA), smart phone, laptop, small laptop, personal computer, wireless Monitors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head mounted displays (HMD), vehicles, drones, medical devices and applications (such as remote surgery), industrial equipment, and Applications (such as robots and / or other wireless devices operating in an industrial and / or automated processing chain environment), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

The communication system 100 may further include a base station 114a and / or a base station 114b. Each base station 114a, 114b may be configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate its access to one or more communication networks (e.g., CN 106/115, Internet) 110, and / or other networks 112). For example, the base stations 114a, 114b may be base transceiver stations (BTS), node B, e-node B, local node B, local e-node B, gNB, NR node B, site controller, access point (AP ), And wireless routers. Although each base station 114a, 114b is described as a single element, it should be understood. The base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

The base station 114a may be part of the RAN 104/113, and the RAN may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), Relay nodes and so on. 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 cell (not shown). These frequencies can be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. Cells can provide wireless service coverage for specific geographic areas that are relatively fixed or are likely to change over time. Cells can be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Therefore, in one embodiment, the base station 114a may include three transceivers, that is, one transceiver for each sector of a 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 a cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via an air interface 116, where the air interface may be any suitable wireless communication link such as radio frequency (RF), Microwave, centimeter wave, micro wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

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, base stations 114a and WTRUs 102a, 102b, 102c in RAN 104/113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) ) To build the air interface 115/116/117. 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).

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), where the technology may use long-term evolution (LTE) and / or advanced LTE (LTE-A) and / or Advanced LTA Pro (LTE-A Pro) to establish the air interface 116.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, where the radio technology may use a new radio (NR) to establish the air interface 116.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access as well as NR radio access (eg, using the dual connectivity (DC) principle). Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (such as eNBs and gNBs).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, and 102c may implement, for example, IEEE 802.11 (ie, wireless high-fidelity (WiFi)), IEEE 802.16 (Global Interoperable 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 Rate for GSM Evolution (EDGE) And GSM EDGE (GERAN) and other radio technologies.

The base station 114b in FIG. 1A may be a wireless router, a local Node B, a local eNode B, or an access point, and may use any suitable RAT to facilitate, for example, a business place, a residence, a vehicle, a campus, an industrial facility, an air corridor (Such as for drones) and wireless connections in local areas such as roads. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may use a cellular-based RAT (such as WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or Femtocell. As shown in FIG. 1A, the base station 114 b may have a direct connection to the Internet 110. Therefore, the base station 114b does not need to access the Internet 110 via the CN 106/115.

RAN 104/113 may communicate with CN 106/115, where the CN 106/115 may be configured to provide voice, data, applications, and / or Internet Protocol voice to one or more WTRUs 102a, 102b, 102c, 102d (VoIP) services of any type of network. The data can have different quality of service (QoS) requirements, such as different liquidity requirements, latency requirements, fault tolerance requirements, reliability requirements, data circulation requirements, and mobility requirements. CN 106/115 can provide call control, billing services, mobile location-based services, pre-paid calling, internet connection, video distribution, etc., and / or can perform high-level security functions such as user authentication. Although not shown in Figure 1A, it should be understood that RAN 104/113 and / or CN 106/115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104/113 for communication , Or using a different RAT. For example, in addition to connecting to RAN 104/113 using NR radio technology, CN 106/115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA or WiFi radio technology .

CN 106/115 may also act as a gateway for WTRUs 102a, 102b, 102c, 102d to access PSTN 108, Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network that provides simple legacy telephone service (POTS). The Internet 110 may include a public communication protocol such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet Protocol family. Globally interconnected computer network device system. The other networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the other network 112 may include another CN connected to one or more RANs, where the one or more RANs may use the same RAT or different RATs as the RAN 104/113.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (eg, WTRUs 102a, 102b, 102c, 102d may include multiple transceivers communicating with different wireless networks on different wireless links) . For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may use cellular-based radio technology, and with a base station 114b that may use IEEE 802 radio technology.

FIG. 1B is a system diagram illustrating an exemplary WTRU 102. FIG. As shown in FIG. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, and a removable Memory 132, power supply 134, global positioning system (GPS) chipset 136, and other peripheral devices 138. It should be understood that, while remaining consistent with embodiments, the WTRU 102 may also include any sub-combination of the aforementioned elements.

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 associated with a DSP core, a controller, and a microcontroller , Special integrated circuit (ASIC), field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), state machine, etc. The processor 118 may perform signal encoding, 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. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may also be integrated into one electronic component or chip.

The transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (eg, base station 114a) via the air interface 116. For example, in one embodiment, the transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. For example, in an embodiment, the transmitting / receiving element 122 may be a radiator / detector configured to transmit and / or receive IR, UV, or visible light signals. In an embodiment, the transmission / reception element 122 may be configured to transmit and / or receive RF and optical signals. It should be understood that the transmission / reception element 122 may be configured to transmit and / or receive any combination of wireless signals.

Although the transmit / receive element 122 is described as a single element in FIG. 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may use MIMO technology. Accordingly, in an embodiment, the WTRU 102 may include two or more transmitting / receiving elements 122 (eg, multiple antennas) via the air interface 116 to transmit and receive radio signals.

The transceiver 120 may be configured to modulate a signal to be transmitted by the transmission / reception element 122 and to demodulate a signal received by the transmission / reception element 122. As described above, the WTRU 102 may have multi-mode capabilities. Accordingly, the transceiver 120 may include multiple transceivers that enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (such as a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may Receive user input 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 data in any suitable memory, such as non-removable memory 130 and / or 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 and store information from memory that is not physically located on the WTRU 102. For example, such memory may be located on a server or a home computer (not shown) .

The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power for other elements in the WTRU 102. The power source 134 may be any suitable device that powers the WTRU 102. For example, the power source 134 may include one or more dry battery packs (such as nickel cadmium (NiCd), nickel zinc (NiZn), nickel hydrogen (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and so on .

The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (eg, longitude and latitude) related to the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or based on information from two or more nearby base stations Received signal timing to determine its location. It should be understood that while maintaining compliance with the embodiments, the WTRU 102 may use any suitable positioning method to obtain location information.

The processor 118 may also be coupled to other peripheral devices 138, where the peripheral devices may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connections. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), universal serial bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth ® 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 event tracking And so on. The peripheral device 138 may include one or more sensors, and the sensors may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor Sensor, temperature sensor, time sensor, geographic location sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity Sensor.

WTRU 102 may include a full-duplex radio device for which some or all signals are received or transmitted (eg, associated with specific sub-frames for UL (eg, for transmission) and downlink (eg, for reception)) It can be parallel and / or simultaneous. A full-duplex radio may include signal processing via hardware (such as a choke) or via a processor (such as a separate processor (not shown) or via processor 118) to reduce and / or substantially eliminate Interference Interference Management Unit. In an embodiment, the WTRU 102 may include a half-duplex radio that transmits and receives some or all signals (eg, associated with specific sub-frames for UL (eg, for transmission) or downlink (eg, for reception).

FIG. 1C is a system diagram showing the RAN 104 and the CN 106 according to the embodiment. As described above, the RAN 104 may use E-UTRA radio technology on the air interface 116 to communicate with the WTRUs 102a, 102b, 102c. The RAN 104 can also communicate with the CN 106.

The RAN 104 may include eNodeBs 160a, 160b, 160c, however it should be understood that while maintaining compliance with embodiments, the RAN 104 may include any number of eNodeBs. Each eNodeB 160a, 160b, 160c may include one or more transceivers on the air interface 116 to communicate with the WTRUs 102a, 102b, 102c. In one embodiment, eNodeB 160a, 160b, 160c may implement MIMO technology. Thus, for example, eNodeB 160a may use multiple antennas to transmit and / or receive wireless signals to and from WTRU 102a.

Each eNodeB 160a, 160b, 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. . As shown in FIG. 1C, the eNodeBs 160a, 160b, and 160c can communicate with each other through an X2 interface.

The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a service gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing elements has been described as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

The MME 162 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the 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, and selecting specific service gateways during the initial connection of the WTRUs 102a, 102b, 102c, and so on. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

The SGW 164 may be connected to each eNodeB 160a, 160b, 160c in the RAN 104 via the S1 interface. SGW 164 can generally route and forward user data packets to / from WTRU 102a, 102b, 102c / user data packets from WTRU 102a, 102b, 102c. SGW 164 may perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging when DL data is available to WTRU 102a, 102b, 102c, and managing and storing the context of WTRU 102a, 102b, 102c and many more.

SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c access to a packet-switched network (such as Internet 110) to facilitate WTRU 102a, 102b, 102c and IP-enabled devices Communication.

CN 106 can facilitate communication with other networks. For example, the CN 106 may provide circuit-switched network (such as PSTN 108) access to the WTRUs 102a, 102b, and 102c to facilitate communication between the WTRUs 102a, 102b, and 102c and traditional landline 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.

Although the WTRU is described as a wireless terminal in FIGS. 1A to 1D, it should be thought that in some typical embodiments, such terminals and communication networks may use (eg, temporarily or permanently) a wired communication interface. .

In a typical embodiment, the other network 112 may be a WLAN.

A WLAN adopting the infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STA) associated with the AP. The AP can access or interface to a decentralized system (DS) or another type of wired / wireless network that carries traffic in and / or out of the BSS. Traffic originating outside the BSS and to the STA can arrive via the AP and be delivered to the STA. Traffic originating from STAs and to destinations outside the BSS can be sent to APs for delivery to their respective destinations. The traffic between the STAs in the BSS can be sent via the AP, for example, the source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as point-to-point traffic. The point-to-point traffic can be sent between the source and destination STAs (eg, directly between them) using direct link setup (DLS). In some typical embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). The WLAN using the independent BSS (IBSS) mode may not have an AP, and STAs (for example, all STAs) within the IBSS or using the IBSS can directly communicate with each other. Here, the IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode.

When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the main channel. The main channel can have a fixed width (for example, a bandwidth of 20 MHz) or a width that can be dynamically set through signaling. The main channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some typical embodiments (eg, in an 802.11 system) carrier sense multiple access (CSMA / CA) with collision avoidance may be implemented. For CSMA / CA, STAs that include APs (such as each STA) can sense the main channel. If a specific STA senses / detects and / or determines that the main channel is busy, then the specific STA may fall back. In a given BSS, a STA (for example, only one station) can transmit at any given time.

High Throughput (HT) STAs can use 40 MHz wide channels for communication (for example, by combining a 20 MHz wide main channel with 20 MHz wide adjacent or non-adjacent channels to form a 40 MHz wide channel).

Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two discrete 80 MHz channels (this combination can be referred to as an 80 + 80 configuration). For the 80 + 80 configuration, after channel encoding, the data can be passed and passed through a segmented parser, which can split 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 80 MHz channels and the data can be transmitted by a transmitting STA. On a receiver of a receiving STA, the above operations for 80 + 80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

802.11af and 802.11ah support sub-1 GHz operation modes. Compared with the channel operating bandwidth and carrier in 802.11n and 802.11ac, the channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to typical embodiments, 802.11ah may support meter type control / machine type communication, such as MTC devices in a macro coverage area. MTC may have certain capabilities, such as limited capabilities including support (eg, support only) certain and / or limited bandwidth. The MTC device may include a battery, and the battery life of the battery is above a critical value (for example, to maintain a long battery life).

WLAN systems that can support multiple channels and channel bandwidth (for example, 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as the primary channel. The bandwidth of the main channel may be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the main channel may be set and / or limited by STAs from all STAs operating in a BSS that supports the minimum bandwidth operation mode. In the 802.11ah example, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes, but for STAs that support (for example, only support 1 MHz mode) (Eg MTC type devices), the main channel can be 1 MHz wide. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the main channel is busy (for example, because the STA (which only supports 1 MHz operating mode) transmits to the AP), then even if most of the frequency bands remain space and available, the entire available frequency band can be considered busy.

In the United States, the available frequency bands available for 802.11ah are from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. According to the country code, the total bandwidth available for 802.11ah is 6 MHz to 26 MHz.

FIG. 1D is a system diagram showing the RAN 113 and the CN 115 according to the embodiment. As described above, the RAN 113 may use NR radio technology on the air interface 116 to communicate with the WTRUs 102a, 102b, 102c. The RAN 113 can also communicate with the CN 115.

RAN 113 may include gNBs 180a, 180b, 180c, but it should be understood that while maintaining compliance with embodiments, RAN 113 may include any number of gNBs. Each gNB 180a, 180b, 180c may include one or more transceivers to communicate with the WTRU 102a, 102b, 102c via the air interface 116. In one embodiment, gNB 180a, 180b, 180c may implement MIMO technology. For example, gNB 180a, 180b may use beamforming to transmit and / or receive signals to and / or from gNB 180a, 180b, 180c. Thus, for example, gNB 180a may use multiple antennas to transmit and / or receive wireless signals to and from WTRU 102a. In an embodiment, the gNB 180a, 180b, 180c may implement a carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In an embodiment, gNB 180a, 180b, 180c may implement a Coordinated Multipoint (CoMP) technology. For example, WTRU 102a may receive cooperative transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

WTRUs 102a, 102b, 102c may use transmissions associated with scalable parameter configuration to communicate with gNB 180a, 180b, 180c. For example, for different transmissions, different cells, and / or different portions of the wireless transmission spectrum, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different. WTRUs 102a, 102b, and 102c may use sub-frames or transmission time intervals (TTIs) with different or scalable lengths (for example, containing different numbers of OFDM symbols and / or continuously changing absolute time lengths) to communicate with gNB 180a, 180b , 180c for communication.

The gNBs 180a, 180b, 180c may be configured to communicate with WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with gNB 180a, 180b, and 180c without access to other RANs (eg, eNodeB 160a, 160b, 160c). In a standalone configuration, WTRUs 102a, 102b, 102c may use one or more of gNB 180a, 180b, 180c as an action anchor. In a standalone configuration, WTRUs 102a, 102b, 102c may use signals in the unlicensed frequency band to communicate with gNB 180a, 180b, 180c. In a non-independent configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while communicating / connecting with another RAN (e.g., eNodeB 160a, 160b, 160c). For example, WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-independent configuration, eNodeB 160a, 160b, 160c can act as an anchor for WTRU 102a, 102b, 102c, and gNB 180a, 180b, 180c can provide additional coverage and / or traffic to serve WTRU 102a, 102b, 102c.

Each gNB 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network interception Cut, implement dual connectivity, implement interworking between NR and E-UTRA, route user plane data to user plane functions (UPF) 184a, 184b, and route control plane information to access and mobility management functions (AMF ) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, and 180c can communicate with each other through the Xn interface.

The CN 115 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possibly a data network (DN) 185a, 185b. Although each of the aforementioned elements is described as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

The AMF 182a, 182b may be connected to one or more of the RAN 113 gNB 180a, 180b, 180c via the N2 interface, and may serve as a control node. For example, AMF 182a, 182b can be responsible for verifying the users of WTRU 102a, 102b, 102c, supporting network truncation (such as processing different PDU conversations with different requirements), selecting specific SMF 183a, 183b, managing registration areas, terminating NAS Messaging and mobile management. AMF 182a, 182b can use network clipping to customize the CN support provided to WTRU 102a, 102b, 102c based on the type of service used by WTRU 102a, 102b, 102c. For example, different network slices can be established for different use cases, such as services that rely on ultra-reliable low-latency (URLLC) access, rely on enhanced large-scale mobile broadband (eMBB) storage Access to services, and / or services for machine type communication (MTC) access, etc. AMF 162 may provide for switching between RAN 113 and other RANs (not shown) using other radio technologies (such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi) Control plane function.

The SMF 183a, 183b can be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. SMF 183a, 183b can also be connected to UPF 184a, 184b in CN 115 via N4 interface. SMF 183a, 183b can select and control UPF 184a, 184b, and can configure traffic routing via UPF 184a, 184b. SMF 183a, 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU conversations, controlling policy enforcement and QoS, and providing notification of downlink information. PDU conversation types can be IP-based, non-IP-based, Ethernet-based, and so on.

UPF 184a, 184b can be connected to one or more of RAN 113 gNB 180a, 180b, 180c via the N3 interface, which can provide a packet switching network for WTRU 102a, 102b, 102c (such as Internet 110) Access to facilitate communication between WTRUs 102a, 102b, 102c and IP-enabled devices, UPF 184, 184b can perform other functions, such as routing and forwarding packets, implementing user plane policies, supporting multi-homed PDU conversations, Handle user plane QoS, buffer downlink packets, and provide mobile anchoring.

CN 115 can facilitate communication with other networks. For example, CN 115 may include or may communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108. In addition, CN 115 may provide 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, and 102c may be connected to the UPF 184a, 184b through the N3 interface and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b, and connected to the UPF 184a, 184b. Local Data Network (DN) 185a, 185b.

In view of Figures 1A to 1D and the corresponding descriptions of Figures 1A to 1D, one or more or all functions described here with reference to one or more of the following may be performed by one or more simulation devices (not shown). ) To perform: WTRU 102a-d, base stations 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 any other device (s) described herein. These simulation devices may be one or more devices configured to simulate one or more or all of the functions herein. For example, these simulated devices can be used to test other devices and / or simulate network and / or WTRU functions.

The simulation device may be designed to perform one or more tests on other devices in a laboratory environment and / or an operator network environment. For example, the one or more emulated devices may perform one or more or all functions while being implemented and / or deployed wholly or partially as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more emulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device to perform the test, and / or may use air wireless communication to perform the test.

The one or more emulation devices may perform one or more functions including all functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device may be used in a test laboratory and / or a test scenario of a wired and / or wireless communication network that is not deployed (eg, tested) to perform testing of one or more components. The one or more simulation devices may be a test device. The simulation device may use direct RF coupling and / or wireless communication via an RF circuit (eg, the circuit may include one or more antennas) to transmit and / or receive data.

Deployment scenarios (for example, in LTE and 5G) may include, for example, indoor hotspots, dense cities, villages, urban macro cells, high speed, and the like. Use cases (for example, in LTE and 5G) may include, for example, enhanced mobile broadband (eMBB), large-scale machine type communication (mMTC), and ultra-reliable and low-latency communication (URLLC). Use cases can focus on different requirements, such as higher data rates, higher spectral efficiency, low power and higher energy efficiency, lower latency, and higher reliability.

Use cases in vehicle scenarios (such as 5G vehicle-to-everything (V2X)) can include vehicle queuing, sensors, and state diagram sharing, remote driving, and / or autonomous cooperative driving. Vehicle queuing can refer to, for example, operating a group of vehicles in a tightly connected manner, for example, the vehicles can move like a train with virtual ropes attached between the vehicles. For example, vehicle distance can be maintained by sharing status information between vehicles. Lineups can reduce the distance between vehicles and / or can reduce the number of drivers required. Queueing can reduce overall fuel consumption.

For example, for high carrier frequencies (for example, above 6 GHz), vehicle jams can cause a reduction in signal strength (for example, a significant reduction). In an example, a vehicle jam can be considered as a separate state, for example, out of sight state and out of sight state.

In an example, one or more transmission modes may be used. The vehicle may be in (eg, V2X) transmission mode 3 (eg, mode 3 user). The vehicle may be in (eg, V2X) transmission mode 4 (eg, mode 4 user). Mode 3 users may, for example, use (eg, directly use) resources (eg, resources allocated by network entities (eg, base stations)), for example, for side links (SL) between vehicles or between vehicles and pedestrians Communication. Mode 4 users may, for example, obtain a list of candidate resources (eg, resources allocated by a network entity (eg, a base station)), and may select resources in the candidate resource list, for example, for SL communication.

The user or WTRU may refer to the vehicle (user). For example, in a vehicle scenario, these terms may be interchangeable herein.

HARQ based on Code Block Group (CBG) can be used. There may be CBG-level CRC. Can support CBG-based transmissions with single / multi-bit HARQ-ACK feedback (for example, in eMBB use cases). CBG-based transmission can be used for downlink transmission and / or uplink transmission.

For example, using one or more of the features described herein can reduce the latency for group communication in a vehicle queue. Group communication can occur within vehicle queues. Vehicles can join or leave the vehicle queue. Notifications or warnings can be disseminated (eg, transmitted, relayed, and / or received) on vehicles in a queue.

For example, in high frequency bands, vehicle jams may reduce signal strength. A vehicle in the queue (for example, due to a vehicle jam) may not have a good communication link with another vehicle in the queue. For example, when the blocking vehicle is large (such as a school bus or truck), a decrease in signal strength (for example, due to a vehicle jam) may be significant. One or more vehicles in the queue (eg, in the middle of the queue) can act as relay vehicles, for example, to maintain group communication in the queue. The relay vehicle may, for example, pass a message (eg, received from a first vehicle) to a second vehicle (eg, a vehicle behind it), or vice versa.

Relay operations may cause additional delays during data transmission. The delay may increase (eg, linearly) with the number of relay vehicles. For example, for queues with a large number of vehicles, the delay caused by relay operations can be significant. For example, via one or more features herein, delays caused by relay operations of vehicle queues can be reduced.

Resources can be selected for V2X users (eg, Mode 4 users). The key performance interface (KPI) may be related to the user's plane latency. End-to-end latency (for example, in NR V2X communication) can be, for example, 3-10 ms. The resource selection for NR V2X communication is disclosed here to support low latency, for example.

Signaling overhead can be reduced in vehicle formation scenarios. Vehicles in a vehicle lineup can move in the same direction, at the same speed (eg, almost the same speed), and / or along the same route (eg, almost the same route) (eg, move approximately). Vehicles can share a common communication environment.

The public environment may be related to switching. In an example, for example, using the same source network entity and destination network entity (eg, gNB), vehicles in a queue can perform a switch at approximately the same time. For example, when each vehicle performs a handover individually, there may be significant signal overhead. Group-based switching can be performed on two or more (eg, all) vehicles in a queue. For example, group-based switching can be configured during the formation period. The formation process can support group-based switching.

Vehicles can move in line at high speeds (for example, up to 250 km / h or 155 mph). The high speed of the vehicle queue may require a switch duration. You can prepare for the switch in advance. In an example, for example, when a vehicle formation may be leaving cell coverage, the first vehicle in the formation may switch earlier than the other vehicles in the formation. Even if one or more other vehicles may not have to be switched at the same time as the first vehicle, the other vehicle may be prepared for switching in advance.

Can provide network coding associated with data transfer. One or more of the following can be applied: channel coding features associated with supporting network coding (e.g., at the transmitting entity); channel decoding features associated with supporting network coding (e.g., at the receiving entity) ); Channel decoding / encoding features related to supporting network coding (e.g., at a relay entity); or messaging related to supporting network coding.

Figure 2 shows an example of data channel coding (for example, Low Density Parity Check (LDPC) coding for NR). In LDPC coding, one or more of the following can be applied. A transport block (TB) can be received from the upper layer. A TB-level CRC can be generated and appended to the TB. A TB segment (eg, a TB segment that includes additional CRC bits) may be divided into several (eg, equal size) code blocks (CB). The CB-level CRC may be appended to one or more (eg, each) CB. For example, based on the CB size (for example, including the CB CRC), the boost size can be determined for a given LDPC base map. Fill bits (eg, if needed) can be inserted (eg, each) into the CB, for example, to match the selected boost size. For example, a CB (eg, with or without padding bits) can be encoded with a given low bit rate LDPC parity check matrix. LDPC-encoded bits can be stored in a circular buffer. For example, based on the redundancy version (RV) and the code rate, one or more bits can be selected from the circular buffer for transmission. For example, the selected bits can be interleaved by a column-row interleaver to compensate for the effects of the attenuation channel. Interleaved bits (for example, from multiple CBs) may be modulated, for example, after these interleaved bits are serialized.

Channel coding characteristics associated with supporting network coding (eg, at the transmitting entity) are exposed. For example, V2X communication can be considered a mesh network. A vehicle or roadside unit (RSU) can multicast a message (for example, the same message) to multiple vehicles nearby.

A group of vehicles can form a vehicle queue. Vehicles in a group or queue can transmit public messages to multiple (for example, all) vehicles in the queue. Vehicles in the front of the lineup may not have a direct connection to the vehicle at the end of the lineup (for example, due to a vehicle jam). Vehicles in the middle of the line can act as relays. In an example, an extended sensor such as an RSU may be used. One or more vehicles may send raw or processed sensor data to the RSU, which RSU may (eg, in turn) multicast the data to one or more nearby vehicles nearby. The paradigm can be presented based on a vehicle queue use case, for example, where vehicles in a queue can act as relay nodes. The paradigm can be extended to or applied to other V2X use cases, for example, where a vehicle and / or RSU can act as a relay node.

In an example, for example, a decoding and forwarding relay scheme can be used because a relay vehicle can receive the same message as another vehicle. Public messages may need to reach the end vehicle within a time threshold, for example to meet latency requirements. In the example, a partial decoding and forwarding relay scheme based on network coding can be used. For example, even when the relay vehicle has not completed decoding the TB, information (for example, partial or complete information) can be forwarded (for example, to one or more other vehicles). For example, compared to decoding and forwarding, this can reduce the latency of message transmission to allow vehicles at the end of the queue to receive messages quickly.

For example, a LDPC encoding system that supports network coding as described herein can be used to implement a partial decoding and forwarding relay scheme. In an example, other channel codes (for example, polar codes or turbo codes) may be used to implement a technique utilizing LDPC encoding.

Figure 3 shows an example of LDPC coding that can include network coding. One or more of the following can be performed.

For example, as shown in FIG. 3, a TB may be received from, for example, an upper layer. A TB-level CRC may be calculated (eg, determined) and / or appended to the TB. CB segmentation can be applied to TB (for example, TB with additional CRC bits). The number C of CB segments can be calculated (eg, determined). A TB may be segmented (eg, equally divided) into C CB segments. The CB-level CRC may or may not be appended to (for example, each) a CB segment.

The calculation of CB segments may vary between LDPC coding system paradigms. In the example (for example, given the same TB size), the number of CB segments in LDPC encoding that supports network coding may be greater than the number of CB segments in LDPC encoding that does not support network coding.

K _cb may be a maximum code block size of the LDPC code, and B may be a TB size (for example, including a TB CRC). LDPC encoding systems (for example, systems that do not support network coding) can, for example, be based on To calculate the number of CB segments, where L can be the CB CRC length. The LDPC encoding system (for example, supporting network coding) can, for example, calculate the number of CB segments based on the following: 1) ; Or 2) ; Or 3) ; Or 4) max (C, A ₅ ) , or any combination of these, wherein A ₁ , A ₂ , A ₃ , A ₄ , A ₅ are integer values.

Network coding can be included in the LDPC coding chain (for example, as shown in Figure 3, as a network coding processor), for example, after the CB segment. Figure 4 shows an example of a network encoding processor (for example, a network encoding processor may refer to a network encoding, such as a network executed by a device (eg, a processor or other organization associated with the device) Coded). For example, one or more of the features shown in Figure 4 may be performed via a network coding processor function (eg, as described herein).

The network coding processor may consider one or more CBs (eg, all CBs) from the segmented TB as a source for network coding processing. The input CB can be stored in a buffer. The degree distribution A can be determined for network coding processing. For example, the degree distribution may depend on the data QoS (eg, the latency of the message, the reliability level of the data), channel conditions, the number of CBs after CB segmentation, and / or the network coded CB (NC -CB). The degree distribution A can be determined dynamically. For example, the degree distribution A can be configured using high-level messaging. The degree distribution A may be predefined.

The degree distribution can be a distribution of random variables (eg, uniform distribution, Gaussian distribution, etc.). A list of degree values may be generated, for example, based on the degree distribution. Each generated degree value can indicate how many CBs can be used to generate the NC-CB. An example could be a total of 10 CBs. A single example of considering the degree distribution A can be a uniform distribution, where the degree random variable A can follow: Pr (A = 1) = 1/10, Pr (A = 2) = 1/10, ..., Pr (A = 10) = 1/10. Another exemplary degree distribution A (for example, non-uniform) can be Pr (A = 1) = 1/2, Pr (A = 3) = 1/4, Pr (A = 5) = 1/8, Pr ( A = 7) = 1/8.

Examples of degree generation can be generated or obtained (for example, under the condition that the degree distribution A has been determined). In one example, the number A may be generated based on the degree distribution A , for example. A CB may be selected (eg, randomly selected) from K source CBs (eg, stored CBs). The selected CB may be XORed, for example to produce an NC-CB. CRC bits can be attached to (eg, each) NC-CB. For example, one or more additional NC CBs can be generated following the same technique (for example, when more NC CBs can be transmitted). Otherwise, the process can stop.

This determination to stop the process may depend on one or more of the following: channel conditions, data QoS, number of CBs after CB segmentation, degree distribution, possible feedback from the receiver, etc. Consider the example of a total of 10 CBs and the degree distribution A may be a uniform distribution (eg, as shown herein). For distribution A , we can produce a list of values, such as 4, 7, 2, 9, 1, 8, 2, 5, 7, 10, 8, 9, 2, 3, 4, 5, 7, 9, 8, 2, , 4, 6, 7, ... Each value can be less than or equal to 10 (for example, 10 CBs); each value can be approximately equally between 1 and 10. The number of values in this list can be a number greater than or equal to 10. In an example (eg, FIG. 5), the number of CBs may be K, and the number of NC-CBs may be N. In the example, N> = K. Each value may correspond to an NC-CB (for example, it may indicate how many CBs are used to generate the NC-CB).

Figure 5 shows an example of data manipulation at a network encoding processor (eg, a network encoding processor of a transmitter). N NC-CBs may be generated from a list of K CBs (eg, from K CBs segmented from TB). As shown in the example in FIG. 5, for each NC CB to be created, a random number of K CBs is selected and an XOR operation is performed on the selected random number of K CBs. The result of the XOR operation (for example, with or without CRC bits) can produce an NC CB. A ₁ may be selected randomly, and as shown in the example in FIG. 5, the value of A ₁ randomly selected is 2 (for example, two CBs out of K CBs are selected to perform an XOR operation). A ₂ may be selected randomly, and as shown in the example of FIG. 5, the value of A ₂ randomly selected is 1 (for example, one of the K CBs is selected). A ₃ may be selected randomly, and as shown in the example in FIG. 5, the value of A ₃ randomly selected is 2 (for example, two CBs out of K CBs are selected to perform an XOR operation).

The CRC bit can be appended one or more times. In the example, the following levels of CRC bits may be appended: CB-level CRC; NC CB-level; or CB-level CRC and NC CB-level.

For example, in the example shown in Figure 3, padding bit insertion can be applied before or after network coding. The padding bit insertion can perform functions similar to or the same as those in FIG. 2, such as padding zeros to CB or NC-CB, for example, to match the support information block length of the LDPC parity check matrix.

Can provide LDPC encoding. Sub-parity check matrices can be provided for LDPC encoding, for example, as shown in the example in Figure 3. For example, when a single transmission on the (eg, each) LDPC codeword of the NC CB is expected, a circular buffer may not be used. The sub-matrix of the LDPC parity check matrix can be selected from the mother LDPC parity check matrix, for example, to match the expected coding rate in the current transmission. Part or all of the LDPC codeword can be transmitted in the current transmission. For example, one or more encoded system bits may not be transmitted to achieve better BLER (Block Error Rate) performance.

The channel interleaving operation may be applied to, for example, each LDPC codeword. For example, modulation may be applied to a sequential channel, which may, for example, interleave bits from multiple NC CBs.

V2X communication can be unauthorized. For example, the transmitter can keep sending data without authorization and does not wait for ACK / NACK feedback from the receiver. For example, a transmitter vehicle may keep transmitting an NC CB to a receiver vehicle (eg, a vehicle behind the transmitter vehicle) unless it receives an ACK from the receiver vehicle.

Can provide channel decoding, for example to support network coding. Figure 6 shows an example of LDPC decoding that can support network coding operations, for example, as described herein. One or more functions shown in Figure 6 may be performed. For example, one or more of the following can be applied.

The receiver can receive data. The receiver can demodulate the symbols and apply a channel deinterleaver. The LDPC-coded NC CB of the channel deinterleaving may be decoded, for example, using LDPC decoding (eg, using a sub-matrix of an LDPC parity check matrix).

Successfully decoded NC CBs can be stored in a buffer. For example, the NC CB level CRC can be used to determine whether the decoding of the NC CB is successful. For example, when the NC CB CRC is not attached, the inherent parity check of the LDPC code can be used to determine whether the NC CB was successfully decoded. For example, the NC CB-level CRC may be removed before the decoded NC CB is stored in a buffer.

For example, when the number of successfully decoded NC CBs in the buffer is greater than the total number of CBs (eg, K CBs), the network decoding process may attempt to decode CBs (eg, all CBs). K CBs can be decoded. For example, if K CBs are decoded and / or when a CB-level CRC is used, a CB-level CRC check may be performed. If a CB-level CRC is not used, a TB-level CRC check can be performed.

Can provide feedback. In an example, for example, when a terabyte-level CRC check passes, a terabyte-level ACK bit may be fed back to the transmitter. For example, when a terabyte-level CRC check fails, the receiver may not (eg, immediately) send a NACK bit to the transmitter. The receiver can wait to receive more NC CBs for the next network decoding attempt. For example, when a timer for receiving data expires, the receiver may send a NACK bit to the transmitter.

Provides channel decoding / encoding that can support network coding (for example, at a relay vehicle). Vehicles in the middle of the queue (for example, different from vehicles at the end of the queue) can act as relay nodes and / or can decode data on their own. Figure 7 shows an example of LDPC decoding / encoding that can support network coding at the relay. One or more of the functions shown in Figure 7 may be performed. For example, one or more of the following can be applied.

The decoding at the relay vehicle may be similar to the decoding of the last vehicle in the queue (see, for example, Figure 6). The relay vehicle can schedule data transmission, which can involve a network coding processor.

The source used for network coding operations may be the decoded NC CB stored in a buffer. The source for network coding operations at the relay vehicle may be the decoded NC CB. This may be different from the transmitter, and the source of the network encoding operation of the transmitter may be CB.

For example, when the number of decoded NC CBs in the buffer may be greater than a critical value, a network encoding operation may begin. The critical value may be less than the total number of CBs (eg, K CBs). For example, because network encoding operations can begin before the relay decodes the CB (for example, all CBs), this can speed up relay data transmission.

Figure 8 shows an example of data manipulation at a relay's network coding processor. The operation may be based on, for example, the decoded NC CB instead of the source CB (eg, as shown in Figure 5).

For example, the NC CB may be zero-padded to match the supported information block length of the LDPC parity check matrix. The LDPC parity check matrix may be a sub-matrix of the parent LDPC parity check matrix. For example, when a single transmission of each NC CB may be applied, a circular buffer may not be used to store LDPC encoded bits. Channel interleaving can be applied to, for example, LDPC coded bits. Modulation can be performed, for example, sequential interleaving bits can be modulated for transmission.

Messaging can support network coding. Messaging may be related to network coding operations in V2X SL.

For example, based on configuration and / or startup, the network coding feature may be a mandatory feature such as V2X SL, or an additional or optional feature. In an example, for example, when a network coding feature is configured and / or activated, the network coding feature may be applied. The network coding feature may be configured, for example, via high-level messaging (eg, RRCConnectionReconfiguration, RRCConnectionEstablishment, etc.). The coding feature can be initiated by the MAC CE, for example.

Network coding characteristics may be associated with WTRU capabilities or WTRU classes. The WTRU class may include network coding capabilities, while another WTRU class may not include network coding capabilities.

The degree distribution A can be configured, for example, by high-level messaging (eg, RRCConnectionReconfiguration, RRCConnectionEstablishment, etc.). The degree distribution A may be activated, for example, by MAC CE and / or physical layer signaling (eg, SCI, DCI, UCI).

Can provide network coding configuration. An NC CB (eg, each NC CB) can be an XOR of several CBs. The component CB information may be included in the control information, for example, to allow the network decoding processor to use this information to decode the CB from the NC CB. Network coding configurations can be included in L1 control messaging, such as SCI, DCI, UCI, for example. The configuration of the NC CB may be a list or bitmap of component CBs. For example, when more than one NC CB can be transmitted, the configuration of multiple NC CBs can be multiplexed.

The relay can have its own network coding configuration, which can be signaled in the SCI associated with the metadata.

Can provide messaging for SL CBG-based data transmission. One or more of the following can be applied.

LTE SL Control Information (SCI) can include multiple formats, such as SCI Format 0 and SCI Format 1. SCI format 0 may be used (for example, mainly) for transmission modes 1 and 2; SCI format 1 may be used (for example, mainly) for transmission modes 3 and 4. SCI format 1 may include, for example: 1) priority order; 2) resource reservation; 3) frequency resource location; 4) time gap; 5) modulation and coding scheme; 6) retransmission index; and / or 7) reserved bit yuan.

There may be a bit on the retransmission index. For example, more retransmissions can be implemented to support V2X reliable data transmission. The field of the retransmission index may be increased, for example, from 1 bit to 2 bits or more. The maximum number of redundant versions (RV) may be, for example, four. Retransmission indexes (eg, each retransmission index) may be associated with the RV ID. It can support CC and IR HARQ. For example, an RV ID can be used to indicate a CC or IR type HARQ.

CBG-based transmission can be supported in NR eMBB use cases. For example, CBG-based transmission can be used in V2X to reduce the number of data retransmissions. The SCI may include CBG information, for example to support CBG-based transmission. For example, the SCI may include a bitmap that shows which CBGs are included in the current (re) transmission. The bitmap length can be the configured maximum supported CBG number (for example, C ). The feedback may include C bits, and each bit may indicate whether the CBG was successfully decoded.

Can optimize CBG messaging. In an example, the bitmap length may be the smallest of the configured maximum number of supported CBGs and the number of CBs. The feedback may include bits for (eg, only for) the transmitted CBG. A TB-level ACK / NACK bit may be included, for example, it is added on top of a CBG-level ACK / NACK.

Resources can be allocated to consumers (for example, Mode 4 consumers). Resource allocation may include determining a resource selection window or RV selection one or more times based on the selected resource. Resources may refer to time domain sub-frames (or time slots) and / or frequency domain sub-carriers (or resource blocks or sub-channels).

The resource selection window can be determined. One or more of the following can be applied.

A packet targeted for a user (for example, a mode 4 user, such as a mode 4 user in V2X) may reach the MAC Tx buffer for transmission at the sub-frame n . The candidate resource set may be selected , for example, within a time interval (eg, [ n + T ₁ , n + T ₂ ]. The minimum value of T ₂ may be, for example, 20 ms (eg, in LTE). This can guarantee that a maximum of 20 can be supported ms latency. End-to-end latency (for example, in LTE) can be 100 ms, which can allow use of T _{2 of} up to 20 ms.

The latency requirements of NR V2X may be 3-10 ms. For example, the value of T ₂ (or the minimum value of T ₂ ) can be reduced to support more challenging use cases. This ensures that the duration between the arrival of the packet in the MAC Tx buffer and the transmission of the packet can be reduced. For example, when the same number of WTRU may select a candidate set of resources in a smaller set of candidate pool resources, reduce the value of T (T or a minimum value of _{2) 2} may increase the likelihood of resource conflicts.

In the example, different T ₂ values (or minimum values of T ₂ ) can be applied on different frequency bands. Operating frequency bands (eg, in NR V2X) can be classified, for example, below 6 GHz and above 6 GHz. Bands below 6 GHz can be shared with LTE V2X, while bands above 6 GHz can be used (for example, only) for NR. NR V2X use cases may include more latency-sensitive use cases, which may be assigned to frequency bands above 6 GHz. For example, by limiting the time window to select a candidate resource set to a smaller value, the latency requirements of the use case can be achieved. In one example, the user plane latent time may be, for example, 3-10 ms for direct communication via SL, and may be 2 ms for packets that may be relayed via BS, for example.

For example, when a WTRU can operate in a frequency band higher than 6 GHz and a frequency band lower than 6 GHz, resource selection can be performed on multiple frequency bands. The resource selection time window upper limit T ₂ (or the minimum value of T ₂ ) can be smaller in a frequency band above 6 GHz and larger in a frequency band below 6 GHz. For example, when the selected resource in the frequency band below 6 GHz meets the latency requirement, the selected resource in the frequency band below 6 GHz can be used. Otherwise, the selected resources in the frequency band below 6 GHz can be ignored.

Figure 9 shows examples of resource selection windows for different frequency bands.

In the example, different T ₂ values (or T ₂ minimum values) can be applied on different parameter configurations. For example, in terms of subcarrier spacing, there may be different parameter configuration options (for example, in NR). In one example, there may be sub-carrier spacing options of 15 KHz, 30 KHz, 60 KHz, 120 KHz, and 240 KHz.

For smaller subcarrier spacings, the symbol duration may be larger. There may be fewer OFDM symbols in a given time slot. This may mean that there may be fewer time domain resources to choose from. The value of T ₂ (or the minimum value of T ₂ ) may be larger, for example, to enable a larger number of possible time resources and / or to achieve low resource conflicts.

For larger subcarrier spacings, the symbol duration may be smaller. There may be more OFDM symbols in a given time slot. This may mean that there may be more time domain resources to choose from. The value of T ₂ (or the minimum value of T ₂ ) may be smaller, for example, to maintain the same number of candidate resources.

FIG. 10 shows an example of a resource selection window for different subcarrier spacing parameter configurations.

For example, different values of T ₂ (or the minimum value of T ₂ ) can be applied, depending on the density of vehicles in the area. For example, vehicle density may be estimated depending on vehicle speed and / or vehicle environment (eg, a highway or local street). High vehicle density environments may have more potential resource competitors. The value of T ₂ (or the minimum value of T ₂ ) can be large, for example to avoid resource conflicts. Low vehicle density environments may have fewer potential resource competitors. The value of T ₂ (or the minimum value of T ₂ ) can be small, for example to ensure low latency requirements.

For example, in terms of vehicle density, multiple (eg, two or more) states can be defined. For example, when the probability of collision is low (for example, in a low vehicle density state), the value of T ₂ may be smaller. For example, in a low vehicle density state, the value of T ₂ (or the minimum value of T ₂ ) may be larger, for example, to avoid conflicts with selected resources of other vehicles.

FIG. 11 shows an example of a vehicle density state diagram. State transitions may depend on, for example, vehicle speed and / or road conditions. In an example, as shown in FIG. 11, a decrease in vehicle speed, and / or a decrease in speed limitation from the current state may trigger the use of a higher density state (eg, higher than the current state). In an example, as shown in FIG. 11, an increase in vehicle speed and / or an increase in speed limit from a current state may trigger the use of a lower density state (eg, lower than the current state).

For example, depending on the type of data traffic, different values of T ₂ (or the minimum value of T ₂ ) can be applied. In an example, when one type of data (eg, one type of data is expected) does not have strict low-latency requirements (eg, periodic data types), the value of T ₂ may be large. In the example, when one type of data (for example, one type of data expected) may require urgent delivery (for example, data type data type or non-periodic event-triggered), T ₂ value of the minimum (or T ₂ of ) Can be small. The QoS requirements of the profile may be associated with the choice of T ₂ (or the minimum of T ₂ ) (eg, alone or in combination with other factors described herein).

The RV may be selected based on the selected resource or resources. One or more of the following can be applied.

Data transmission and retransmission can occur in selected resources. For example, a different selection window T ₂ (or the minimum value of T ₂ ) can be used in the resource selection. Data transmission can be associated with the selection window T ₂ (or the minimum value of T ₂ ).

For small T ₂ (or a small minimum of T ₂ ) (for example, 2 ms), the chance of resource conflicts may be high. The transmission may (for example in this case) not be combined with other transmissions for better decoding performance. The selected RV for this (re) transmission may be a self-decodeable RV (such as RV0 or RV3).

For large T ₂ (or a large minimum of T ₂ ) (for example, 20 ms), the chance of a resource conflict may be low. Transmissions can (for example in this case) be combined with other transmissions for better decoding performance. The selected RV for this (re) transmission may not require self-decodeable capabilities (for example, all RVs can be applied). In an example, for example, when T ₂ > Thre (eg, T _{2 is} less than the critical value) or the minimum value of T ₂ > Thre (eg, the minimum value of T ₂ is less than the critical value), the RV selection may be only at RV0 and RV3 Between. For example, when T ₂ > Thre (for example, T _{2 is} larger than the critical value) or T ₂ minimum value> Thre (for example, the minimum value of T ₂ is larger than the critical value), the RV selection can be between RV0, RV1, RV2 and RV3. Between.

Group-based switching can be provided in a vehicle queue, such as a V2X use case, where a group of vehicles can operate in a tightly coupled manner, such as a train with virtual ropes between vehicles. For example, by sharing status information, the distance between vehicles can be maintained (eg, and / or minimized).

For example, when a group of vehicles travels in the same direction at a small distance between vehicles, switching between the groups of vehicles can be simplified. Can simplify Uu interface. Vehicles in a queue can perform a switch between two cells, which can mean that other vehicles in a queue can perform a similar switch between two cells.

Figure 12 illustrates an example of handover in which one or more of the features shown can be performed. The WTRU may transmit a measurement report to the serving (or source) eNB, which may decide to switch the WTRU to a neighbor (or target) eNB. Preparation for handover between the source eNB and the target eNB may be performed, for example, via an S1 interface or an X2 interface. The target eNB may, for example, establish resources for the WTRU at the end of the handover preparation. The source eNB may transmit a handover command to the WTRU, for example, via an RRCConnectionReconfiguration message. The source eNB may transmit a state transfer message to the target eNB. The WTRU may use the received RACH configuration to mimic (eg, perform) a random access procedure to the target eNB. The WTRU may transmit an RRCConnectionReconfigurationComplete message to the target eNB (eg, when the random access procedure is successfully completed).

For example, handovers can be simplified when multiple WTRUs are in the same queued vehicle group.

FIG. 13 illustrates an example of a switching procedure, such as in a queue scenario, in which one or more of the features shown can be performed. WTRU2 can join the queue. WTRU2 may, for example, register handover coordination with a line of lead vehicles. Information can be exchanged in a queue, for example via a PC5 link or via an RSU. The content of the message (eg, in the PC5 link) may include, for example, one or more of the following: (i) WTRU ID; (ii) WTRU vehicle information; (iii) WTRU network information; (iv) WTRU handover Coordination; or (v) WTRU's ability / willingness to become a team leader vehicle.

The team leader vehicle may pass handover coordination information to the gNB, for example, via a Uu interface. For example, when a queued member (eg, a member vehicle) chooses a handover coordination, the member may not need to report their measurements to the gNB for a handover. This reduces measurement reports. The queue leader vehicle may send its own measurement report to the gNB, which may represent one or more (eg, all) measurement conditions for the queue.

The member vehicle may send its measurement report to the queue leader vehicle, for example, at a lesser opportunity. For example, when a queue leader vehicle receives a measurement report from another member vehicle in the queue, the vehicle queue leader may send the measurement report from one or more (eg, all) members of the queue to the gNB. The vehicle queue leader may (eg, optionally) process measurement reports (eg, take an average of the measurement reports) from multiple (eg, all) members of the queue before sending to gNB. Group-based measurement reports can be sent to gNB for handover.

The source gNB may decide to switch the queue to the target gNB. The source gNB may send a group-based handover command (eg, via an RRCConnectionReconfiguration message) to the line leader vehicle (eg, after handover preparation). The handover command may include, for example, one or more of the following: a new C-RNTI, a target gNB security algorithm ID, a dedicated RACH preamble, a target eNB SIB, and the like. The dedicated RACH preamble may be, for example, based on each queue, or may be based on each member vehicle.

The team leader vehicle can transmit RRCConnectionReconfiguration messages to the member vehicles in the team. Formation vehicles (for example, each composition vehicle) can execute independent random storage procedures. For example, when the random access procedure is non-contention based (for example, with a dedicated RACH preamble), member vehicles in the queue (for example, each member vehicle) may use a different preamble to access the target gNB.

The team member vehicle may (eg, at the end of the random access procedure) (eg, via an RRCConfigurationComplete message) send a handover completion message to the team leader vehicle, for example. For example, when a member vehicle (eg, all member vehicles) in a queue completes a handover, the team leader vehicle may send a group-based handover completion message to the target gNB. For example, when less than all the vehicle members in the queue complete the handover, the team leader vehicle may send a group-based handover completion message indicating which member WTRUs have completed the handover. The remaining WTRUs can start another (eg, traditional) handover procedure.

Features, elements, and actions (eg, processes and tools) are described via non-limiting examples. Each feature, element, action, or other aspect of the described subject matter, whether presented in the illustration or in the description, may be implemented individually or in any combination, including in any order with other themes (whether known (Unknown)), regardless of the paradigm presented here. Although examples can target LTE, LTE-A, new radio (NR), or 5G protocols, the subject matter of this article applies to other wireless communications, systems, services, and protocols.

The WTRU may refer to an identification code of a physical device, or a user identification code such as a subscription-related identification code, such as MSISDN, SIP URI, and the like. The WTRU may refer to an application-based identification code, such as a username that can be used by each application.

The above processing may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or 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, but not limited to, Internal hard drives and removable magnetic disks), magneto-optical media and / or optical media (such as CD-ROM discs and / or digital versatile discs (DVDs)). The software-associated processor can be used to implement radio frequency transceivers for WTRUs, terminals, base stations, RNCs, and / or any host computer.

100‧‧‧communication system

102, 102a, 102b, 102c, 102d ‧‧‧ Wireless Transmit / Receive Unit (WTRU)

104, 113‧‧‧ Radio Access Network (RAN)

106, 115‧‧‧ Core Network (CN)

108‧‧‧ Public Switched Telephone Network (PSTN)

110‧‧‧Internet

112‧‧‧Other networks

114a, 114b‧‧‧ base station

116‧‧‧ air interface

118‧‧‧Processor

120‧‧‧ Transceiver

122‧‧‧Transmit / Receive Element

124‧‧‧Speaker / Microphone

126‧‧‧Keyboard

128‧‧‧Display / Touchpad

130‧‧‧non-removable memory

132‧‧‧ Removable memory

134‧‧‧Power

136‧‧‧Global Positioning System (GPS) Chipset

138‧‧‧Peripheral equipment

160a, 160b, 160c‧‧‧e Node B

162‧‧‧Mobile Management Entity (MME)

164‧‧‧Service Gateway

166‧‧‧Packet Data Network (PDN) Gateway

180a, 180b, 180c‧‧‧gNB

182a, 182b‧‧‧ Mobile Management Function (AMF)

183a, 183b‧‧‧ Dialogue Management Function (SMF)

184a, 184b ‧‧‧ User Plane Function (UPF)

185a, 185b‧‧‧ Data Network (DN)

CB‧‧‧Code Block

LDPC‧‧‧Low-density parity check

NC-CB‧‧‧Network Coded CB

TB‧‧‧Transfer Block

XOR‧‧‧ XOR

FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented.

FIG. 1B is a system diagram illustrating an exemplary wireless transmission / reception unit (WTRU) that can be used within the communication system shown in FIG. 1A according to an embodiment.

FIG. 1C is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used in the communication system shown in FIG. 1A according to an embodiment.

FIG. 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that can be used in the communication system illustrated in FIG. 1A according to an embodiment.

FIG. 2 shows an example of a data channel encoding (for example, a low-density parity check (LDPC) encoding system) in, for example, NR.

Figure 3 shows an example of LDPC coding that can support network coding.

Figure 4 shows an example of a network coding processor.

Figure 5 shows an example of data manipulation at a network coding processor.

Fig. 6 shows an example of an LDPC decoding system that can support network coding.

FIG. 7 shows an example of an LDPC decoding / encoding system that can support network coding at a relay, for example.

Figure 8 shows an example of data manipulation at a relay's network coding processor.

Figure 9 shows examples of resource selection windows for different frequency bands.

FIG. 10 shows an example of a resource selection window for different subcarrier spacing parameter configurations.

FIG. 11 shows an example of a vehicle density state diagram.

Fig. 12 shows an example of a switching procedure.

FIG. 13 shows an example of a switching procedure in a vehicle formation.

Claims (15)

A wireless transmit / receive unit (WTRU) including: A memory; and A processor configured to: Append multiple CRC bits to a transport block (TB); Performing a segmentation on the TB with the attached CRC bits, where the segmentation creates multiple code blocks (CB); Network coding is applied to the plurality of CBs, wherein the network coding of the plurality of CBs generates a plurality of network coded CBs (NC-CB), and wherein the network coding includes the processor being configured to : Selecting a random number of CBs from the plurality of CBs, and Perform an XOR operation on the random number of CBs, and append multiple CRC bits to a result of the XOR operation; Applying LDPC coding to the plurality of NC-CBs, wherein an LDPC code is a sub-matrix based on a parity check matrix; and Send a transmission. The WTRU according to item 1 of the patent application scope, wherein the processor is further configured to apply a channel interleaver and a modulation to the LDPC-coded NC-CB. The WTRU as described in claim 1, wherein the network coding is performed a number of times greater than a number of the plurality of CBs. The WTRU according to item 3 of the patent application scope, wherein a number of the plurality of NC-CBs is greater than the number of the plurality of CBs. The WTRU as described in claim 1, wherein a number of CBs created by the segment is greater than a number of CBs generated for a same transport block size in a conventional coding system. The WTRU as described in claim 1, wherein the processor is further configured to append respective CRC bits to respective CBs. The WTRU as described in item 1 of the patent application scope, wherein the sub-matrix is selected to match a coding rate associated with a current transmission. The WTRU as described in item 1 of the patent application scope, wherein the following are transmitted with a network coded data: A network coding feature is activated; A one-time distribution for the random number of CBs; and A network coded configuration. A method associated with wireless communication, the method comprising: Append multiple CRC bits to a transport block (TB); Performing a segmentation on the TB with the additional CRC bits, where the segmentation creates multiple code blocks (CB); Applying network coding to the plurality of CBs, wherein the network coding of the plurality of CBs generates a plurality of network coded CBs (NC-CB), and wherein the network coding includes: Selecting a random number of CBs from the plurality of CBs, and Perform an XOR operation on the random number of CBs, and append multiple CRC bits to a result of the XOR operation; Applying LDPC coding to the plurality of NC-CBs, wherein an LDPC code is a sub-matrix based on a parity check matrix; and Send a transmission. The method described in item 9 of the patent application scope further includes applying a channel interleaver and a modulation to the NC-CB of the LDPC code. The method according to item 9 of the scope of patent application, wherein the network coding is performed a number of times greater than a number of the plurality of CBs. The method according to item 11 of the application, wherein a number of the plurality of NC-CBs is greater than a number of the plurality of CBs. The method according to item 9 of the scope of patent application, wherein a number of CBs created by the segment is larger than a number of CBs generated for a same transport block size in a conventional coding system. The method as described in claim 9 of the patent application scope further includes appending respective CRC bits to respective CBs. The method of claim 9 in which the sub-matrix is selected to match a coding rate associated with a current transmission.