EP3834355A1 - Control signaling for new radio vehicle-to-vehicle communication - Google Patents

Abstract

Embodiment of the present disclosure describes methods and apparatuses for receiving configuration information from a network the configuration information to include an indication of sidelink control resources for V2V communication, an indication of one or more PSCCH formats to be transmitted or monitored by the vehicle-based UE, and an indication of one or more SCI formats to be transmitted or monitored by the vehicle -based UE and transmitting or monitor for a PSCCH transmission that includes SCI based on the configuration information.

Description

CONTROL SIGNALING FOR NEW RADIO VEHICLE-TO- VEHICLE

COMMUNICATION

Related Application

This application claims priority to U.S. Provisional Application No. 62/717,177 filed August 10, 2018. The specification of said application is hereby incorporated by reference in its entirety.

Field

Embodiments of the present disclosure generally relate to the field of wireless

communication, and more particularly, to apparatuses, systems, and methods for control signaling in vehicle-to-vehicle communication.

Background

Release 16 of Third Generation Partnership Project (“3GPP”) new radio (“NR”) specifications provide physical layer and protocols to support advanced vehicle-to- everything (V2X) use cases, such as sensor sharing, autonomous and remote driving, etc. Releases 14 and 15 of 3GPP Long Term Evolution (LTE) specifications emphasized basic safety features. In comparison, the NR V2X targets a very diverse set of use cases and associated requirements.

Brief Description of the Drawings

Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings.

Figure 1 illustrates a network in accordance with some embodiments.

Figure 2 illustrates different PSCCH formats in accordance with some embodiments.

Figure 3 illustrates a frequency division multiplex option in accordance with some embodiments.

Figure 4 illustrates time division multiplex options in accordance with some embodiments.

Figure 5 illustrates sideline control channel element formats in accordance with some embodiments.

Figure 6 illustrates supported multiplexing options in accordance with some embodiments. Figure 7 illustrates an example operation flow/algorithmic structure in accordance with some embodiments.

Figure 8 illustrates an example operation flow/algorithmic structure in accordance with some embodiments.

Figure 9 illustrates an electronic device in accordance with some embodiments.

Figure 7 illustrates baseband circuitry in accordance with some embodiments.

Figure 8 illustrates communication circuitry in accordance with some embodiments.

Figure 9 illustrates an electronic device in accordance with some embodiments.

Figure 10 illustrates circuitry of an electronic device in accordance with some

embodiments.

Figure 11 illustrates interfaces of baseband circuitry in accordance with some

embodiments.

Figure 12 illustrates components of an electronic device in accordance with some embodiments.

Detailed Description

In the following detailed description, reference is made to the accompanying drawings, which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments that may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure.

Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order than the described embodiment. Various additional operations may be performed or described operations may be omitted in additional embodiments.

The description may use the phrases“in an embodiment,” or“in embodiments,” which may each refer to one or more of the same or different embodiments. Furthermore, the terms“comprising,”“including,”“having,” and the like, as used with respect to embodiments of the present disclosure, are synonymous. For the purposes of the present disclosure, the phrases“A or B,”“A and/or B,” and“A/B” mean (A), (B), or (A and B).

Figure 1 illustrates a network 100 in accordance with some embodiments. The network 100 may be designed to facilitate communications with vehicle-based user equipments (UEs). The network 100 may include a first vehicle-based UE 104, a second vehicle-based UE 108, a base station 112, a person-based UE 116, and an infrastructure-based UE 120.

In some embodiments, the network 100 may be a 5G/NR compatible network.

The network 100 may be referred to as a vehicle-to-every thing (V2X) network that facilitates communication between each of the devices of the network 100. The network 100 may provide for vehicle-to-vehicle (V2V) communication (for example, between vehicle-based UE 104 and vehicle-based UE 108), vehicle-to-infrastructure (V2I) communication (for example, between vehicle-based UE 108 and infrastructure-based UE 120), vehicle-to network (V2N) communication (for example, between vehicle-based UE 108 and the base station 112), and vehicle-to-pedestrian (V2P) communication (for example, between vehicle-based UE 108 and user-based UE 116).

A user-based UE 116, as used herein, may be a UE designed to be carried by a user. A user-based UE 116 may be a smartphone or a wearable device (for example, a smartwatch, fitness tracker, smartglasses, etc.).

Vehicle-based UEs, as used herein, may be UEs that are configured to provide V2X communication from a vehicle. Typically, the vehicle-based UEs are permanently mounted within the vehicle; however, in other embodiments the vehicle-based UEs may be removable.

The infrastructure-based UE 120 may also be referred to as a roadside unit (RSU), which may refer to any transportation infrastructure entity used for V2X communications. The infrastructure-based UE 120 may be implemented in or by a suitable radio access node or a stationary (or relatively stationary) UE. In one example, the infrastructure-based UE 120 may be a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicles, for example vehicle-based UE 108 and vehicle-based UE 104. The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic. The computing device(s) and some or all of the radio-frequency circuitry of the infrastructure-based UE 120 may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network.

The diverse set of use cases and requirements associated with NR V2X motivates a sidelink physical-layer design that is both flexible and reconfigurable. This may facilitate high data rate best effort traffic and ultra-low latency, reliable transmissions with ~lms delay and 10 ⁵ reliability in different coverage regions.

The desired radio-interface flexibility may be supported taking into account the extreme requirements on latency and reliability. While shared channel transmission reliability and latency may already be achieved in wide range due to dynamic indication of parameters in sidelink control indication (SCI), the flexibility of control transmission itself may be a key design point for sidelink based NR V2X.

Furthermore, except the link performance and configurability, potentially system level design components such as channel access may need to support new functionality providing different latency and reliability.

Previous sidelink design for V2V communication, for example, from 3GPP LTE Releases 14 and 15, is optimized for broadcast basic safety traffic. Thus, its applicability to NR advanced V2X use cases is very limited. The limitation of LTE Release 14/15 sidelink design for V2V communication comes mainly from broadcast-centric physical layer design and fixed control/data transmission format. That would lead to inefficient support of use cases requiring substantially different latency and reliability as demanded by advanced V2X.

Embodiments herein provide mechanisms and components of sidelink communication targeting different use cases and objectives. Embodiments include unified physical control channel design; multiplexing of physical control and data channels; sidelink preemption indication; and group retransmission and feedback mechanisms.

Link-level components for reliable low-latency transmission

First, the design of NR V2V communication may allow link performance to achieve the identified variety of reliability and latency targets for a given scenario and traffic pattern/ data rate. In that aspect, the following design principles may be followed. Sufficient flexibility in exploiting all sources of diversity for both control and data physical channels:

o Time diversity, for example, transmission distributed over the latency

budget;

o Frequency diversity, for example, frequency hopping or distributed resources allocation;

o Interference / collision diversity, for example, randomization of interference and collisions including co-channel interference, in-band emissions (IBE), out-of-band emissions (OOB), half-duplex (HD);

o Spatial micro-diversity, for example, transmission diversity modes utilizing MIMO schemes; and

o Spatial macro-diversity, for example, duplication at PDCP layer and

transmission over multiple component carriers.

Sufficient flexibility in achievable channel access latency and transmission duration.

Sufficient flexibility in achievable spectrum efficiency, support of low spectrum efficiency:

o Physical sidelink control channel (PSCCH)

^■ Mechanisms of variable redundancy per information bit by

transmitting SCI over configured number of PSCCH resources and/or changing the operating SCI payload size; and

