EP3874648A1

EP3874648A1 - Hybrid automatic repeat request (harq) enhancements to support unicast and groupcast communication over sidelink for new radio (nr) vehicle to everything (v2x)

Info

Publication number: EP3874648A1
Application number: EP19878625.3A
Authority: EP
Inventors: Ansab ALI; Kyeongin Jeong; Sangeetha L. Bangolae; Alexey Khoryaev; Sergey PANTELEEV; Youn Hyoung Heo
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-11-01
Filing date: 2019-10-31
Publication date: 2021-09-08
Also published as: CN113330702A; WO2020092831A1; CN118677574A; EP3874648A4

Abstract

A device of a New Radio (NR) User Equipment (UE), a method and a machine readable medium. The method includes: encoding for transmission a packet in a cellular vehicle to everything (V2X) network, the transmission including one of a unicast transmission to a single vehicular user equipment (V-UE), or a groupcast transmission to a plurality of V-UEs; decoding a Hybrid Automatic Repeat Request (HARQ)-based message from at least one of the UEs, the HARQ-based message based on a HARQ configuration for the UE and being in response to the packet; and in response to a determination, based on the HARQ-based message, that a HARQ retransmission of the packet is to be encoded, encoding for transmission the HARQ retransmission.

Description

HYBRID AUTOMATIC REPEAT REQUEST (HARQ) ENHANCEMENTS TO SUPPORT UNICAST AND GROUPCAST COMMUNICATION OVER SIDELINK FOR NEW RADIO (NR) VEHICLE TO

EVERYTHING (V2X)

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of and priority from U.S. Provisional Patent Application No. 62/754,517 entitled " HYBRID AUTOMATIC REPEAT REQUEST (HARQ) EN HANCEMENTS TO SUPPORT UN ICAST AND GROUPCAST COMM UN ICATION OVER SIDELINK FOR NEW RADIO (N R) VEHICLE TO EVERYTHING (V2X)/' filed November 1, 2018, the entire disclosure of which is incorporated herein by reference.

FIELD

[0002] Various embodiments generally relate to the field of cellular communications, and particularly to communication within a cellular vehicle to everything (C-V2X) network.

BACKGROUN D

[0003] Current Third Generation Partnership Project (3GPP) New Radio (NR) specifications (or 5G specifications) do not address issues related to mechanisms to support nearly lossless data transfer, especially in the context of vehicle to everything (V2X) use cases.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Fig. 1 illustrates an example of a cellular vehicle to everything (C-V2X) network;

[0005] Fig. 2 illustrates an embodiment of a process according to an embodiment;

[0006] Fig. 3 illustrates an architecture of a system of a cellular network according to some embodiments; and

[0007] Fig. 4 illustrates example components of baseband circuitry and radio front end modules (RFEM) in accordance with various embodiments.

DETAILED DESCRIPTION

[0008] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well- known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrase "A or B" means (A), (B), or (A and B). An architecture includes, but is not limited to, a network topology. Examples of an architecture include, but is not limited to, a network, a network topology, and a system. Examples of a network include, but is not limited to, a time sensitive network (TSN), a core network (CN), any other suitable network known in the field of wireless communications, or any combination thereof.

[0009] One or more embodiments described herein are related to one or more third generation partnership project (3GPP) specifications. Examples of these specifications include, but are not limited to, one or more 3GPP new radio (NR) specifications and one or more specifications directed and/or related to fifth generation (5G) mobile

networks/systems.

[0010] As the use of NR becomes prevalent and widespread and new use cases of advanced vehicle to vehicle (V2V) communication are identified, there is a need to support mechanisms for NR based systems to meet the associated requirements for these use cases. The advanced vehicle to everything V2X use cases have a requirement of high reliability (99.99%) as well as low latency. Hence we need mechanisms to support nearly lossless data transfer at lower layers.

[0011] Hybrid automatic repeat request (HARQ) Feedback is supported in NR and long term evolution (LTE) and needs to be adapted to sidelink communication between vehicular UEs (V2X).

[0012] Referring first to Fig. 1, an example of a cellular V2X network 100 is shown. The combination of V2V, vehicle to pedestrian (V2P), vehicle to infrastructure (V2I) and vehicle to network (V2N) is known as V2X. C-V2X is short form of Cellular to Everything which covers V2V,V2P,V2I and V2N. C2X fulfills the vision to create autonomous vehicle and safer autonomous driving. As seen in Fig. 1, V2X network 100 includes a number of V-UEs, which may includes vehicles 102, 104 and 106. The infrastructure elements include traffic light 108 and relay 110. Base station 112 within the network may further include a Node B, such as a NR evolved Node B (gNodeB). The infrastructure elements of network 100, along with base station 112, may be connected to a application server 116 for traffic management. V-UEs 102, 104 and 106 may be in communication with one another by way of V2V wireless connections, to infrastructure elements 108 and 110 by way of V2I connections, to the cellular network such as to base station 112 or relay 110 by way of V2N connections, and to pedestrian (such as through a mobile device of a pedestrian) 114 by way of V2P connections.

[0013] Embodiments described herein are directed to providing HARQ feedback support enhancements for unicast/groupcast communication between V-UEs, such as V-UEs 102, 104 and 106 of Fig. 1.

[0014] The ideas and solutions set forth in the embodiments described herein could be adopted in the 3GPP V2X standards. With 5G gaining momentum, V2X advanced use cases gaining traction, and in view of the growing focus of 5G in self-driven and autonomous driving use cases, the ideas and solutions set forth in the embodiments described herein could be applicable for enablement of efficient unicast and groupcast communication between remote-driven and autonomous vehicles in the near future.

[0015] As the 3GPP V2X standards evolve to incorporate advanced V2X use cases that go beyond road safety applications, there is a need to develop mechanisms that enable vehicular UEs in communication range of each other to offer functionalities that are able to effectively fulfill requirements such use cases. While these use cases are functionally quite diverse, one aspect that seems common among them is the need for one-to-one and one-to-many communication between different UEs. For instance, if we consider vehicular platooning, the basic idea is that a group of vehicles, either of the same type or of different types (e.g. semi truck, passenger cars, etc.), are grouped together in a platoon such that they are able to move in a coordinated fashion, being aware of each other's status as well as their

surroundings. This requires the platoon leader to be able to effectively communicate with individual Vehicular UEs (V-UEs) to manage the platoon.

[0016] The long term evolution (LTE) based V2X design over sidelink inherently was based on broadcast, i.e. all packets sent by V-UEs over sidelink (such as PC5) were sent blindly, i.e. with no particular receiver in mind. Specifically, the destination field identifier (ID) in the medium access control (MAC) subheader that usually indicates the destination ID for the intended V- UE was simply mapped to the V2X service ID, e.g., Provider Service Identifier (PSID) or Intelligent Transport Systems Application Identifier (ITS-AID) for the V2X application running at the transmit UE. Consequently, there is no way, or indeed no need, for the transmitting UE to know about the UE that received the packet. Additionally, there is no feedback mechanism in place at the receiving UE to inform the transmitting UE that the receiving UE received the packet. So, there is a need to solve this issue in order to meet the unicast/groupcast requirement for advanced V2X use cases.

[0017] HARQ is a process that ensures delivery between peer entities at Layer 1. In NR, for access (Uu) link, asynchronous incremental Hybrid ARQ is supported. For LTE V2X broadcast model, HARQ was not agreed upon. Without any acknowledgement/negative

acknowledgement (A/N) feedback, it is inefficient to transmit data protocol data units (PDUs) to a large group of V-UEs using a low modulation and coding scheme (MCS) to meet the requirement of the V-UE in worst channel condition. The V-UEs in good channel conditions would repeatedly receive the same data when a constant number of retransmissions is employed and this would lead to lot of resource wastage.

[0018] In NR V2X, unicast and groupcast types of communication are being supported to enable advanced use cases, such as platooning, sensor information sharing, and advanced driving. The reliability requirement for these use cases ranges from about 99.000% to 99.999%. Along with tight latency requirement, these use cases demand a closed loop feedback mechanism at lower layers to be supported. A HARQ retransmission mechanism may be used to adapt an modulation and coding scheme (MCS) for V2X unicast/groupcast communication in order to meet the stringent reliability requirements.

[0019] Support of HARQ Feedback/retransmissions for V2X Unicast/Groupcast

communication

[0020] Unicast communication is a connection-oriented or connectionless link established between two V2X UEs (e.g., XQ01, XR101, XR201, etc.) in RRCJDLE or RRCJN ACTIVE or RRC_CONNECTED mode. Groupcast communication is a special form of unicast in which the link is established between one transmitting UE (e.g., XQ01, XR101, XR201, etc.) and several receiving UEs (e.g., XQ01, XR101, XR201, etc.), and the transmitting UE may have information about the receiving UEs.

[0021] For NR sidelink, asynchronous HARQ similar to access link (Uu) can be considered. Essentially, the MAC entity has a HARQ entity for sidelink that can maintain a set of HARQ processes. These processes can be used in any order for transmissions and since the peer UE does not know anything regarding the HARQ process information, the process and redundancy version etc. can be carried via sidelink control information (SCI). Alternatively, during the connection establishment procedure for unicast, this information can be exchanged. In any case, the TX and RX UE for the link should have knowledge of the HARQ process and Redundancy Versions (RVs) for proper operation.

[0022] For unicast V-UEs, the HARQ retransmissions can be done by relying on a dedicated sidelink control channel for feedback. The RX UE can then use a particular message for indicating if it did or did not receive the original packet, i.e., ACK or NACK based operation. While many different options are possible, i.e., ACK based only, NACK based only or some combination of the both, using NACK only based operation can result in reduced signaling overhead (assuming errors are few and far between). If the U E sends a NACK indicating they did not successfully receive a packet, the TX UE can retransmit the packet, in which case, the side control information (SCI) will indicate if the subsequent transmission is indeed a retransmission using the new data indication (N DI) field (similar to NR Uu case).

[0023] For groupcast, the situation is a bit more complex since it is possible to include in the group a set of up to 20 UEs that are involved in group communication. Focusing on the platooning use case, since it is expected to be one of the advanced V2X use cases with widespread deployment, it can be assumed that one UE (termed as the platoon leader) can assume the role of mediating communication within the group. Hence, from a HARQ operational point of view, the platoon leader would benefit from mechanisms to decide when to start/stop the HARQ retransmissions. This can be accomplished in a number of different ways as will be described below.

[0024] According to a first embodiment of a mechanism to decide when to start/stop the HARQ retransmissions, the platoon leader V-UE may be configured to expect an expected number of aggregated received ACKs or NACKs up to a maximum number of V-UEs.

Essentially, the platoon leader V-UE can be configured with a certain maximum number of ACKs or NACKs after which it may safely assume that the original transmission has been successfully received by most/all UEs within the group.

[0025] According to a second embodiment of a mechanism to decide when to start/stop the HARQ retransmissions, a timer may be defined at the platoon leader UE, which can be configured such that the expiry of this timer indicates that there is no need for further retransmissions. The criteria for the timer value itself can be set up based on quality of service (QoS) requirements such as latency, since delay critical V2X packets may not need to be retransmitted after a certain amount of time has elapsed. For this option, the proper configuration of the timer is essential and depends on the V2X application requirements. As a special case, the timer may be used in other ways if an ACK-only transmission mode is enabled. This timer may countdown after transmission of a transport block (TB) for a HARQ process and may expire if no ACK is received. After the expiration, the HARQ process may be considered to trigger NACK, i.e., to trigger retransmission.

[0026] According to a third embodiment of a mechanism to decide when to start/stop the HARQ retransmissions, the platoon leader V-UE may also combine the information from the received ACKs/NACKs with the QoS requirements for each transmission to determine a specific number of retransmissions to be performed. It is expected that the QoS requirements for each V2X packet can be different in general, which translates to a different number of retransmissions required for each packet. This requires a mapping configured at the access stratum (AS) layer between the QoS and/or QoS flow identifier (QFI) for each packet on the one hand, and the maximum number of retransmissions for the packet. Of course, if the platoon leader receives a certain number of ACKs corresponding to a packet before reaching the maximum number of retransmissions, there is no need to further perform them.

[0027] According to a fourth embodiment of a mechanism to decide when to start/stop the HARQ retransmissions, a NACK based feedback mechanism may be used, where the platoon leader may further use the received NACKs and perform energy detection, whereby the total energy of the received NACK messages is compared against a configured threshold to determine if there is a need to perform further retransmissions. This fourth embodiment relies on layer 1 (LI) detection and may lead to potentially faster retransmissions and reduced latency.

[0028] According to a fifth embodiment of a mechanism to decide when to start/stop the HARQ retransmissions, in a variation of the fourth embodiment, the NACK feedback messages can be sent by the UEs in a randomized fashion, i.e., if a dedicated physical channel is used for HARQ feedback, the transmissions can be scattered in time/frequency, which allows a cleaner picture at the platoon leader to determine the overall status of how many UEs received the transmission successfully. Whenever a receiver in the group sends a ACK/NACK, it can either use a resource already allocated for HARQ purpose or a grant-free resource, and based on the QoS requirement for delay, choose a random number in the time and/or frequency domain to send the NACK so as to not collide with other feedback messages being transmitted by other UEs. The receiver may further exploit a sensing and resource selection procedure to determine a resource for ACK/NACK procedure. The platoon leader, in combining such NACK messages, may then determine if a retransmission is required. This fifth embodiment has the drawback of increased resource usage and latency as the receiving (RX) V-UEs spread out their feedback messages across a wider set of resources. To combat this, each RX V-UE may be configured with a specific timer within which it needs to be sending the feedback for it to be useful.