o Physical sidelink shared channel (PSSCH)

^■ Support of MCS tables designed for different BLER targets, e.g.

10% and 0.001%, and

^■ Flexibly configurable repetitions for PSSCH.

Link adaptation based on channel quality measurements or HARQ-ACK feedback.

Configuration of aspects of control channels, as used herein, may include a base station generating and sending configuration messages (for example, radio resource control (RRC) configuration messages) to a UE, or may include pre-configuration by

programming a device consistent with established specifications, for example, 3G PPA technical specifications. Physical sidelink control channel design

Sidelink control signaling for V2X communication may carry at least one of the following types of information: scheduling assignment (SA), scheduling grant (SG), or scheduling request (SR). It could be assumed that any type of sidelink control information may be carried by physical sidelink control channel (PSCCH). Further in this invention, it is assumed that the described PSCCH design principles may be applicable to any type of sidelink control information.

As discussed above, it may be desirable for both control and shared channel transmission formats to be flexible enough to support diverse set of reliability and latency targets. Unlike in Release 14 LTE V2V communication, where single PSCCH format is applied, in NR the PSCCH may be designed to support more PSCCH formats with different spectrum efficiency, for example, redundancy per information bit for SCI transmission.

In order to achieve different redundancy per information bit, the following general approaches may be considered:

· Variable number of control resource elements; and

• Variable payload size.

The variable number of control resource elements may be provided as follows.

In 3GPP cellular systems, for example, NR and LTE, variable number of downlink control resource elements may be realized by different PDCCH formats expressed as different levels of aggregation of Control Channel Elements (CCE), which may comprise a same or different number of resources element groups (REGs) depending of the PDCCH format. In sidelink physical control channel design for NR, similar concept could be used taking into account the specifics of sidelink communication and sidelink physical structure.

In that case, a sidelink control channel element (SL-CCE) or simply sidelink control resource may be introduced as a minimum granularity of PSCCH resource allocation. Further, different PSCCH physical formats can be defined depending on the number of SL-CCE as presented in Table 1, for example.

Table 1 : NR PSCCH formats

In various embodiments, a particular format to use may either be configured or decided by a UE based on distributed scheduling procedure and/or channel quality measurements. The format may also be changed based on congestion control procedures. For example, a UE may select transmission with smaller number of SL-CCEs in case of high loading and with more SL-CCEs in case of low loading.

The number of SL-CCEs to be used for a PSCCH needs to be known to both transmitting UE and receiving UEs for proper receive processing. For that purpose, rules and restrictions how to map a PSCCH format to N (SL-CCE) SL-CCEs may be defined and known by both transmitting/receiving UEs.

A sidelink PSCCH control resource set (CORESET) may be introduced as part of sidelink resource pool configuration. The PSCCH CORESET may indicate the symbols and PRBs used for purposes of PSCCH monitoring.

Figure 2 illustrates different PSCCH formats in accordance with some embodiments. Structure 204 illustrates the numerology and slot format, with 30 kHz slots and 14 symbols with a normal cyclic prefix (CP). The diamond hash marked symbols may represent a first symbol of a slot.

Structure 208 illustrates slots with sidelink CORESETs and PSSCHs in accordance with some embodiments. If a UE is configured with PSCCH format 0 (one SL-CCE per SCI format transmission as in Table 1), then the CORESET may be divided onto independent non-overlapping candidates for PSCCH decoding as illustrated on the left-hand side of structure 208. Here, PSCCH SL CORESET 212 is composed of two consecutive SL-CCEs in time and four adjacent SL-CCEs in frequency in a slot. In total, there are 8 candidates for decoding of PSCCH format 0: Cl-0, Cl-l ... , Cl-7. If a UE is configured with PSSCH format 1 (two SL-CCE per SCI format transmission according to Table 1), and hopping is not desired (as discussed below), pairs of CCEs of SL CORESET 212 may be combined according to their hatching infill; however, in other embodiments, other pairs may be used (as further discussed below).

If a UE is configured with PSCCH format 1 (two SL-CCE per SCI format transmission according to Table 1), it may be beneficial to define non-overlapping candidates in order to reduce blind decoding efforts from the UE. Moreover, due to power limitation at the UE and the principle of maximized coverage for control signaling transmission, it may be desirable to limit composing PSCCH transmission from SL-CCE of different time resources. In that case there may be no power sharing between SL-CCE and, therefore, no coverage penalty from increased aggregation level. An example candidate mapping for PSCCH format 1 is illustrated as SL CORESET 216 in the right-hand side of Figure 2. SL CORESET 216 includes pairs of SL-CCEs, which is composed from candidates separated by a frequency offset known to the receiving UE. This may enable a desirable level of frequency diversity being achieved for the overall SCI transmission. In total there may be four candidates of PSCCH format 1: C2-0, C2-1, C2-2, and C2-3.

It may be noted, that candidates of different PSCCH formats may overlap. For example, each candidate of PSCCH format 1 may contain two candidates of PSCCH format 2. In Figure 2, it could be seen that candidate C2-0 may contain two candidates Cl-0 and Cl -6, candidate C2-1 may contain candidates Cl-l and Cl-7, etc.

For the introduced PSCCH formats, the UE behavior may be specified from both TX and RX perspective.

Transmitting UE behavior for transmitting PSCCH may be as follows. A transmitting UE may select PSCCH candidate for SCI transmission based on a grant from gNB or based on a distributed scheduling procedure. The distributed scheduling procedure may be performed by the transmitting UE and it may take into account channel sensing and measurements, priority, and other aspects. The selected PSCCH candidate may fall into the space of candidates to be monitored by intended receiver(s).

Receiving UE behavior for receiving PSCCH may be as follows. In order to keep receive- processing complexity manageable, the maximum number of candidates for PSCCH decoding may be fixed and known to a UE. In that case, a UE may be configured to monitor a given PSCCH format with a given number of attempts / blind decodings. Also a rule how to combine different SL-CCEs into a candidate may defined.

In some embodiments, a total number of channel estimations‘JT per PSCCH CORESET monitoring occasion or per slot may be defined. In that case, a UE may not be expected to be configured with PSCCH formats and number of candidates that lead to the number of channel estimations exceeding the total defined number. In case of configuration exceeding‘JT, a UE may apply a prioritization rule to identify the candidates to be checked and drop other candidates beyond the channel estimation attempts budget.

Furthermore, a total number‘7’ of blind decoding attempts across all configured PSCCH formats in a CORESET monitoring occasion or a slot may be predefined in a 3GPP technical specification. The UE may not be expected to be configured with PSCCH formats and number of candidates that lead to the number of blind decoding attempts exceeding the total defined number. In case of configuration exceeding‘7’, a UE may apply prioritization rule to identify the candidates to be checked and drop other candidates beyond the blind decoding budget.

In one example, the resources in sidebnk CORESET may be divided onto‘common’ resources, which may be configured semi-statically by the network, and‘custom’ (UE- specific/group-specific/link-specific) resources, which may be established during unicast/groupcast communication and are known only to UEs in the intended group. The common and custom resources may be overlapped or multiplexed so that the total blind decoding efforts for a UE do not exceed V and‘7’ as defined above.

Variable payload size

There may be a tradeoff between scheduling flexibility and amount of dynamic and semi static signaling required to support such flexibility. Moreover, the larger the control signaling payload size the worse the coverage and reliability due to fundamental restrictions. In order to support all the diverse requirements and use cases of NR V2X communications, it may be desirable to provide the control signaling for sidebnk with a variable payload size so that an appropriate combination of flexibility and reliability may be configured/selected in a particular case.