[0029] In all the above cases, the feedback information could implicitly provide channel quality information to increase or decrease transmitter power and adapt MCS accordingly.

[0030] According to one embodiment, ACK/NACK signaling may also include an identifier (ID) that identifies a source of an ACK/NACK message (e.g. particular UE or member of the group) or the group itself w/o identifying a specific member of the group. The resource for the ACK/NACK feedback can be reserved by the original source (e.g., a UE , etc.) of the data for which the ACK/NACK feedback is sough, for example as indicated to receivers/sources of the ACK/NACK messages, by Physical Sidelink Control Channel (PSCCH) and/or Physical Sidelink Shared Channel (PSSCH) transmissions. In addition, group members may be configured to send ACK/NACK messages only when a sidelink (SL) Reference Signal Received Power (RSRP) value between an original source of the data and a group member is below a certain thresholds. Group members that have successfully received a PSSCH transmission are expected to monitor ACK/NACK signaling from group members and, in case if NACK is detected, may retransmit the message jointly with the original source in order to increase a reliability of reception. The retransmission may happen at the same resource in using a system frame number (SFN). A UEs may further be configured with a condition when they are expected to send ACK and NACK, such as being expected to send only NACK or only ACK or both.

[0031] When is HARQ applied for groupcast:

[0032] Even if HARQ retransmissions are supported for NR V2X groupcast, HARQ

retransmissions may, according to an embodiment, be configurable and up to the transmitter V-UE to determine based on some information e.g. number of V-UEs in the group as made available by the core network (e.g AMF), channel conditions and whether dedicated resources have been configured for use (leading to less probability of collisions with other transmissions) as well as the QoS requirements (since some applications may not require high reliability to warrant the need for HARQ feedback). Such factors can be considered using (pre-)configuration based on application requirements by the upper layers.

[0033] In particular, for QoS requirements, there could be a mapping function between a QoS parameter combination which comprises at least {priority, reliability, latency, communication range} and HARQ operation parameters including whether HARQ retransmission is enabled or disabled.

[0034] HARQ Configuration for V2X

[0035] According to an embodiment, a HARQ process may be configured dynamically using 3GPP LTE-V2X (PC5) signaling or SL radio resource control (RRC) signaling between two V-UEs or within a group of V-UEs, or, alternatively, in a semi-static fashion using an initial configuration. As discussed above, the information about maximum number of HARQ processes, timers and resources considered above for HARQ feedback, etc. may be part of the noted dynamic or semi-static configuration, and may be exchanged between peer UEs before unicast or groupcast communication is initiated. If RRC signaling is used to exchange this configuration information, the information element below can be considered, on top of the HARQ configuration (which HARQ configuration is to contain process ID and remote vehicle (RV) information) as in a Uu case (with Uu referring to the logical interface between a UE and a base station in a V2N (vehicle to network) scenario):

sidelinkHARQConfig SEQUENCE {

nrofHARQ-Processes INTEGER (1..8),

nrofHARQ-retransmissions INTEGER (0..15),

maxACK-NACK INTEGER (0..15),

HARQ-retransmitTimer ENUMERATED {

ms2, ms3, ms4, ms5, ms6, ms7, ms8, mslO, msl4, msl6, ms20},

}

[0036] Fig. 2 shows a process 200 according to an embodiment, according to Fig. 2, at operation 202, encoding for transmission a packet in a cellular vehicle to everything (V2X) network, the transmission including one of a unicast transmission to a single vehicular user equipment (V-UE), or a groupcast transmission to a plurality of V-UEs; at operation 204, decoding a Hybrid Automatic Repeat Request (HARQ)-based message from at least one of the UEs, the HARQ-based message based on a HARQ configuration for the UE and being in response to the packet and at operation 206, in response to a determination, based on the HARQ-based message, that a HARQ retransmission of the packet is to be encoded, encoding for transmission the HARQ retransmission.

[0037] Fig. 3 illustrates an example architecture of a system 300 of a network, in accordance with various embodiments. Fig. 3 is similar to Fig. 1, except that it focuses on the various components of a cellular network rather than on components of a more specific version of a cellular network, a C-V2X network as shown in Fig. 1. The following description is provided for an example system 300 that operates in conjunction with the LTE system standards and 5G or NR system standards as provided by 3GPP technical specifications. However, the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., Sixth Generation (6G)) systems, IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), or the like.

[0038] As shown by Figure 3, the system 300 includes UE 301a and UE 301b (collectively referred to as "UEs 301" or "UE 301"). In this example, UEs 301 are illustrated as

smartphones, but may also comprise any mobile or non-mobile computing device.

[0039] The UEs 301 may be configured to connect, for example, communicatively couple, with an or RAN 310. In embodiments, the RAN 310 may be an NG RAN or a 5G RAN, an E- UTRAN, or a legacy RAN, such as a UTRAN or GERAN. As used herein, the term "NG RAN" or the like may refer to a RAN 310 that operates in an NR or 5G system 300, and the term "E- UTRAN" or the like may refer to a RAN 310 that operates in an LTE or 4G system 300. The UEs 301 utilize connections (or channels) 303 and 304, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below).

[0040] In this example, the connections 303 and 304 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a GSM protocol, a CDMA network protocol, a PTT protocol, a POC protocol, a UMTS protocol, a 3GPP LTE protocol, a 5G protocol, a NR protocol, and/or any of the other communications protocols discussed herein. In embodiments, the UEs 301 may directly exchange communication data via a ProSe interface 305 such as a PC5 interface. The ProSe interface 305 may alternatively be referred to as a SL interface 305 and may comprise one or more logical channels, including but not limited to a PSCCH, a PSSCH, a PSDCH, and a PSBCH.

[0041] The UE 301b is shown to be configured to access an AP 306 (also referred to as "WLAN node 306," "WLAN 306," "WLAN Termination 306," "WT 306" or the like) via connection 307. The connection 307 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP 306 would comprise a wireless fidelity (Wi-Fi^®) router. In this example, the AP 306 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below).

[0042] The RAN 310 can include one or more AN nodes or RAN nodes 311a and 311b (collectively referred to as "RAN nodes 311" or "RAN node 311") that enable the connections 303 and 304. As used herein, the terms "access node," "access point," or the like may describe equipment that provides the radio baseband functions for data and/or voice connectivity between a network and one or more users. These access nodes can be referred to as BS, N R evolved NodeBs (gNodeBs), RAN nodes, eN Bs, NodeBs, RSUs, TRxPs or TRPs, and so forth. As used herein, the term "NG RAN node" or the like may refer to a RAN node 311 that operates in an N R or 5G system 300 (for example, a gN B), and the term "E-UTRAN node" or the like may refer to a RAN node 311 that operates in an LTE or 4G system 300 (e.g., an eNB). According to various embodiments, the RAN nodes 311 may be implemented as one or more of a dedicated physical device such as a macrocell base station, and/or a low power (LP) base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0043] In embodiments, the UEs 301 can be configured to communicate using OFDM communication signals with each other or with any of the RAN nodes 311 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an OFDMA communication technique (e.g., for downlink communications) or a SC-FDMA communication technique (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.

[0044] In some embodiments, a downlink resource grid can be used for downlink

transmissions from any of the RAN nodes 311 to the U Es 301, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot.

Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid comprises a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements; in the frequency domain, this may represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

[0045] According to various embodiments, the UEs 301 and the RAN nodes 311, 312 communicate data (for example, transmit and receive) data over a licensed medium (also referred to as the "licensed spectrum" and/or the "licensed band") and an unlicensed shared medium (also referred to as the "unlicensed spectrum" and/or the "unlicensed band"). The licensed spectrum may include channels that operate in the frequency range of

approximately 400 MHz to approximately 3.8 GHz, whereas the unlicensed spectrum may include the 5 GHz band.

[0046] The RAN nodes 311 may be configured to communicate with one another via interface 312. In embodiments where the system 300 is a 5G or NR system, the interface 312 may be an Xn interface 312. The Xn interface is defined between two or more RAN nodes 311 (e.g., two or more gNodeBs or gNBs and the like) that connect to 5GC 320, between a RAN node 311 (e.g., a gNB) connecting to 5GC 320 and an eNB, and/or between two eNBs connecting to 5GC 320.

[0047] The RAN 310 is shown to be communicatively coupled to a core network— in this embodiment, core network (CN) 320. The CN 320 may comprise a plurality of network elements 322, which are configured to offer various data and telecommunications services to customers/subscribers (e.g., users of UEs 301) who are connected to the CN 320 via the RAN 310. The components of the CN 320 may be implemented in one physical node or separate physical nodes including components to read and execute instructions from a machine- readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium).

[0048] Generally, the application server 330 may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS PS domain, LTE PS data services, etc.). The application server 330 can also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 301 via the EPC 320. [0049] In embodiments, the CN 320 may be a 5GC (referred to as "5GC 320" or the like), and the RAN 310 may be connected with the CN 320 via an NG interface 313. In embodiments, the NG interface 313 may be split into two parts, an NG user plane (NG-U) interface 314, which carries traffic data between the RAN nodes 311 and a UPF, and the SI control plane (NG-C) interface 315, which is a signaling interface between the RAN nodes 311 and AMFs.

[0050] In embodiments, the CN 320 may be a 5G CN (referred to as "5GC 320" or the like), while in other embodiments, the CN 320 may be an EPC). Where CN 320 is an EPC (referred to as "EPC 320" or the like), the RAN 310 may be connected with the CN 320 via an SI interface 313. In embodiments, the SI interface 313 may be split into two parts, an SI user plane (Sl-U) interface 314, which carries traffic data between the RAN nodes 311 and the S- GW, and the Sl-MME interface 315, which is a signaling interface between the RAN nodes 311 and MMEs.

[0051] Fig. 4 illustrates example components of baseband circuitry 410 and radio front end modules (RFEM) 415 in accordance with various embodiments. Baseband circuitry 410 includes a RF interface 418 connecting it to the RFEM. As shown, the RFEMs 415 may include Radio Frequency (RF) circuitry 406, front-end module (FEM) circuitry 408, antenna array 411 coupled together at least as shown.

[0052] The baseband circuitry 410 includes circuitry and/or control logic configured to carry out various radio/network protocol and radio control functions that enable communication with one or more radio networks via the RF circuitry 406. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 410 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 410 may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of

modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments. The baseband circuitry 410 is configured to process baseband signals received from a receive signal path of the RF circuitry 406 and to generate baseband signals for a transmit signal path of the RF circuitry 406. The baseband circuitry 410 is configured to interface with an application circuitry for generation and processing of the baseband signals and for controlling operations of the RF circuitry 406. The baseband circuitry 410 may handle various radio control functions.

[0053] The aforementioned circuitry and/or control logic of the baseband circuitry 410 may include one or more single or multi-core processors. For example, the one or more processors may include a 3G baseband processor 404A, a 4G/LTE baseband processor 404B, a 5G/NR baseband processor 404C, or some other baseband processor(s) 404D for other existing generations, generations in development or to be developed in the future (e.g., sixth generation (6G), etc.). In other embodiments, some or all of the functionality of baseband processors 404A-D may be included in modules stored in the memory 404G and executed via a Central Processing Unit (CPU) 404E. In other embodiments, some or all of the functionality of baseband processors 404A-D may be provided as hardware accelerators (e.g., FPGAs,

ASICs, etc.) loaded with the appropriate bit streams or logic blocks stored in respective memory cells. In various embodiments, the memory 404G may store program code of a real time OS (RTOS), which when executed by the CPU 404E (or other baseband processor), is to cause the CPU 404E (or other baseband processor) to manage resources of the baseband circuitry 410, schedule tasks, etc. In addition, the baseband circuitry 410 includes one or more audio digital signal processor(s) (DSP) 404F. The audio DSP(s) 404F include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.

[0054] In some embodiments, each of the processors 404A-404E include respective memory interfaces to send/receive data to/from the memory 404G. The baseband circuitry 410 may further include one or more interfaces to communicatively couple to other circuitries/devices [0055] RF circuitry 406 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium.

[0056] In some embodiments, the receive signal path of the RF circuitry 406 may include mixer circuitry 406a, amplifier circuitry 406b and filter circuitry 406c. In some embodiments, the transmit signal path of the RF circuitry 406 may include filter circuitry 406c and mixer circuitry 406a. RF circuitry 406 may also include synthesizer circuitry 406d for synthesizing a frequency for use by the mixer circuitry 406a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 406a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 408 based on the synthesized frequency provided by synthesizer circuitry 406d. The amplifier circuitry 406b may be configured to amplify the down-converted signals and the filter circuitry 406c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 410 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 406a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[0057] FEM circuitry 408 may include a receive signal path, which may include circuitry configured to operate on RF signals received from antenna array 411, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 406 for further processing. FEM circuitry 408 may also include a transmit signal path, which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 406 for transmission by one or more of antenna elements of antenna array 411. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 406, solely in the FEM circuitry 408, or in both the RF circuitry 406 and the FEM circuitry 408.

[0058] The antenna array 411 comprises one or more antenna elements, each of which is configured convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. For example, digital baseband signals provided by the baseband circuitry 410 is converted into analog RF signals (e.g., modulated waveform) that will be amplified and transmitted via the antenna elements of the antenna array 411 including one or more antenna elements (not shown). The antenna elements may be omnidirectional, direction, or a combination thereof. The antenna elements may be formed in a multitude of arranges as are known and/or discussed herein. The antenna array 411 may comprise microstrip antennas or printed antennas that are fabricated on the surface of one or more printed circuit boards. The antenna array 411 may be formed in as a patch of metal foil (e.g., a patch antenna) in a variety of shapes, and may be coupled with the RF circuitry 406 and/or FEM circuitry 408 using metal transmission lines or the like.