In one embodiment, a UE may be configured to transmit or monitor one or more SCI formats with the same or different payload sizes. In that case a blind decoding in the same resource assuming different payload sizes may be counted separately to fulfill the blind decoding hypothesis budget A UE may not be expected to be configured with more than, for example, 2-4 different sizes for blind decoding in the same CORESET.

Multiplexing of PSCCH and PSSCH

Different multiplexing options of control (PSCCH) and data (PSSCH) may also provide different latency and reliability tradeoff. For example, control and data transmitted in the same transmission time interval (TTI) multiplexed in frequency domain may provide the lowest transmission latency and duration but may also experience shared power between PSCCH and PSSCH so that coverage of both of them is penalized. On the other hand, if PSCCH and PSSCH are transmitted at different times they may not share power and may preserve DFT-s-OFDM waveform properties increasing coverage for both control and data. This may consume more resources in time domain and, therefore, lead to slightly increased transmission latency, congestion, and half-duplex problems.

For NR V2X design, all the above examples of multiplexing may be accommodated using a flexible resource allocation design paradigm. In this section, the desired control and data channel multiplexing options are described one by one and then a common signaling and UE behavior approach is presented.

First, the NR V2X may support the Release 14 option, where PSCCH and PSSCH are multiplexed in the same TTI in either adjacent or non-adjacent manner. As illustrated in Figure 3, which shows a frequency division multiplex (FDM) option for PSCCH and PSSCH multiplexing in accordance with some embodiments, the PSCCH SL CORESET may be distributed over the system bandwidth so that in, case of transmission, the data and control may be multiplexed in frequency in the same time unit (for example, slot, multiple slots, or a fraction of a slot). Note that in general, from the UE perspective, control and data may still be transmitted in time division multiplex (TDM) manner in different time occasions where the time gap between control and data may be either predefined or signaled in SCI. In another embodiment, PSCCH and PSSCH may be TDMed within a slot or different slots by specific PSCCH CORESET configuration. Besides the example in Figure 2 with PSCCH and PSSCH multiplexed in the same slot, the multiplexing option may also be similar to structures 404 and 408 of Figure 4, which illustrates TDM options for PSCCH and PSSCH multiplexing on a slot level in accordance with some embodiments. As shown in Figure 4, one slot may be dedicated to control signaling, while one or more separate slots may be dedicated to shared channel transmissions. Here it is important to note, that channel access instances may still be configured differently. Structure 404 may include channel-access symbols 412, 416, 420, and 424 that may be used to separately perform channel access for each resource carrying either control or data (for example, listen- before-talk). Structure 408, on the other hand, may only include channel-access symbols 428 and 432 once per multiple slots, for example, for both control and shared channels.

In order to accommodate all the described multiplexing options within NR V2X communication framework, configurable resource structures from both system perspective and UE perspective may be defined.

From a network perspective, a concept of sidelink resource pools may be employed to signal spectrum resources to be used for transmission and monitoring at least of PSCCH and PSSCH. The resource pool configuration may at least convey which PRBs in frequency and which groups of slots/symbols in which occasions are dedicated to PSCCH. Then, the configuration may also indicate which PRBs in frequency and which groups of slots/symbols in which occasions are dedicated to PSSCH. The signaling mechanism may signal PSCCH and PSSCH resources separately or jointly.

Within a configured PSCCH resource pool, the PSCCH resources may be mapped to SL- CCEs. The SL-CCE duration in symbols and bandwidth in PRBs or REs may be configured within a predefined range or be a single fixed value.

For example, one SL-CCE may have duration indicated from the set of 1 to 14 symbols (including potential gap and automatic gain control (AGC) symbols). However, such flexibility may not be useful and may complicate UE implementation and system design, therefore a small subset may be defined. In some embodiments, at least full slot allocation, for example, 14 symbols for normal cyclic prefix (NCP) and 12 symbols for extended cyclic prefix (ECP) may be included into the set. Additionally, several sub-slot durations may be needed at least to realize the case of TDM of PSCCH and PSSCH within a slot similar to what is illustrated in Figure 2. Therefore, aggregation of SL-CCEs in time domain may be defined as illustrated in Figure 5 in accordance with some embodiments.

Figure 5 illustrates SL-CCE formats in accordance with some embodiments. Structures 504 illustrate examples of SL-CCE formats with different durations. These durations may let to multiplex control and data in the same slot for latency critical services or to multiplex multiple SL-CCEs within a slot. The SL-CCE bandwidth may at least include 1, 2 PRBs to support Release l4-like physical structure. The SL-CCE bandwidth may in the same time be a function of duration. For example, in case of full slot SL-CCE duration, it may be a relatively small value of 1-2 PRBs while in case of sub-slot durations it may grow to 4-6 PRBs, for example.

Structures 508 illustrate examples of SL-CCE formats with different occupied bandwidth and duration in accordance with some embodiments. With these structures, single SL-CCE bandwidth may be defined (e.g., 1 PRB) and aggregation of the SL-CCEs in frequency domain may be adopted.

Once the dimensions of control channels are defined and known to both transmitting UE and receiving UE, the transmitting UE may follow the distributed or gNB/eNB-controlled scheduling mode to transmit control and data according to the configured/selected multiplexing option. The multiplexing option may be specific to a particular scheduling decision and may be UE-specific. Thus, it may not be known to receiving UEs until decoding of control information.

Figure 6 illustrates options of multiplexing of PSCCH and PSSCH from TX UE perspective that may be supported in accordance with some embodiments.

In option 1, sub-slot level PSCCH/PSSCH are TDMed in a same slot. This option may provide a fixed link budget for control channel transmissions (similar reliability across UEs), reduce an amount of sidelink channel access attempts needed for transmission of control and shared channels, and provide latency benefits for control channel processing. However, this option may have limited control channel capacity (low order of frequency multiplexing).

In option 2, slot level PSCCH/PSSCH are FDMed in a same slot. This option may reduce an amount of sidelink channel access attempts needed for transmission of control and shared channels, provide sufficient control channel capacity (frequency multiplexing), and provide a common sensing procedure for control and shared channel transmissions. However, this option may have latency for control channel processing, and the power of control channel may be shared with shared channel.

In option 3, slot-level PSCCH and PSSCH are TDMed in different slots. This option may provide maximum energy per control and shared channel transmission (desirable for high reliability), and provide sufficient control channel capacity. However, this option may have latency for control channel processing, and resource selection may be needed for both control and shared channel.

In option 4, sub-slot level PSCCH/PSSCH are TDMed in different slots. This option may provide fixed link budget for control channel transmissions (similar reliability across UEs), and provide latency benefits for control channel processing. However, this option may have limited control channel capacity (low order of frequency multiplexing), resource selection may be needed for both control and shared channel, and sub-slot level transmission for PSCCH only may include additional AGC considerations.

System level components

In order to provide collision-free communication in some special cases, e.g., for transmission of urgent data, a resource preemption mechanism may be defined for NR V2X sidelink communication.

In one example, a PSCCH transmission may convey a‘Preemption’ SCI format (P-SCI) indicating time and frequency resources and their time schedule in future. When detected by other UEs, these resources shall be released by these UEs (e.g. dropped or rate-matched or punctured). Alternatively, when detected by other UEs, all resources overlapped in time with the indicated resources shall be released by these UEs. The detection of P-SCI with resources overlapped at a particular UE may trigger resource reselection in some cases.