[0059] One or more of the components of Figs. 3 and/or 4, may be used in any of the embodiments described herein. [0060] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.

[0061] The components of Figs. 3 and/or 4, such as the shown baseband processing circuitry including processing circuitry and a RF interface, may be used in any of the embodiments described herein, such as in a gNodeB or in a UE.

[0062] In some embodiments, the electronic device(s), network(s), system(s), chip(s) or component(s), or portions or implementations thereof, of Figs. 3 and/or 4, or some other figure herein, may be configured to perform one or more processes, techniques, or methods as described herein, or portions thereof.

[0063] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.

[0064] In some embodiments, the electronic device(s), network(s), system(s), chip(s) or component(s), or portions or implementations thereof, of Figs. 3 and/or 4, or some other figure herein, may be configured to perform one or more processes, techniques, or methods as described herein, or portions thereof. For example, the process may include receiving, by a signaling mechanism, an indication of a secondary physical random access channel (PRACFI) configuration; and identifying the secondary PRACFI configuration. [0065] In some embodiments, the electronic device of Figs. 3 and/or 4 may be configured to perform one or more processes, techniques, and/or methods as described herein, or portions thereof. For example, the process may include: determining an indication of a secondary physical random access channel (PRACFI) configuration; and transmitting, by a signaling mechanism, the indication of the secondary PRACFI configuration.

[0066] EXAMPLES

[0067] Example 1 includes a device of a New Radio (NR) User Equipment (UE), the device including processing circuitry and a radio frequency (RF) interface coupled to the processing circuitry, the processing circuitry to: encode a packet for transmission in a cellular vehicle to everything (V2X) network, the transmission including one of a unicast transmission to a single vehicular user equipment (V-UE), or a groupcast transmission to a plurality of V-UEs; decode a Flybrid Automatic Repeat Request (FIARQ)-based message from at least one of the UEs, the FIARQ-based message based on a FIARQ configuration for the UE and being in response to the packet; and in response to a determination, based on the FIARQ-based message, that a FIARQ retransmission of the packet is to be encoded, encode for transmission the FIARQ

retransmission.

[0068] Example 2 includes the subject matter of Example 1, and optionally, wherein the transmission includes a sidelink transmission.

[0069] Example 3 includes the subject matter of Example 1, and optionally, wherein the processing circuitry is to determine whether a FIARQ retransmission of the packet is to be encoded based on at least one of network configuration channel conditions or quality of service (QoS) requirements.

[0070] Example 4 includes the subject matter of Example 1, and optionally, further including decoding, during a connection establishment procedure, a unicast message from the single V- UE or from one of the plurality of V-UEs, and establishing the FIARQ configuration for the UE based on the unicast message.

[0071] Example 5 includes the subject matter of Example 1, and optionally, further including decoding a signal including one of a PC5-based signal or a radio resource control (RRC) signal, and establishing the FIARQ configuration based on the signal, wherein the RRC signal includes a dedicated information element (IE) to signal the FIARQ configuration. [0072] Example 6 includes the subject matter of Example 1, and optionally, wherein the processing circuitry is to determine a quality of service (QoS) requirement for the packet, the QoS requirement including a QoS flow identifier (QFI) for the packet.

[0073] Example 7 includes the subject matter of Example 1, and optionally, wherein the packet is an original packet or a HARQ retransmission of an original packet.

[0074] Example 8 includes the subject matter of Example 7, and optionally, wherein the HARQ-based message is a HARQ feedback and includes an acknowledgment (ACK) or a negative acknowledgment (NACK).

[0075] Example 9 includes the subject matter of Example 8, and optionally, wherein the processing circuitry is to: determine that the HARQ retransmission of the packet is to be encoded in response to a determination that the HARQ feedback includes a NACK; and determine that the HARQ retransmission of the packet is not to be encoded in response to a determination that the HARQ feedback includes an ACK.

[0076] Example 10 includes the subject matter of Example 8, and optionally, wherein the transmission is a groupcast transmission, and wherein the processing circuitry is to at least one of: determine whether the HARQ retransmission is to be encoded based on a

determination of whether a maximum number of ACKs or NACKs from respective ones of the plurality of V-UEs have been decoded; determine that the HARQ retransmission is not to be encoded based on expiration of a timer configured to the processing circuitry, the timer being based on quality of service (QoS) requirements of the original packet; determine a maximum number of HARQ retransmissions for the packet based on a QoS requirement of the packet and based on a mapping configured at an access stratum (AS) layer of the UE; or determine whether the HARQ retransmission is to be encoded based on a determination that an energy of received NACKs in response to the original packet is beyond a configured threshold.

[0077] Example 11 includes the subject matter of Example 10, and optionally, wherein, where the processing circuitry is to determine the maximum number of HARQ retransmissions based on the QoS requirements, the processing circuitry is to further decode NACKs from the plurality of V-UEs based on a random distribution of the NACKs in a time or frequency domain, the NACKs in response to the packet.

[0078] Example 12 includes the subject matter of Example 10, and optionally, wherein, where the processing circuitry is to determine the maximum number of HARQ retransmissions based on the QoS requirements, the processing circuitry is to further determine the maximum number of HARQ retransmissions based on the ACK or the NACK.

[0079] Example 13 includes the subject matter of Example 10, and optionally, wherein: the QoS requirement includes a QoS flow identifier (QFI) for the packet; and where the processing circuitry is to determine the maximum number of HARQ retransmissions based on the QoS requirements, the processing circuitry is to further use an access stratum (AS) layer thereof to map the QFI to the maximum number of HARQ retransmissions.

[0080] Example 14 includes the subject matter of any one of Examples 3, 6, and 10-13, wherein the QoS requirement comprises one or more of priority, reliability, latency and communication range.

[0081] Example 15 includes the subject matter of Example 10, and optionally, wherein, where the processing circuitry is to determine whether the HARQ retransmission is to be encoded based on a determination that an energy of received NACKs in response to the original packet is beyond a configured threshold, the processing circuitry is to determine that the HARQ retransmission is to be encoded in response to a determination that the NACKs in response to the original packet exceed the configured threshold.

[0082] Example 16 includes the subject matter of Example 10, and optionally, wherein, where the processing circuitry is to determine whether the HARQ retransmission is to be encoded based on a determination of whether a maximum number of ACKs or NACKs from respective ones of the plurality of V-UEs have been decoded, the processing circuitry is to at least one of: determine that the HARQ retransmission is to be encoded based on a determination that the maximum number of NACKs has been reached; or determine that the HARQ retransmission is not to be encoded based on a determination that the maximum number of ACKs has been reached.

[0083] Example 17 includes the subject matter of Example 10, and optionally, wherein HARQ feedback is associated with a group ID for a group of V-UEs including the UE.