The P-SCI may be carried by a conventional SCI format as a bit field.

The P-SCI may also carry a priority level value (e.g., one of 8 or 16 levels) wherein the release of the indicated resources may only be triggered for transmissions of <lower> or <equal or lower> priority.

Another potential enhancement related to reliable V2V communication is introduction of physical layer feedback and retransmissions. Such behavior may be typically a part of unicast communication. However, in case of groupcast communication (e.g., platooning use case), the feedback may not be easy to organize due to multiple recipients. In one example related to groupcast communication, the following radio-layer enhancements may be used to improve sidelink communication performance in distributed resource allocation mode.

Group radio-layer feedback

When a transmitter of a UE sends sidelink transmission/message to a group, a UE that received PSCCH but has not received PSSCH (for example, should have, but did not receive a PSSCH) may send a negative acknowledgement (NACK) on a resource reserved by the transmitter for acknowledgement. The reserved resource for NACK may be indicated in SCI scheduling data from the transmitting UE in the group.

Group radio-layer (re)transmission

If UEs of a group detect NACK from at least one of the group members, UEs can retransmit successfully received packet on a resource that can be either reserved by a UE that failed to receive the transmission, or by the original source of transmission.

Figure 7 illustrates an operation flow/algorithmic structure 700 in accordance with some embodiments. The operation flow/algorithmic structure 700 may be performed by a vehicle-based UE or components thereof. For example, the operation flow/algorithmic structure 700 may be performed by the vehicle-based UE 104 or vehicle-based UE 108 described above with respect to Figure 1.

The operation flow/algorithmic structure 700 may include, at 704, receiving configuration information from a network. In some embodiments, the vehicle-based UE may receive the configuration information from a base station, for example base station 112, through configuration parameters or information elements included RRC signaling. The configuration information to include an indication of sidelink control resources for V2V communication, an indication of one or more PSCCH formats to be transmitted or monitored by the vehicle-based UE, and an indication of one or more SCI formats to be transmitted or monitored by the vehicle-based UE.

In some embodiments, the indication of the one or more PSCCH formats may include indications of a plurality of PSCCH formats, with individual PSCCH formats being associated with a respective number of sidelink control channel elements. The associations may be similar to those described above with respect to Table 1. In some embodiments, the vehicle-based UE may select a particular PSCCH format from available PSCCH formats based on various operations or procedures performed by the UE. For example, in some embodiments the PSCCH format may be selected based on a distributed scheduling procedure, channel quality measurements, or a congestion-control procedure (or network load determined therefrom). Once selected, the vehicle-based UE may generate and transmit the PSCCH transmission with the selected PSCCH format.

The operation flow/algorithmic structure 700 may further include, at 708, transmitting or monitoring for a PSCCH transmission that includes SCI based on the configuration information. The transmitting or monitoring for the PSCCH transmission may be done based on the configuration information. For example, the vehicle-based UE may determine a PSCCH format then determine which SL-CCEs are to carry the corresponding PSCCH transmission. The vehicle-based UE may then either monitor candidate SL-CCEs, or select SL-CCEs of the candidates on which the PSCCH is to be encoded.

Figure 8 illustrates an operation flow/algorithmic structure 800 in accordance with some embodiments. The operation flow/algorithmic structure 800 may be performed by a vehicle-based UE or components thereof. For example, the operation flow/algorithmic structure 800 may be performed by the vehicle-based UE 104 or vehicle-based UE 108 described above with respect to Figure 1.

The operation flow/algorithmic structure 800 may include, at 804, detecting a sidelink feedback resource reserved by transmitter for one or more UEs of a group to provide radio-layer feedback. In some embodiments, the resource may be a physical sidelink feedback channel (PSFCH) resource.

In some embodiments, detection of the reserved resource may be performed by detecting sidelink control information, transmitted from a transmitter of another UE, that schedules data.

The operation flow/algorithmic structure 800 may further include, at 808, determining a PSSCH transmission directed to the group is not properly received by the vehicle-based UE. In some embodiments, the vehicle-based UE may determine, from sidelink control information, that a PSSCH transmission is to be sent to a group of which the vehicle-based UE is a member. If the vehicle-based UE then fails to properly decode the scheduled transmission, and part, or in whole, the UE may determine that the PSSCH transmission is not properly received. The operation flow/algorithmic structure 800 may further include, at 812, transmitting a NACK on the reserved sidelink feedback resource based on the determination at 808.

Figure 9 illustrates an example of a platform 900 (or“device 900”) in accordance with various embodiments. In embodiments, the computer platform 900 may be suitable for use as any of the UEs of Figure 1 or any other element/device discussed herein. The platform 900 may include any combinations of the components shown in the example. The components of platform 900 may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof adapted in the computer platform 900, or as components otherwise incorporated within a chassis of a larger system. The block diagram of Figure 9 is intended to show a high level view of components of the computer platform 900.

However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

The application circuitry 905 may include circuitry such as, but not limited to, single-core or multi-core processors and one or more of cache memory, low drop-out voltage regulators (LDOs), interrupt controllers, serial interfaces such as serial peripheral interface (SPI), inter-integrated circuit (I2C) or universal programmable serial interface circuit, real time clock (RTC), timer-counters including interval and watchdog timers, general purpose input/output (IO), memory card controllers such as secure digital/multi-media card (SD/MMC) or similar, universal serial bus (USB) interfaces, mobile industry processor interface (MIPI) interfaces and Joint Test Access Group (JTAG) test access ports. The processor(s) may include any combination of general-purpose processors and/or dedicated processors (e.g., graphics processors, application processors, etc.). The processors (or cores) may be coupled with or may include memory /storage and may be configured to execute instructions stored in the memory /storage to enable various applications or operating systems to run on the platform 900. In some embodiments, processors of application circuitry 905 may process IP data packets received from an EPC or 5GC.

Application circuitry 905 may be or include a microprocessor, a multi-core processor, a multithreaded processor, an ultra-low voltage processor, an embedded processor, or other known processing element. In one example, the application circuitry 905 may include an Intel® Architecture Core™ based processor, such as a Quark™, an Atom™, an i3, an i5, an i7, or an MCU-class processor, or another such processor available from Intel® Corporation, Santa Clara, CA. The processors of the application circuitry 905 may also be one or more of Advanced Micro Devices (AMD) Ryzen® processor(s) or Accelerated Processing Units (APUs); A5-A9 processor(s) from Apple® Inc., Snapdragon™ processor(s) from Qualcomm® Technologies, Inc., Texas Instruments, Inc.® Open Multimedia Applications Platform (OMAP)™ processor(s); a MIPS-based design from MIPS Technologies, Inc.; an ARM-based design licensed from ARM Holdings, Ltd.; or the like. In some implementations, the application circuitry 905 may be a part of a system on a chip (SoC) in which the application circuitry 905 and other components are formed into a single integrated circuit, or a single package, such as the Edison™ or Galileo™ SoC boards from Intel® Corporation.

Additionally or alternatively, application circuitry 905 may include circuitry such as, but not limited to, one or more a field-programmable devices (FPDs) such as FPGAs and the like; programmable logic devices (PLDs) such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), and the like; ASICs such as structured ASICs and the like;

programmable SoCs (PSoCs); and the like. In such embodiments, the circuitry of application circuitry 905 may comprise logic blocks or logic fabric, and other