[0084] Example 18 includes the subject matter of Example 10, and optionally, the processing circuitry to retransmit to one of the plurality of V-UEs an original groupcast packet received at the UE from another one of the plurality of V-UEs, the processing circuitry to retransmit in response to decoding a NACK from said one of the plurality of V-UEs that was based on the original groupcast packet. [0085] Example 19 includes the subject matter of any one of Examples 1-18, further including a front end module coupled to the RF interface.

[0086] Example 20 includes the subject matter of Example 19, and optionally, further including one or more antennas coupled to the front end module, the antennas to transmit or receive signals.

[0087] Example 21 includes a method to be performed at a device of a New Radio (NR) User Equipment (UE), the method including: encoding for transmission a packet in a cellular vehicle to everything (V2X) network, the transmission including one of a unicast transmission to a single vehicular user equipment (V-UE), or a groupcast transmission to a plurality of V- UEs; decoding a Hybrid Automatic Repeat Request (HARQ)-based message from at least one of the UEs, the HARQ-based message based on a HARQ configuration for the UE and being in response to the packet; and in response to a determination, based on the HARQ-based message, that a HARQ retransmission of the packet is to be encoded, encoding for transmission the HARQ retransmission.

[0088] Example 22 includes the subject matter of Example 21, and optionally, wherein the transmission includes a sidelink transmission.

[0089] Example 23 includes the subject matter of Example 21, and optionally, the method further including determining whether a HARQ retransmission of the packet is to be encoded based on at least one of network configuration channel conditions or quality of service (QoS) requirements.

[0090] Example 24 includes the subject matter of Example 21, and optionally, further including decoding, during a connection establishment procedure, a unicast message from the single V-UE or from one of the plurality of V-UEs, and establishing the HARQ configuration for the UE based on the unicast message.

[0091] Example 25 includes the subject matter of Example 21, and optionally, further including decoding a signal including one of a PC5-based signal or a radio resource control (RRC) signal, and establishing the HARQ configuration based on the signal, wherein the RRC signal includes a dedicated information element (IE) to signal the HARQ configuration.

[0092] Example 26 includes the subject matter of Example 21, and optionally, the method further including determining a quality of service (QoS) requirement for the packet, the QoS requirement including a QoS flow identifier (QFI) for the packet. [0093] Example 27 includes the subject matter of Example 21, and optionally, wherein the packet is an original packet or a HARQ retransmission of an original packet.

[0094] Example 28 includes the subject matter of Example 27, and optionally, wherein the HARQ-based message is a HARQ feedback and includes an acknowledgment (ACK) or a negative acknowledgment (NACK) in response to the packet.

[0095] Example 29 includes the subject matter of Example 28, and optionally, the method further including: determining that the HARQ retransmission of the packet is to be encoded in response to a determination that the HARQ feedback includes a NACK; and determining that the HARQ retransmission of the packet is not to be encoded in response to a determination that the HARQ feedback includes an ACK.

[0096] Example 30 includes the subject matter of Example 28, and optionally, wherein the transmission is a groupcast transmission, and the method further including at least one of: determining whether the HARQ retransmission is to be encoded based on a determination of whether a maximum number of ACKs or NACKs from respective ones of the plurality of V-UEs have been decoded; determining that the HARQ retransmission is not to be encoded based on expiration of a timer configured to the device, the timer being based on quality of service (QoS) requirements of the original packet; determining a maximum number of HARQ retransmissions for the packet based on a QoS requirement of the packet and based on a mapping configured at an access stratum (AS) layer of the UE; or determining whether the HARQ retransmission is to be encoded based on a determination that an energy of received NACKs in response to the original packet is beyond a configured threshold.

[0097] Example 31 includes the subject matter of Example 30, and optionally, wherein, where the method includes determining the maximum number of HARQ retransmissions based on the QoS requirements, the method further includes decoding NACKs from the plurality of V- UEs based on a random distribution of the NACKs in a time or frequency domain, the NACKs in response to the packet.

[0098] Example 32 includes the subject matter of Example 30, and optionally, wherein, where the method includes determining the maximum number of HARQ retransmissions based on the QoS requirements, the method further includes determining the maximum number of HARQ retransmissions based on the ACK or the NACK.

[0099] Example 33 includes the subject matter of Example 30, and optionally, wherein: the QoS requirement includes a QoS flow identifier (QFI) for the packet; and where the method includes determining the maximum number of HARQ retransmissions based on the QoS requirements, the method further includes using an access stratum (AS) layer thereof to map the QFI to the maximum number of HARQ retransmissions.

[0100] Example 34 includes the subject matter of any one of Examples 23, 26, and 30-33, and optionally, wherein the QoS requirement comprises one or more of priority, reliability, latency and communication range.

[0101] Example 35 includes the subject matter of Example 30, and optionally, wherein, where the method includes determining whether the HARQ retransmission is to be encoded based on a determination that an energy of received NACKs in response to the original packet is beyond a configured threshold, the method further includes determining that the HARQ retransmission is to be encoded in response to a determination that the NACKs in response to the original packet exceed the configured threshold.

[0102] Example 36 includes the subject matter of Example 30, and optionally, wherein, where the method includes determining whether the HARQ retransmission is to be encoded based on a determination of whether a maximum number of ACKs or NACKs from respective ones of the plurality of V-UEs have been decoded, the method further includes at least one of:

determining that the HARQ retransmission is to be encoded based on a determination that the maximum number of NACKs has been reached; or determining that the HARQ

retransmission is not to be encoded based on a determination that the maximum number of ACKs has been reached.

[0103] Example 37 includes the subject matter of Example 30, and optionally, wherein HARQ feedback is associated with a group ID for a group of V-UEs including the UE.

[0104] Example 38 includes the subject matter of Example 30, and optionally, the method further including retransmitting to one of the plurality of V-UEs an original groupcast packet received at the UE from another one of the plurality of V-UEs, retransmitting being in response to decoding a NACK from said one of the plurality of V-UEs that is based on the original groupcast packet.

[0105] Example 39 includes a device of a New Radio (NR) User Equipment (UE), the device including: means for encoding for transmission a packet in a cellular vehicle to everything (V2X) network, the transmission including one of a unicast transmission to a single vehicular user equipment (V-UE), or a groupcast transmission to a plurality of V-UEs; means for decoding a Hybrid Automatic Repeat Request (HARQ)-based message from at least one of the UEs, the HARQ-based message based on a HARQ configuration for the UE and being in response to the packet; and means for, in response to a determination, based on the HARQ- based message, that a HARQ retransmission of the packet is to be encoded, encoding for transmission the HARQ retransmission.

[0106] Example 40 includes the subject matter of Example 39, and optionally, wherein the transmission includes a sidelink transmission.

[0107] Example 41 includes the subject matter of Example 39, and optionally, further including means for determining whether a HARQ retransmission of the packet is to be encoded based on at least one of network configuration channel conditions or quality of service (QoS) requirements.