interconnected resources that may be programmed to perform various functions, such as the procedures, methods, functions, etc. of the various embodiments discussed herein. In such embodiments, the circuitry of application circuitry 905 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), anti-fuses, etc.)) used to store logic blocks, logic fabric, data, etc. in look-up tables (LUTs) and the like.

The baseband circuitry 910 may be implemented, for example, as a solder-down substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board or a multi-chip module containing two or more integrated circuits. Although not shown, baseband circuitry 910 may comprise one or more digital baseband systems, which may be coupled via an interconnect subsystem to a CPU subsystem, an audio subsystem, and an interface subsystem. The digital baseband subsystems may also be coupled to a digital baseband interface and a mixed-signal baseband subsystem via another interconnect subsystem. Each of the interconnect subsystems may include a bus system, point-to-point connections, network-on-chip (NOC) structures, and/or some other suitable bus or interconnect technology, such as those discussed herein. The audio subsystem may include digital signal processing circuitry, buffer memory, program memory, speech processing accelerator circuitry, data converter circuitry such as analog- to-digital and digital-to-analog converter circuitry, analog circuitry including one or more of amplifiers and filters, and/or other like components. In an aspect of the present disclosure, baseband circuitry 910 may include protocol processing circuitry with one or more instances of control circuitry (not shown) to provide control functions for the digital baseband circuitry and/or radio frequency circuitry (e.g., the radio front end modules 915).

As used herein, the term“circuitry” may refer to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable System on Chip (SoC)), digital signal processors (DSPs), etc., that are configured to provide the described functionality.

In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. In addition, the term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

The terms“application circuitry” and/or“baseband circuitry” may be considered synonymous to, and may be referred to as,“processor circuitry.” As used herein, the term “processor circuitry” may refer to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and/or transferring digital data. The term“processor circuitry” may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and/or functional processes.

The radio front end modules (RFEMs) 915 may comprise a millimeter wave RFEM and one or more sub-millimeter wave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-millimeter wave RFICs may be physically separated from the millimeter wave RFEM. The RFICs may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both millimeter wave and sub-millimeter wave radio functions may be implemented in the same physical radio front end module 915. The RFEMs 915 may incorporate both millimeter wave antennas and sub-millimeter wave antennas.

The memory circuitry 920 may include any number and type of memory devices used to provide for a given amount of system memory. As examples, the memory circuitry 920 may include one or more of volatile memory including random access memory (RAM), dynamic RAM (DRAM) and/or synchronous dynamic RAM (SDRAM), and nonvolatile memory (NVM) including high-speed electrically erasable memory (commonly referred to as Flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc. The memory circuitry 920 may be developed in accordance with a Joint Electron Devices Engineering Council (JEDEC) low power double data rate (LPDDR)-based design, such as LPDDR2, LPDDR3, LPDDR4, or the like. Memory circuitry 920 may be implemented as one or more of solder down packaged integrated circuits, single die package (SDP), dual die package (DDP) or quad die package (Q17P), socketed memory modules, dual inline memory modules (DIMMs) including microDIMMs or MiniDIMMs, and/or soldered onto a motherboard via a ball grid array (BGA). In low power implementations, the memory circuitry 920 may be on-die memory or registers associated with the application circuitry 905. To provide for persistent storage of information such as data, applications, operating systems and so forth, memory circuitry 920 may include one or more mass storage devices, which may include, inter alia, a solid state disk drive (SSDD), hard disk drive (HDD), a micro HDD, resistance change memories, phase change memories, holographic memories, or chemical memories, among others. For example, the computer platform 900 may incorporate the three-dimensional (3D) cross-point (XPOINT) memories from Intel® and Micron®.

Removable memory circuitry 923 may include devices, circuitry, enclosures/housings, ports or receptacles, etc. used to couple portable data storage devices with the platform 900. These portable data storage devices may be used for mass storage purposes, and may include, for example, flash memory cards (e.g., Secure Digital (SD) cards, microSD cards, xD picture cards, and the like), and USB flash drives, optical discs, external HDDs, and the like.

The platform 900 may also include interface circuitry (not shown) that is used to connect external devices with the platform 900. The external devices connected to the platform 900 via the interface circuitry may include sensors 921, such as accelerometers, level sensors, flow sensors, temperature sensors, pressure sensors, barometric pressure sensors, and the like. The interface circuitry may be used to connect the platform 900 to electro mechanical components (EMCs) 922, which may allow platform 900 to change its state, position, and/or orientation, or move or control a mechanism or system. The EMCs 922 may include one or more power switches, relays including electromechanical relays (EMRs) and/or solid state relays (SSRs), actuators (e.g., valve actuators, etc.), an audible sound generator, a visual warning device, motors (e.g., DC motors, stepper motors, etc.), wheels, thrusters, propellers, claws, clamps, hooks, and/or other like electro-mechanical components. In embodiments, platform 900 may be configured to operate one or more EMCs 922 based on one or more captured events and/or instructions or control signals received from a service provider and/or various clients.

In some implementations, the interface circuitry may connect the platform 900 with positioning circuitry 945, which may be the same or similar as the positioning circuitry

945 discussed with regard to Figure 9.

In some implementations, the interface circuitry may connect the platform 900 with Near- Field Communication (NFC) circuitry 940, which may include an NFC controller coupled with an antenna element and a processing device. The NFC circuitry 940 may be configured to read electronic tags and/or connect with another NFC-enabled device.

The driver circuitry 946 may include software and hardware elements that operate to control particular devices that are embedded in the platform 900, attached to the platform 900, or otherwise communicatively coupled with the platform 900. The driver circuitry

946 may include individual drivers allowing other components of the platform 900 to interact with or control various input/output (I/O) devices that may be present within, or connected to, the platform 900. For example, driver circuitry 946 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface of the platform 900, sensor drivers to obtain sensor readings of sensors 921 and control and allow access to sensors 921, EMC drivers to obtain actuator positions of the EMCs 922 and/or control and allow access to the EMCs 922, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

The power management integrated circuitry (PMIC) 925 (also referred to as“power management circuitry 925”) may manage power provided to various components of the platform 900. In particular, with respect to the baseband circuitry 910, the PMIC 925 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMIC 925 may often be included when the platform 900 is capable of being powered by a battery 930, for example, when the device is included in a UE XQ01, XQ02, XR101.

In some embodiments, the PMIC 925 may control, or otherwise be part of, various power saving mechanisms of the platform 900. For example, if the platform 900 is in an

RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the platform 900 may power down for brief intervals of time and thus save power. If there is no data traffic activity for an extended period of time, then the platform 900 may transition off to an RRC Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The platform 900 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The platform 900 may not receive data in this state; in order to receive data, it must transition back to RRC Connected state. An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

A battery 930 may power the platform 900, although in some examples the platform 900 may be mounted deployed in a fixed location, and may have a power supply coupled to an electrical grid. The battery 930 may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in V2X applications, the battery 930 may be a typical lead-acid automotive battery. In some implementations, the battery 930 may be a“smart batery,” which includes or is coupled with a Batery Management System (BMS) or batery monitoring integrated circuitry. The BMS may be included in the platform 900 to track the state of charge (SoCh) of the batery 930. The BMS may be used to monitor other parameters of the batery 930 to provide failure predictions, such as the state of health (SoH) and the state of function (SoF) of the batery 930. The BMS may communicate the information of the batery 930 to the application circuitry 905 or other components of the platform 900. The BMS may also include an analog-to-digital (ADC) convertor that allows the application circuitry 905 to directly monitor the voltage of the batery 930 or the current flow from the batery 930. The batery parameters may be used to determine actions that the platform 900 may perform, such as transmission frequency, network operation, sensing frequency, and the like.

A power block, or other power supply coupled to an electrical grid may be coupled with the BMS to charge the batery 930. In some examples, the power block XS30 may be replaced with a wireless power receiver to obtain the power wirelessly, for example, through a loop antenna in the computer platform 900. In these examples, a wireless batery charging circuit may be included in the BMS. The specific charging circuits chosen may depend on the size of the batery 930, and thus, the current required. The charging may be performed using the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard promulgated by the Alliance for Wireless Power, among others.

User interface circuitry 950 includes various input/output (I/O) devices present within, or connected to, the platform 900, and includes one or more user interfaces designed to enable user interaction with the platform 900 and/or peripheral component interfaces designed to enable peripheral component interaction with the platform 900. The user interface circuitry 950 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual butons (e.g., a reset buton), a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, and/or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position(s), or other like information. Output device circuitry may include any number and/or combinations of audio or visual display, including, inter alia, one or more simple visual outputs/indicators (e.g., binary status indicators (e.g., light emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as display devices or touchscreens (e.g., Liquid Crystal Displays (LCD), LED displays, quantum dot displays, projectors, etc.), with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the platform 900. The output device circuitry may also include speakers or other audio emitting devices, printer(s), and/or the like. In some embodiments, the sensor circuitry 921 may be used as the input device circuitry (e.g., an image capture device, motion capture device, or the like) and one or more EMCs may be used as the output device circuitry (e.g., an actuator to provide haptic feedback or the like). In another example, NFC circuitry comprising an NFC controller coupled with an antenna element and a processing device may be included to read electronic tags and/or connect with another NFC-enabled device. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power supply interface, etc

Although not shown, the components of platform 900 may communicate with one another using a suitable bus technology, which may include any number of technologies, including industry standard architecture (ISA), extended ISA (EISA), peripheral component interconnect (PCI), peripheral component interconnect extended (PCIx), PCI express (PCIe), a Time-Trigger Protocol (TTP) system, a FlexRay system, or any number of other technologies. The bus may be a proprietary bus, for example, used in a SoC based system. Other bus systems may be included, such as an I2C interface, an SPI interface, point-to- point interfaces, and a power bus, among others.

Figure 10 illustrates example components of baseband circuitry 910 and radio front end modules (RFEM) 915 in accordance with various embodiments. As shown, the RFEMs 915 may include Radio Frequency (RF) circuitry 1006, front-end module (FEM) circuitry 1008, one or more antennas 1011 coupled together at least as shown.

The baseband circuitry 910 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 910 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1006 and to generate baseband signals for a transmit signal path of the RF circuitry 1006. Baseband processing circuitry 910 may interface with the application circuitry 905 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1006. For example, in some embodiments, the baseband circuitry 910 may include a third generation (3G) baseband processor 1004A, a 4G baseband processor 1004B, a 5G baseband processor 1004C, or other baseband processor(s) 1004D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 910 (e.g., one or more of baseband processors 1004A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1006. In other embodiments, some or all of the functionality of baseband processors 1004A-D may be included in modules stored in the memory 1004G and executed via a Central Processing Unit (CPU) 1004E. 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 910 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 910 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.

In some embodiments, the baseband circuitry 910 may include one or more audio digital signal processor(s) (DSP) 1004F. The audio DSP(s) 1004F may include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip or a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 910 and the application circuitry 905 may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 910 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 910 may support communication with an E-UTRAN or other WMAN, a WLAN, a WPAN. Embodiments in which the baseband circuitry 910 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry. RF circuitry 1006 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1006 may include switches, filters, amplifiers, etc. to facilitate the

communication with the wireless network. RF circuitry 1006 may include a receive signal path, which may include circuitry to down-convert RF signals received from the FEM circuitry 1008 and provide baseband signals to the baseband circuitry 910. RF circuitry 1006 may also include a transmit signal path, which may include circuitry to up-convert baseband signals provided by the baseband circuitry 910 and provide RF output signals to the FEM circuitry 1008 for transmission.

In some embodiments, the receive signal path of the RF circuitry 1006 may include mixer circuitry l006a, amplifier circuitry l006b and filter circuitry l006c. In some

embodiments, the transmit signal path of the RF circuitry 1006 may include filter circuitry l006c and mixer circuitry l006a. RF circuitry 1006 may also include synthesizer circuitry l006d for synthesizing a frequency for use by the mixer circuitry l006a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry l006a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 1008 based on the synthesized frequency provided by synthesizer circuitry l006d. The amplifier circuitry l006b may be configured to amplify the down- converted signals and the filter circuitry l006c 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 910 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 l006a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry l006a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry l006d to generate RF output signals for the FEM circuitry 1008. The baseband signals may be provided by the baseband circuitry 910 and may be filtered by filter circuitry 1006c.

In some embodiments, the mixer circuitry l006a of the receive signal path and the mixer circuitry l006a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry l006a of the receive signal path and the mixer circuitry l006a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry l006a of the receive signal path and the mixer circuitry l006a of the transmit signal path may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry l006a of the receive signal path and the mixer circuitry l006a of the transmit signal path may be configured for super heterodyne operation.

In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 1006 may include analog-to-digital converter (ADC) and digital -to-analog converter (DAC) circuitry and the baseband circuitry 910 may include a digital baseband interface to communicate with the RF circuitry 1006.

In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuitry l006d may be a fractional -N synthesizer or a fractional N/N+l synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry l006d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry l006d may be configured to synthesize an output frequency for use by the mixer circuitry l006a of the RF circuitry 1006 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry l006d may be a fractional N/N+l synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 910 or the application circuitry 905 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the application circuitry 905.

Synthesizer circuitry l006d of the RF circuitry 1006 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DP A). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry l006d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry 1006 may include an IQ/polar converter.

FEM circuitry 1008 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 1011, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1006 for further processing. FEM circuitry 1008 may also include a transmit signal path, which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1006 for transmission by one or more of the one or more antennas 1011. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 1006, solely in the FEM circuitry 1008, or in both the RF circuitry 1006 and the FEM circuitry 1008.

In some embodiments, the FEM circuitry 1008 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry 1008 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 1008 may include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 1006). The transmit signal path of the FEM circuitry 1008 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1006), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1011).

Processors of the application circuitry 905 and processors of the baseband circuitry 910 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 910, alone or in combination, may be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 905 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., TCP and UDP layers). As referred to herein, Layer 3 may comprise a RRC layer, described in further detail below. As referred to herein, Layer 2 may comprise a MAC layer, an RLC layer, and a PDCP layer, described in further detail below. As referred to herein, Layer 1 may comprise a PHY layer of a UE/RAN node, described in further detail below.

Figure 11 illustrates example interfaces of baseband circuitry in accordance with various embodiments. As discussed above, the baseband circuitry 910 of FIGS. XS1, 9, and XT may comprise processors 1004A-1004E and a memory 1004G utilized by said processors. Each of the processors 1004A-1004E may include a memory interface, 11104A-11104E, respectively, to send/receive data to/from the memory 1004G.

The baseband circuitry 910 may further include one or more interfaces to