[0108] Example 42 includes a device of a New Radio (NR) User Equipment (UE), the device including processing circuitry and a radio frequency (RF) interface coupled to the processing circuitry, the processing circuitry to: decode a packet transmitted in a cellular vehicle to everything (V2X) network by a vehicular user equipment (V-UE), the packet including one of a unicast packet or a groupcast packet; encode for transmission a Hybrid Automatic Repeat Request (HARQ)-based message based on a HARQ configuration for the UE and in response to the packet; and decode a HARQ retransmission of the packet from the V-UE.

[0109] Example 43 includes the subject matter of Example 42, and optionally, wherein the packet includes a sidelink packet.

[0110] Example 44 includes the subject matter of Example 42, and optionally, further including decoding, during a connection establishment procedure, a unicast message from the V-UE, and establishing the HARQ configuration for the UE based on the unicast message.

[0111] Example 45 includes the subject matter of Example 42, and optionally, further including encoding a signal including one of a PC5-based signal or a radio resource control (RRC) signal, the signal to cause the V-UE to establish the HARQ configuration, wherein the RRC signal includes a dedicated information element (IE) to signal the HARQ configuration.

[0112] Example 46 includes the subject matter of Example 42, and optionally, wherein the packet is an original packet or a HARQ retransmission of an original packet.

[0113] Example 47 includes the subject matter of Example 46, and optionally, wherein the HARQ-based message is a HARQ feedback and includes an acknowledgment (ACK) or a negative acknowledgment (NACK). [0114] Example 48 includes the subject matter of Example 47, and optionally, wherein the processing circuitry is to further encode the NACK for transmission within randomly selected time or frequency resources.

[0115] Example 49 includes the subject matter of Example 47, and optionally, wherein the HARQ feedback is associated with a group ID for a group of V-UEs of the network including the U E, and wherein the processing circuitry is to encode the HARQ feedback only in response to a determination that sidelink radio conditions are below a threshold.

[0116] Example 50 includes the subject matter of Example 42, and optionally, wherein the packet is a groupcast packet, the processing circuitry to retransmit to one of a plurality of V- UEs of the network an original groupcast packet received at the UE from another one of the plurality of V-UEs, the processing circuitry to retransmit in response to decoding a NACK from said one of the plurality of V-UEs that was based on the original packet.

[0117] Example 51 includes the subject matter of Example 47, and optionally, wherein the processing circuitry is determine whether to send a HARQ feedback based on a quality of service of the packet, and based on a timer configu red to the processing circuitry.

[0118] Example 52 includes the subject matter of any one of Examples 42-51, further including a front end module coupled to the RF interface.

[0119] Example 53 includes the subject matter of Example 52, and optionally, further including one or more antennas coupled to the front end module, the antennas to transmit or receive signals.

[0120] Example 54 includes machine-readable medium including code which, when executed, is to cause a machine to perform the method of any one of Examples 20-38.

[0121] Example 55 includes a machine-readable medium including code which, when executed, is to cause a machine to perform the method of any one of Examples 20-38.

[0122] Example 56 includes a product comprising one or more tangible computer-readable non-transitory storage media comprising computer-executable instructions operable to, when executed by at least one computer processor, enable the at least one computer processor to perform the method of any one of Examples 20-38.

[0123] Example 57 includes an apparatus comprising means for causing a wireless communication device to perform the method of any one of Examples 20-38.

[0124] Example 58 includes a signal as described in or related to any of the examples above, or portions or parts thereof. [0125] Example 59 includes a signal in a wireless network as shown and described herein.

[0126] Example 60 includes a method of communicating in a wireless network as shown and described herein.

[0127] Example 61 includes a system for providing wireless communication as shown and described herein.

[0128] Example 62 includes a method of communicating for use in a new radio (NR) vehicle to everything (V2X) based telecommunication system, comprising: determining or causing to determine channel conditions, dedicated resources, and quality of service (QoS) requirements associated with a hybrid automatic repeat request (HARQ) mechanism for communications between a plurality of vehicular user equipment (V-UEs).

[0129] Example 63 includes the method of example 61 or some other example herein, further comprising: receiving or causing to receive a result of determining whether the HARQ mechanism is enabled based on the QoS requirements.

[0130] Example 64 includes a method of communicating for use in a new radio (NR) vehicle to everything (V2X) based telecommunication system, comprising: configuring or causing to configure a hybrid automatic repeat request (HARQ) mechanism for communications between a plurality of vehicular user equipment (V-UEs) using 3GPP LTE-V2X (PC5) signaling or sidelink (SL) radio resource control (RRC) signaling; and initiating or causing to initiate groupcast communication or unicast communication between the plurality of V-UEs in response to the configuring.

[0131] Example 65 includes an apparatus for use in performing communication in a new radio (NR) vehicle to everything (V2X) based telecommunication system, the apparatus configured to perform the method set forth in any one of Examples 62-63.

[0132] Example 66 includes an apparatus for use in performing communication in a new radio (NR) vehicle to everything (V2X) based telecommunication system, the apparatus configured to perform the method set forth in Example 64.

[0133] Example 67 includes an apparatus for use in performing communication in a new radio (NR) vehicle to everything (V2X) based telecommunication system, the apparatus comprising means for performing the method set forth in any one of Examples 62-63.

[0134] Example 68 includes an apparatus for use in performing communication in a new radio (NR) vehicle to everything (V2X) based telecommunication system, the apparatus comprising means for performing the method set forth in Example 63. [0135] Example 69 includes a method of communicating in a wireless network as shown and described herein.

[0136] Example 70 includes a system for providing wireless communication as shown and described herein.

[0137] Example 71 includes a device for providing wireless communication as shown and described herein.

[0138] Example 72 includes an apparatus comprising means for performing one or more of the methods described above.

[0139] Example 73 includes an apparatus comprising circuitry configured to perform one or more of the methods described above.

[0140] Example 74 includes an apparatus as described herein, wherein the apparatus or any portion thereof is implemented in or by a user equipment (UE).

[0141] Example 75 includes a method as described herein, wherein the method or any portion thereof is implemented in or by a user equipment (UE).

[0142] Example 76 includes an apparatus as described herein, wherein the apparatus or any portion thereof is implemented in or by a base station (BS).

[0143] Example 77 includes a method as described herein, wherein the method or any portion thereof is implemented in or by a base station (BS).

[0144] Any of the above-described examples may be combined with any other example (or combination of examples), unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed.

Claims

What is claimed is:

1. A device of a New Radio (NR) User Equipment (UE), the device including processing circuitry and a radio frequency (RF) interface coupled to the processing circuitry, the processing circuitry to:

encode a packet for transmission in a cellular vehicle to everything (V2X) network, the transmission including one of a unicast transmission to a single vehicular user equipment (V-UE), or a groupcast transmission to a plurality of V-UEs;

decode a Hybrid Automatic Repeat Request (HARQ)-based message from at least one of the UEs, the HARQ-based message based on a HARQ configuration for the UE and being in response to the packet; and

in response to a determination, based on the HARQ-based message, that a HARQ retransmission of the packet is to be encoded, encode for transmission the HARQ

retransmission.

2. The device of claim 1, further including decoding, during a connection establishment procedure, a unicast message from the single V-UE or from one of the plurality of V-UEs, and establishing the HARQ configuration for the UE based on the unicast message.

3. The device of claim 1, further including decoding a signal including one of a PC5- based signal or a radio resource control (RRC) signal, and establishing the HARQ configuration based on the signal, wherein the RRC signal includes a dedicated information element (IE) to signal the HARQ configuration.

4. The device of claim 1, wherein the processing circuitry is to determine a quality of service (QoS) requirement for the packet, the QoS requirement including a QoS flow identifier (QFI) for the packet.

5. The device of claim 1, wherein the packet is an original packet or a HARQ

retransmission of an original packet.

6. The device of claim 5, wherein the HARQ-based message is a HARQ feedback and includes an acknowledgment (ACK) or a negative acknowledgment (NACK).

7. The device of claim 6, wherein the processing circuitry is to:

determine that the HARQ retransmission of the packet is to be encoded in response to a determination that the HARQ feedback includes a NACK; and

determine that the HARQ retransmission of the packet is not to be encoded in response to a determination that the HARQ feedback includes an ACK.

8. The device of claim 6, wherein the transmission is a groupcast transmission, and wherein the processing circuitry is to at least one of:

determine whether the HARQ retransmission is to be encoded based on a determination of whether a maximum number of ACKs or NACKs from respective ones of the plurality of V-UEs have been decoded;

determine that the HARQ retransmission is not to be encoded based on expiration of a timer configured to the processing circuitry, the timer being based on quality of service (QoS) requirements of the original packet;

determine a maximum number of HARQ retransmissions for the packet based on a QoS requirement of the packet and based on a mapping configured at an access stratum (AS) layer of the UE; or

determine whether the HARQ retransmission is to be encoded based on a determination that an energy of received NACKs in response to the original packet is beyond a configured threshold.

9. The device of claim 8, wherein, where the processing circuitry is to determine the maximum number of HARQ retransmissions based on the QoS requirements, the processing circuitry is to further determine the maximum number of HARQ retransmissions based on the ACK or the NACK.

10. The device of claim 8, wherein:

the QoS requirement includes a QoS flow identifier (QFI) for the packet; and where the processing circuitry is to determine the maximum number of HARQ retransmissions based on the QoS requirements, the processing circuitry is to further use an access stratum (AS) layer thereof to map the QFI to the maximum number of HARQ retransmissions.

11. The device of claim 8, wherein, where the processing circuitry is to determine whether the HARQ retransmission is to be encoded based on a determination that an energy of received NACKs in response to the original packet is beyond a configured threshold, the processing circuitry is to determine that the HARQ retransmission is to be encoded in response to a determination that the NACKs in response to the original packet exceed the configured threshold.

12. The device of claim 8, wherein, where the processing circuitry is to determine whether the HARQ retransmission is to be encoded based on a determination of whether a maximum number of ACKs or NACKs from respective ones of the plurality of V-UEs have been decoded, the processing circuitry is to at least one of:

determine that the HARQ retransmission is to be encoded based on a determination that the maximum number of NACKs has been reached; or

determine that the HARQ retransmission is not to be encoded based on a determination that the maximum number of ACKs has been reached.

13. The device of claim 8, the processing circuitry to retransmit to one of the plurality of V-UEs an original groupcast packet received at the UE from another one of the plurality of V- UEs, the processing circuitry to retransmit in response to decoding a NACK from said one of the plurality of V-UEs that was based on the original groupcast packet.

14. The device of any one of claims 1-13, further including a front end module coupled to the RF interface.

15. The device of claim 14, further including one or more antennas coupled to the front end module, the antennas to transmit or receive signals.

16. A method to be performed at a device of a New Radio (NR) User Equipment (UE), the method including:

encoding for transmission a packet in a cellular vehicle to everything (V2X) network, the transmission including one of a unicast transmission to a single vehicular user equipment (V-UE), or a groupcast transmission to a plurality of V-UEs; decoding a Hybrid Automatic Repeat Request (HARQ)-based message from at least one of the UEs, the HARQ-based message based on a HARQ configuration for the UE and being in response to the packet; and

in response to a determination, based on the HARQ-based message, that a HARQ retransmission of the packet is to be encoded, encoding for transmission the HARQ retransmission.

17. The method of claim 16, further including decoding, during a connection

establishment procedure, a unicast message from the single V-UE or from one of the plurality of V-UEs, and establishing the HARQ configuration for the UE based on the unicast message.

18. The method of claim 16, the method further including determining a quality of service (QoS) requirement for the packet, the QoS requirement including a QoS flow identifier (QFI) for the packet.

19. The method of claim 16, wherein the packet is an original packet or a HARQ retransmission of an original packet.

20. The method of claim 19, wherein the HARQ-based message is a HARQ feedback and includes an acknowledgment (ACK) or a negative acknowledgment (NACK) in response to the packet.

21. The method of claim 20, the method further including:

determining that the HARQ retransmission of the packet is to be encoded in response to a determination that the HARQ feedback includes a NACK; and

determining that the HARQ retransmission of the packet is not to be encoded in response to a determination that the HARQ feedback includes an ACK.

22. The method of claim 20, wherein the transmission is a groupcast transmission, and the method further including at least one of:

determining whether the HARQ retransmission is to be encoded based on a determination of whether a maximum number of ACKs or NACKs from respective ones of the plurality of V-UEs have been decoded; determining that the HARQ retransmission is not to be encoded based on expiration of a timer configured to the device, the timer being based on quality of service (QoS) requirements of the original packet;

determining a maximum number of HARQ retransmissions for the packet based on a QoS requirement of the packet and based on a mapping configured at an access stratum (AS) layer of the UE; or

determining whether the HARQ retransmission is to be encoded based on a determination that an energy of received NACKs in response to the original packet is beyond a configured threshold.

23. A device of a New Radio (NR) User Equipment (UE), the device including:

means for encoding for transmission a packet in a cellular vehicle to everything (V2X) network, the transmission including one of a unicast transmission to a single vehicular user equipment (V-UE), or a groupcast transmission to a plurality of V-UEs;

means for decoding a Hybrid Automatic Repeat Request (HARQ)-based message from at least one of the UEs, the HARQ-based message based on a HARQ configuration for the UE and being in response to the packet; and

means for, in response to a determination, based on the HARQ-based message, that a HARQ retransmission of the packet is to be encoded, encoding for transmission the HARQ retransmission.

24. The device of claim 23, further including means for determining whether a HARQ retransmission of the packet is to be encoded based on at least one of network configuration channel conditions or quality of service (QoS) requirements.

25. A machine-readable medium including code which, when executed, is to cause a machine to perform the method of any one of claims 16-22.