communicatively couple to other circuitries/devices, such as a memory interface 11112 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 910), an application circuitry interface 11114 (e.g., an interface to send/receive data to/from the application circuitry 905 of FIGS. XS1-XT), an RF circuitry interface 11116 (e.g., an interface to send/receive data to/from RF circuitry 1006 of Figure XT), a wireless hardware connectivity interface 11118 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 11120 (e.g., an interface to send/receive power or control signals to/from the PMIC 925. Figure 12 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Figure 12 shows a diagrammatic representation of hardware resources 1200 including one or more processors (or processor cores) 1210, one or more memory /storage devices 1220, and one or more communication resources 1230, each of which may be communicatively coupled via a bus 1240. As used herein, the term“computing resource,”“hardware resource,” etc., may refer to a physical or virtual device, a physical or virtual component within a computing environment, and/or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor/CPU time and/or processor/CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input/output operations, ports or network sockets, channel/link allocation, throughput, memory usage, storage, network, database and applications, and/or the like. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 1202 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1200. A“virtualized resource” may refer to compute, storage, and/or network resources provided by virtualization infrastructure to an application, device, system, etc.

The processors 1210 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 1212 and a processor 1214.

The memory /storage devices 1220 may include main memory, disk storage, or any suitable combination thereof. The memory /storage devices 1220 may include, but are not limited to, any type of volatile or nonvolatile memory such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read only memory (EPROM), electrically erasable programmable read-only memory

(EEPROM), Flash memory, solid-state storage, etc.

The communication resources 1230 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1204 or one or more databases 1206 via a network 1208. For example, the communication resources 1230 may include wired communication components (e.g., for coupling via a universal serial bus (USB)), cellular communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components. As used herein, the term“network resource” or

“communication resource” may refer to computing resources that are accessible by computer devices via a communications network. The term“system resources” may refer to any kind of shared entities to provide services, and may include computing and/or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.

Instructions 1250 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1210 to perform any one or more of the methodologies discussed herein. The instructions 1250 may reside, completely or partially, within at least one of the processors 1210 (e.g., within the processor’s cache memory), the memory /storage devices 1220, or any suitable combination thereof. Furthermore, any portion of the instructions 1250 may be transferred to the hardware resources 1200 from any combination of the peripheral devices 1204 or the databases 1206. Accordingly, the memory of processors 1210, the memory /storage devices 1220, the peripheral devices 1204, and the databases 1206 are examples of computer-readable and machine-readable media.

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.

Some non-limiting examples are provided below.

Example 1 includes a method comprising receiving configuration information from a network the configuration information to include an indication of sidelink control resources for vehicle-to-vehicle (V2V) communication, an indication of one or more physical sidelink control channel (PSCCH) formats to be transmitted or monitored by the vehicle-based UE, and an indication of one or more sidelink control information (SCI) formats to be transmitted or monitored by the vehicle-based UE; and transmitting or monitoring for a PSCCH transmission that includes SCI based on the configuration information.

Example 2 includes the method of example 1 or some other example herein, wherein the indication of one or more PSCCH formats includes indications of a plurality of PSCCH formats, wherein individual PSCCH formats are associated with a respective number of sidelink control channel elements.

Example 3 includes the method of example 2 or some other example herein, wherein the plurality of PSCCH formats includes a first PSCCH format associated with 1 sidelink control channel element; a second PSCCH format associated with 2 sidelink control channel elements; a third PSCCH format associated with 4 sidelink control channel elements; a fourth PSCCH format associated with 8 sidelink control channel elements; a fifth PSCCH format associated with 16 control channel elements; and a sixth PSCCH format associated with 32 control channel elements.

Example 4 includes the method of example 2 or some other example herein, further comprising: selecting a PSCCH format from the plurality of PSCCH formats based on a distributed scheduling procedure, channel quality measurements, or a congestion-control procedure; and transmitting the PSCCH transmission with the selected PSCCH format.

Example 5 includes the method of example 4 some other example herein, further comprising selecting the PSCCH format based on a network load determined from the congestion-control procedure.

Example 6 includes the method of example 1 or some other example herein, wherein the configuration information includes a rule to map the PSCCH transmission to one or more sidelink control channel elements in a sidelink control resource set.

Example 7 includes the method of example 1 or some other example herein, further comprising determining a number of attempts to decode the PSCCH format based on the configuration information or a predefined configuration.

Example 8 includes the method of example 1 or some other example herein, further comprising: determining, based on the configuration information, a first set of control resources available to all UEs of a network; and determining a second set of control resources available to a subset of the UEs of the network.

Example 9 includes the method of example 1 or some other example herein, further comprising determining, based on configuration information or a distributed scheduling decision, a PSCCH and physical sidelink shared channel (PSSCH) multiplexing scheme.

Example 10 includes the method of example 9 or some other example herein, wherein the PSCCH and PSSCH multiplexing scheme is at a sub-slot level with the PSCCH and the PSSCH time division multiplexed in a same slot; at a slot level with the PSCCH and PSSCH frequency division multiplexed in a same slot; at a slot level with the PSCCH and the PSSCH time division multiplexed in different slots; or at a sub-slot level with the PSCCH and the PSSCH time division multiplexed in different slots.

Example 11 includes a method comprising storing configuration information to indicate sidelink control resources for vehicle-to-vehicle (V2V) communication, one or more physical sidelink control channel (PSCCH) formats to be transmitted or monitored by the vehicle-based UE, and a mapping rule for mapping a PSCCH transmission to plurality of sidelink control channel elements that are frequency division multiplexed or time division multiplexed with a contiguous allocation property; and causing the PSCCH transmission to be transmitted on the plurality of sidelink control channel elements or monitor the plurality of sidelink control channel elements for the PSCCH transmission based on the configuration information.

Example 12 includes the method of example 11 or some other example herein, wherein the plurality of sidelink control channel elements comprise 12 resource elements in a frequency domain and three symbols in a time domain.

Example 13 includes the method of example 11 or some other example herein, wherein the PSCCH transmission comprises preemption sidelink control information to indicate time and frequency resources to be released by one or more UEs.

Example 14 includes the method of example 13 or some other example herein, further comprising: detecting the preemption sidelink control information; determining an overlapped schedule with respect to a transmission scheduled in the time and frequency resources; and performing a resource reselection for the transmission based on the determination of the overlapped schedule and the preemption sidelink control information. Example 15 includes the method of example 13 or some other example herein, wherein the preemption sidelink control information includes an indication of a priority level value and the method further comprises: determining an overlapped schedule with respect to a transmission scheduled in the time and frequency resources, the transmission to include an associated transmission priority; comparing the transmission priority to the priority level value; and determining whether to release the time and frequency resources based on the comparison of the transmission priority to the priority level value.

Example 16 includes a method comprising: detecting a sidelink feedback resource reserved by transmitter for one or more UEs of a group to provide radio-layer feedback; determining a physical sidelink shared channel (PSSCH) transmission directed to the group is not properly received by the vehicle-based UE; and transmitting a negative acknowledgment on the sidelink feedback resource based on said determination.

Example 17 includes the method of example 16 or some other example herein, wherein detecting the sidelink feedback resource comprises: detecting sidelink control information scheduling data from the transmitter.

Example 18 includes the method of example 16 or some other example herein, wherein PSSCH transmission is a first PSSCH transmission and the method further comprises: receiving and successfully decoding a second PSSCH transmission from the transmitter; detecting a negative acknowledgment, from another vehicle-based UE, with respect to the second PSSCH transmission; and transmitting the second PSSCH transmission to the other vehicle-based UE.

Example 19 includes the method of example 18 or some other example herein, further comprising: detecting a PSSCH resource reserved for re-transmission of the second PSSCH transmission; and transmitting the second PSSCH transmission on the PSSCH resource.

Example 20 includes a method of example 19 or some other example herein, further comprising detecting the PSSCH resource based on signaling from the transmitter or the other vehicle-based UE.

Example 21 may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1-20, or any other method or process described herein. Example 22 may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-20, or any other method or process described herein.

Example 23 may include an apparatus comprising logic, modules, and/or circuitry to perform one or more elements of a method described in or related to any of examples 1- 20, or any other method or process described herein.

Example 24 may include a method, technique, or process as described in or related to any of examples 1-20, or portions or parts thereof.

Example 25 may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-20, or portions thereof.

Example 26 may include a method of communicating in a wireless network as shown and described herein.

Example 27 may include a system for providing wireless communication as shown and described herein.

Example 28 may include a device for providing wireless communication as shown and described herein.

The description herein of illustrated implementations, including what is described in the Abstract, is not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed. While specific implementations and examples are described herein for illustrative purposes, a variety of alternate or equivalent embodiments or implementations calculated to achieve the same purposes may be made in light of the above detailed description, without departing from the scope of the present disclosure, as those skilled in the relevant art will recognize.

Claims

CLAIMS What is claimed is:

1. One or more computer-readable media having instructions that, when executed by one or more processors, cause a vehicle-based user equipment (UE) to:

receive configuration information from a network the configuration information to include an indication of sidelink control resources for vehicle-to-vehicle (V2V) communication, an indication of one or more physical sidelink control channel (PSCCH) formats to be transmitted or monitored by the vehicle-based UE, and an indication of one or more sidelink control information (SCI) formats to be transmitted or monitored by the vehicle- based UE; and

transmit or monitor for a PSCCH transmission that includes SCI based on the

configuration information.

2. The one or more computer-readable media of claim 1, wherein the indication of one or more PSCCH formats includes indications of a plurality of PSCCH formats, wherein individual PSCCH formats are associated with a respective number of sidelink control channel elements.

3. The one or more computer-readable media of claim 2, wherein the plurality of PSCCH formats includes a first PSCCH format associated with 1 sidelink control channel element; a second PSCCH format associated with 2 sidelink control channel elements; a third PSCCH format associated with 4 sidelink control channel elements; a fourth PSCCH format associated with 8 sidelink control channel elements; a fifth PSCCH format associated with 16 control channel elements; and a sixth PSCCH format associated with 32 control channel elements.

4. The one or more computer-readable media of claim 2, wherein the instructions, when executed, further cause the vehicle-based UE to:

select a PSCCH format from the plurality of PSCCH formats based on a distributed scheduling procedure, channel quality measurements, or a congestion-control procedure; and

transmit the PSCCH transmission with the selected PSCCH format.

5. The one or more computer-readable media of claim 4, wherein the instructions, when executed, further cause the vehicle-based UE to select the PSCCH format based on a network load determined from the congestion-control procedure.

6. The one or more computer-readable media of claim 1, wherein the configuration information includes a rule to map the PSCCH transmission to one or more sidelink control channel elements in a sidelink control resource set.

7. The one or more computer-readable media of claim 1, wherein the instructions, when executed, further cause the vehicle-based UE to:

determine a number of attempts to decode the PSCCH format based on the configuration information or a predefined configuration.

8. The one or more computer-readable media of claim 1, wherein the instructions, when executed, further cause the vehicle-based UE to:

determine, based on the configuration information, a first set of control resources available to all UEs of a network; and

determine a second set of control resources available to a subset of the UEs of the network.

9. The one or more computer-readable media of claim 1, wherein the instructions, when executed, further cause the vehicle-based UE to:

determine, based on configuration information or a distributed scheduling decision, a PSCCH and physical sidelink shared channel (PSSCH) multiplexing scheme.

10. The one or more computer-readable media of claim 9, wherein the PSCCH and PSSCH multiplexing scheme is at a sub-slot level with the PSCCH and the PSSCH time division multiplexed in a same slot; at a slot level with the PSCCH and PSSCH frequency division multiplexed in a same slot; at a slot level with the PSCCH and the PSSCH time division multiplexed in different slots; or at a sub-slot level with the PSCCH and the PSSCH time division multiplexed in different slots.

11. An apparatus to be employed in a vehicle-based user equipment (UE), the apparatus comprising:

memory to store configuration information to indicate sidelink control resources for vehicle-to-vehicle (V2V) communication, one or more physical sidelink control channel (PSCCH) formats to be transmitted or monitored by the vehicle-based UE, and a mapping rule for mapping a PSCCH transmission to plurality of sidelink control channel elements that are frequency division multiplexed or time division multiplexed with a contiguous allocation property; and

processing circuitry to cause the PSCCH transmission to be transmitted on the plurality of sidelink control channel elements or monitor the plurality of sidelink control channel elements for the PSCCH transmission based on the configuration information.

12. The apparatus of claim 11, wherein the plurality of sidelink control channel elements comprise 12 resource elements in a frequency domain and three symbols in a time domain.

13. The apparatus of claim 11, wherein the PSCCH transmission comprises preemption sidelink control information to indicate time and frequency resources to be released by one or more UEs.

14. The apparatus of claim 13, wherein the processing circuitry is further to detect the preemption sidelink control information; determine an overlapped schedule with respect to a transmission scheduled in the time and frequency resources; and perform a resource reselection for the transmission based on the determination of the overlapped schedule and the preemption sidelink control information.

15. The one or more computer-readable media of claim 13, wherein the preemption sidelink control information includes an indication of a priority level value and the processing circuitry is further to:

determine an overlapped schedule with respect to a transmission scheduled in the time and frequency resources, the transmission to include an associated transmission priority;

compare the transmission priority to the priority level value; and determine whether to release the time and frequency resources based on the comparison of the transmission priority to the priority level value.

16. One or more computer-readable media having instructions that, when executed by one or more processors, cause a vehicle-based user equipment (UE) to:

detect a sidelink feedback resource reserved by transmitter for one or more UEs of a group to provide radio-layer feedback;

determine a physical sidelink shared channel (PSSCH) transmission directed to the group is not properly received by the vehicle-based UE; and

transmit a negative acknowledgment on the sidelink feedback resource based on said determination.

17. The one or more computer-readable media of claim 16, wherein to detect the sidelink feedback resource, the vehicle-based UE is to:

detect sidelink control information scheduling data from the transmitter.

18. The one or more computer-readable media of claim 16, wherein PSSCH transmission is a first PSSCH transmission and the instructions, when executed, further cause the vehicle-based UE to:

receive and successfully decode a second PSSCH transmission from the transmitter; detect a negative acknowledgment, from another vehicle-based UE, with respect to the second PSSCH transmission; and

transmit the second PSSCH transmission to the other vehicle-based UE.

19. The one or more computer-readable media of claim 18, wherein the instructions, when executed, further cause the vehicle-based UE to: detect a PSSCH resource reserved for re transmission of the second PSSCH transmission; and transmit the second PSSCH transmission on the PSSCH resource.

20. The one or more computer-readable media of claim 19, wherein the instructions, when executed, further cause the vehicle-based UE to detect the PSSCH resource based on signaling from the transmitter or the other vehicle-based UE.