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

Abstract

Embodiments of the present disclosure describe methods and apparatus for receiving configuration information from a network and sending or monitoring PSCCH transmissions including SCIs based on the configuration information, the configuration information including: an indication of sidelink control resources to be used for V2V communications, an indication of one or more PSCCH formats to be transmitted or monitored by an in-vehicle UE, and an indication of one or more SCI formats to be transmitted or monitored by the in-vehicle UE.

Description

Control signaling for new radio vehicle-to-vehicle communication

RELATED APPLICATIONS

This application claims priority to U.S. provisional application No. 62/717,177 filed on 8/10/2018. The specification of said application is incorporated herein by reference in its entirety.

Technical Field

Embodiments of the present disclosure relate generally to the field of wireless communications, and more particularly, to an apparatus, system, and method for control signaling in vehicle-to-vehicle communications.

Background

Release 16 of the third generation partnership project ("3 GPP") new radio ("NR") specification provides a physical layer and protocols to support advanced vehicle-to-everything (V2X) use cases such as sensor sharing, autonomous driving, and remote driving, among others. Releases 14 and 15 of the 3GPP Long Term Evolution (LTE) specifications emphasize basic security features. In contrast, the goal of NR V2X is a very diverse set of use cases and associated requirements.

Drawings

The embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals refer to like structural elements. In the drawings of the accompanying drawings, embodiments are shown by way of example and not limitation.

Fig. 1 illustrates a network, according to some embodiments.

Figure 2 illustrates different PSCCH formats, according to some embodiments.

Fig. 3 illustrates a frequency division multiplexing option in accordance with some embodiments.

Fig. 4 illustrates a time division multiplexing option, according to some embodiments.

Fig. 5 illustrates a sidelink control channel element format (sidelink control channel element format), according to some embodiments.

Fig. 6 illustrates multiplexing options supported in accordance with some embodiments.

Fig. 7 illustrates an example operational flow/algorithm structure, according to some embodiments.

Fig. 8 illustrates an example operational flow/algorithm structure, according to some embodiments.

FIG. 9 illustrates an electronic device, in accordance with some embodiments.

Fig. 7 illustrates a baseband circuit, in accordance with some embodiments.

Fig. 8 illustrates a communication circuit, according to some embodiments.

FIG. 9 illustrates an electronic device, in accordance with some embodiments.

FIG. 10 illustrates circuitry of an electronic device, in accordance with some embodiments.

Fig. 11 illustrates an interface of a baseband circuit, according to some embodiments.

FIG. 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 which 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, the operations may be performed out of the order presented. The operations described may be performed in a different order than the described embodiments. In additional embodiments, various additional operations may be performed or the operations described may be omitted.

The description may use the phrases "in one embodiment" or "in an embodiment," 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 this disclosure, the phrases "a or B", "a and/or B", and "a/B" mean (a), (B), or (a and B).

Fig. 1 illustrates a network 100 according to some embodiments. The network 100 may be designed to facilitate communications with vehicle-mounted (vehicle-based) User Equipment (UE). The network 100 may include a first in-vehicle UE 104, a second in-vehicle UE 108, a base station 112, a human-based UE 116, and an infrastructure-based UE 120. In some embodiments, network 100 may be a 5G/NR compatible network.

Network 100 may be referred to as a vehicle-to-everything (V2X) network that facilitates communication between each device of network 100. The network 100 may provide vehicle-to-vehicle (V2V) communication (e.g., between the in-vehicle UE 104 and the in-vehicle UE 108), vehicle-to-infrastructure (V2I) communication (e.g., between the in-vehicle UE 108 and the infrastructure-based UE 120), vehicle-to-network (V2N) communication (e.g., between the in-vehicle UE 108 and the base station 112), and vehicle-to-pedestrian (V2P) communication (e.g., between the in-vehicle UE 108 and the user-based UE 116).

A user-based UE 116, as used herein, may be a UE designed to be carried by a user. The user-based UE 116 may be a smartphone or a wearable device (e.g., a smart watch, a fitness tracker, smart glasses, etc.).

As used herein, a vehicular UE may be a UE configured to provide V2X communication from a vehicle. Typically, in-vehicle UEs are permanently installed in the vehicle; however, in other embodiments, the in-vehicle UE may be mobile.

Infrastructure-based UE 120 may also be referred to as a roadside unit (RSU), which may refer to any transport infrastructure entity for V2X communication. The infrastructure-based UE 120 may be implemented in or by an appropriate radio access node or stationary (or relatively stationary) UE. In one example, infrastructure-based UE 120 may be a computing device coupled with radio frequency circuitry located at the roadside that provides connection support for passing vehicles (e.g., in-vehicle UE 108 and in-vehicle UE 104). The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications/software for sensing and controlling continuous vehicle and pedestrian traffic. The computing devices of the infrastructure-based UE 120 and some or all of their radio frequency circuitry 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 backhaul network.

The various use cases and requirement sets associated with NR V2X motivate flexible and reconfigurable side link physical layer designs. This may facilitate high data rate best effort traffic and ultra-low latency with 1ms latency and 10 in different coverage areas^-5Reliable transmission of reliability.

The desired radio interface flexibility may be supported in view of the extreme requirements on delay and reliability. Although the reliability and delay of shared channel transmission may have been achieved over a wide range due to the dynamic indication of parameters in Sidelink Control Indication (SCI), the flexibility of the control transmission itself may be a key design point for sidelink-based NR V2X.

Furthermore, in addition to link performance and configurability, potential system-level design components (e.g., channel access) may be required to support new functionality that provides different latency and reliability.

For example, previous sidelink designs for V2V communication from 3GPP LTE releases 14 and 15 have been optimized for broadcast basic security traffic. Thus, its applicability to the NR-advanced V2X use case is very limited. The limitations of LTE release 14/15 sidelink design for V2V communication mainly come from broadcast-centric physical layer design and fixed control/data transport formats. This will result in inefficient support for use cases requiring substantially different delays and reliability (as required by advanced V2X).

Embodiments herein provide mechanisms and components for sidelink communications for different use cases and targets. Embodiments include a unified physical control channel design; multiplexing of physical control and data channels; a sidelink preemption indication; and group retransmission and feedback mechanisms.

Link level assembly for reliable low latency transmission

First, the design of NR V2V communications may allow link performance to achieve various reliability and latency goals identified for a given scenario and traffic pattern/data rate. In this regard, the following design principles may be followed.

Sufficient flexibility in terms of all diversity (diversity) sources that utilize both control and data physical channels:

time diversity, e.g., transmission allocated over a delay budget;

frequency diversity, e.g., frequency hopping or distributed resource allocation;

interference/collision diversity, e.g., randomization of interference and collisions, including co-channel interference, in-band emission (IBE), out-of-band emission (OOB), half-duplex (HD);

omicron spatial differential diversity, e.g., transmit diversity mode with MIMO scheme; and

spatial macro-diversity, e.g., replication at the PDCP layer and transmission on multiple component carriers.

Sufficient flexibility in terms of achievable channel access delay and transmission duration.

With sufficient flexibility in terms of achievable spectral efficiency, supporting low spectral efficiency:

omicron physical side link control channel (PSCCH)

A mechanism to achieve variable redundancy per information bit by sending SCI and/or changing the operational SCI payload size over a configured number of PSCCH resources; and

omicron physical side link shared channel (PSSCH)

Supporting MCS tables designed for different BLER targets, e.g., 10% and 0.001%, and

flexibly configurable repetition for the PSSCH.

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

As used herein, configuration of aspects of the control channel may include the base station generating and sending a configuration message (e.g., a Radio Resource Control (RRC) configuration message) to the UE, or may include a pre-configuration by programming a device that is consistent with an established specification (e.g., the 3G PPA technical specification).

Physical side link control channel design

The side link 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 can be assumed that any type of sidelink control information can be carried by the Physical Sidelink Control Channel (PSCCH). Furthermore, in the present invention, it is assumed that the described PSCCH design principles can be applied to any type of sidelink control information.

As discussed above, it may be desirable for both the control and shared channel transport formats to be flexible enough to support various sets of reliability and delay objectives. Unlike the case where a single PSCCH format is applied in release 14LTE V2V communications, in NR the PSCCH may be designed to support more PSCCH formats with different spectral efficiencies, e.g. redundancy for each information bit of the SCI transmission.

To achieve different redundancy for each information bit, the following general approach can be considered:

a variable number of control resource elements (control resource elements); and

variable payload size.

A variable number of control resource units may be provided as follows.

In 3GPP cellular systems, such as NR and LTE, a variable number of downlink control resource elements may be implemented by different PDCCH formats, represented as different levels of aggregation of Control Channel Elements (CCEs), which may include the same or different numbers of Resource Element Groups (REGs), depending on the PDCCH format. In the design of the side link physical control channel of NR, similar concepts can be used in consideration of the details of side link communication and the side link physical structure.

In this case, a sidelink control channel element (SL-CCE) or simply a sidelink control resource may be introduced as the minimum granularity of PSCCH resource allocation. Also, for example, different PSCCH physical formats may be defined depending on the number of SL-CCEs shown in table 1.

Table 1: NR PSCCH Format

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

Both the transmitting UE and the receiving UE need to know the number of SL-CCEs used to transmit the PSCCH for proper receive processing. For this purpose, both the transmitting/receiving UEs may define and know the rules and restrictions on how to map the PSCCH format to an N _ (SL-CCE) SL-CCE.

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

Figure 2 illustrates different PSCCH formats, according to some embodiments. Structure 204 shows numerology and slot format, with a 30kHz slot and 14 symbols in the case of a conventional Cyclic Prefix (CP). The symbol of the diamond hash mark may represent the first symbol of the slot.

Structure 208 shows a slot with sidelinks CORESET and pscsch in accordance with some embodiments.

If the UE is configured with PSCCH format 0 (one SL-CCE per SCI format transmission as shown in table 1), the CORESET may be divided into separate non-overlapping candidates for PSCCH decoding, as shown on the left side of structure 208. The PSCCH SL core set 212 consists here of two consecutive SL-CCEs in time and four adjacent SL-CCEs in frequency in a slot. There are a total of 8 candidates for decoding PSCCH format 0: c1-0, C1-1 and C1-7. If the UE is configured with psch format 1 (two SL-CCEs per SCI format transmission according to table 1) and no frequency hopping is desired (as discussed below), the paired CCEs of SL core set 212 may be merged according to their shadow filling; however, in other embodiments, other pairs may be used (as discussed further below).

If the UE is configured with PSCCH format 1 (two SL-CCEs per SCI format transmission according to table 1), it may be beneficial to define non-overlapping candidates to reduce blind decoding effort from the UE. In addition, due to power limitations at the UE and the principles of maximum coverage for control signaling transmissions, it may be desirable to limit the composition of PSCCH transmissions from SL-CCEs of different time resources. In this case, there may be no power sharing between SL-CCEs and, therefore, no coverage penalty from increased aggregation levels. An example candidate for mapping for PSCCH format 1 is shown on the right side of fig. 2 as SL core set 216. SL core set 216 includes pairs of SL-CCEs that are composed of separate candidates with frequency offsets known to the receiving UE. This may enable a desired level of frequency diversity to be achieved for the entire SCI transmission. There may be a total of four PSCCH format 1 candidates: c2-0, C2-1, C2-2 and C2-3.

It should be noted that the candidates for different PSCCH formats may overlap. For example, each candidate of PSCCH format 1 may comprise two candidates of PSCCH format 2. In FIG. 2, it can be seen that candidate C2-0 may include two candidates C1-0 and C1-6, candidate C2-1 may include candidates C1-1 and C1-7, and so on.

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

The transmitting UE behavior for transmitting the PSCCH may be as follows. The transmitting UE may select PSCCH candidates for SCI transmission based on grants from the gNB or based on a distributed scheduling procedure. The distributed scheduling procedure may be performed by the transmitting UE and may take into account channel sensing and measurements, priorities, and other aspects. The selected PSCCH candidate may fall within the space of candidates to be monitored by the intended recipient.

The receiving UE behavior for receiving the PSCCH may be as follows. To keep the receive processing complexity manageable, the maximum number of candidates for PSCCH decoding may be fixed and known to the UE. In this case, the UE may be configured to monitor a given PSCCH format for a given number of attempts/blind decodes. Rules may also be defined how different SL-CCEs are merged into candidates.

In some embodiments, a total number of channel estimates "X" per PSCCH CORESET monitoring occasion or per time slot may be defined. In this case, it may not be desirable for the UE to be configured with PSCCH formats and with a number of candidates that results in the number of channel estimates exceeding the total defined number. In the event that the configuration exceeds "X", the UE may apply a priority rule to identify candidates to check and discard other candidates that exceed the channel estimation attempt budget.

Furthermore, the total number "Y" of blind decoding attempts over all configured PSCCH formats in a CORESET monitoring occasion or time slot may be predefined in the 3GPP technical specification. It may not be desirable for the UE to be configured with PSCCH formats and with a number of candidates that results in a number of blind decoding attempts that exceeds the total defined number. In the event that the configuration exceeds "Y", the UE may apply a priority rule to identify candidates to check and discard other candidates that exceed the blind decoding budget.

In one example, the resources in the sidelink CORESET may be divided into "common" resources that can be semi-statically configured by the network, and "custom" (UE-specific/group-specific/link-specific) resources that can be established during unicast/multicast communications and are known only to UEs in the intended group. The common resources and the customized resources may overlap or be multiplexed such that the total blind decoding effort of the UE does not exceed "X" and "Y" as defined above.

Variable payload size

A trade-off may be required between scheduling flexibility and the amount of dynamic and semi-static signaling required to support such flexibility. In addition, due to fundamental limitations, the larger the size of the control signaling payload, the worse the coverage and reliability. In order to support all the various requirements and use cases of NR V2X communication, it may be desirable to provide control signaling with variable payload sizes for the sidelinks so that the appropriate combination of flexibility and reliability can be configured/selected in a particular situation.

In one embodiment, the UE may be configured to transmit or monitor one or more SCI formats with the same or different payload sizes. In this case, blind decoding in the same resource assuming different payload sizes may be calculated separately to achieve a blind decoding assumption budget "Y". It may not be expected that the UE is configured with more than, for example, 2-4 different sizes in the same CORESET for blind decoding.

Multiplexing of PSCCH and PSSCH

Different multiplexing options for control (PSCCH) and data (PSCCH) may also provide different delay and reliability tradeoffs. For example, control and data transmitted in the same Transmission Time Interval (TTI) multiplexed in the frequency domain may provide the lowest transmission delay and duration, but may also experience shared power between PSCCH and PSCCH, and thus coverage for both protocols is penalized. On the other hand, if PSCCH and PSCCH are transmitted at different times, they may not share power and DFT-s-OFDM waveform properties may be reserved, thereby increasing coverage for both control and data. This may consume more resources in the time domain and thus lead to slightly increased transmission delays, congestion and half-duplex problems.

For the NR V2X design, a flexible resource allocation design paradigm can be used to accommodate all of the above multiplexing examples. In this section, the required control and data channel multiplexing options will be described one by one, followed by a general signaling and UE behavior approach.

First, NR V2X may support the release 14 option, where PSCCH and PSCCH are multiplexed in the same TTI, either adjacent or non-adjacent. As shown in fig. 3, fig. 3 illustrates a Frequency Division Multiplexing (FDM) option for PSCCH and PSCCH multiplexing, which PSCCH SL core set may be distributed over the system bandwidth so that data and control may be multiplexed in frequency in the same time unit (e.g., a slot, multiple slots, or a portion of a slot) in the case of transmission, in accordance with some embodiments. It is noted that in general, from the UE perspective, control and data can still be sent in a Time Division Multiplexed (TDM) fashion at different times, where the time interval between control and data can be predefined or signaled in the SCI.

In another embodiment, the PSCCH and PSCCH may be TDM within one time slot or different time slots by a particular PSCCH CORESET configuration. In addition to the example of fig. 2 of multiplexing PSCCH and PSCCH in the same slot, the multiplexing option may also be similar to structures 404 and 408 of fig. 4, which illustrate TDM options for PSCCH and PSCCH multiplexing at the slot level, according to some embodiments. As shown in fig. 4, one time slot may be dedicated for control signaling, while one or more separate time slots may be dedicated for shared channel transmission. Here, it is important to note that the channel access instance may still be configured differently. Structure 404 may include channel access symbols 412, 416, 420, and 424, which may be used to perform channel access (e.g., listen before talk) separately for each resource carrying control or data. On the other hand, structure 408 may include only one channel access symbol 428 and 432 per multiple slots, for example for control and shared channels.

To accommodate all the described multiplexing options in the NR V2X communications framework, a resource structure may be defined that is configurable from both a system perspective and a UE perspective.

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

In the configured PSCCH resource pool, PSCCH resources may be mapped to SL-CCEs. The symbol-unit SL-CCE duration and PRB or RE-unit bandwidth may be configured within a predefined range or may be a single fixed value.

For example, one SL-CCE may have a duration indicated by a set of from 1 to 14 symbols, including potential differences and Automatic Gain Control (AGC) symbols. However, such flexibility may not be useful and may complicate UE implementation and system design, so a small subset may be defined. In some embodiments, at least a full time slot allocation may be included in the set, e.g., 14 symbols for Normal Cyclic Prefix (NCP) and 12 symbols for Extended Cyclic Prefix (ECP). In addition, at least several sub-slot durations may be required to achieve a similar TDM case of PSCCH and PSCCH within a slot as shown in fig. 2. Thus, an aggregation of SL-CCEs in the time domain as shown in fig. 5 may be defined according to some embodiments.

Fig. 5 illustrates a SL-CCE format, according to some embodiments. Structure 504 shows an example of SL-CCE formats with different durations. These durations may allow multiplexing control and data for delay-critical services in the same slot, or multiplexing multiple SL-CCEs in a slot. The SL-CCE bandwidth may comprise at least 1, 2 PRBs to support a physical structure like release 14. The SL-CCE bandwidth may simultaneously be a function of the duration. For example, in the case of a full slot SL-CCE duration, it may be a relatively small value of 1-2 PRBs, while in the case of a sub-slot duration, it may grow to 4-6 PRBs.

Structure 508 illustrates an example of SL-CCE formats with different occupied bandwidths and durations, according to some embodiments. With these structures, a single SL-CCE bandwidth (e.g., 1 PRB) may be defined and aggregation of SL-CCEs in the frequency domain may be employed.

Once the size of the control channel is defined and known to both the transmitting and receiving UEs, the transmitting UE may follow a distributed or gNB/eNB controlled scheduling pattern to transmit control and data according to configured/selected multiplexing options. The multiplexing option may be specific to a particular scheduling decision and may be UE specific. Thus, the control information may be agnostic to the receiving UE before it is decoded.

Fig. 6 illustrates multiplexing options of PSCCH and PSCCH that may be supported from the perspective of a TX UE, according to some embodiments.

In option 1, TDM is performed on the sub-slot level PSCCH/PSCCH in the same slot. This option may provide a fixed link budget (similar reliability on the UE) for control channel transmission, reduce the number of sidelink channel access attempts required for transmission of control and shared channels, and provide latency benefits for control channel processing. However, this option may have limited control channel capacity (frequency reuse of low order).

In option 2, the slot level PSCCH/PSCCH is FDM in the same slot. This option may reduce the number of sidelink channel access attempts required for control and shared channel transmission, provide sufficient control channel capacity (frequency reuse), and provide a common sensing procedure for control channel transmission and shared channel transmission. However, this option may have a delay in the control channel processing, and the power of the control channel may be shared with the shared channel.

In option 3, the slot levels PSCCH and PSCCH are TDM in different slots. This option can provide the maximum energy per control and shared channel transmission (required for high reliability) and provide sufficient control channel capacity. However, this option may have a delay in control channel processing, and both control and shared channels may require resource selection.

In option 4, the sub-slot level PSCCH/PSCCH is TDM in different slots. This option may provide a fixed link budget (similar reliability on the UE) for control channel transmission and delay benefits for control channel processing. However, this option may have limited control channel capacity (frequency reuse of low order), both control and shared channels may require resource selection, and sub-slot level transmission only for PSCCH may include additional AGC considerations.

System level assembly

To provide collision-free communication in certain special cases (e.g., for transmission of urgent data), a resource preemption mechanism may be defined for NR V2X sidelink communication.

In one example, PSCCH transmissions may convey a "preemptive" SCI format (P-SCI) that indicates future time and frequency resources and their time scheduling. These UEs will release (e.g., drop or rate match or puncture) these resources when detected by other UEs. Alternatively, when detected by other UEs, these UEs will release all resources that overlap in time with the indicated resources. In some cases, detecting a P-SCI with overlapping resources at a particular UE may trigger resource reselection.

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

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

Another potential enhancement related to reliable V2V communication is the introduction of physical layer feedback and retransmissions. This behavior may typically be part of a unicast communication. However, in the case of multicast communications (e.g., queued use cases), the feedback may not be easily organized due to the multiple recipients.

In one example relating to multicast communications, the following radio layer enhancements may be used to improve sidelink communications performance in a distributed resource allocation mode.

Group radio layer feedback

When the UE's transmitter transmits a sidelink transmission/message to the group, a UE that has received the PSCCH but has not received the PSCCH (e.g., should have received but not received the PSCCH) may transmit a Negative Acknowledgement (NACK) on resources reserved by the transmitter for acknowledgement. The reserved resources for the NACK may be indicated in SCI scheduling data from the transmitting UEs in the group.

Group radio layer (retransmission)

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

Fig. 7 illustrates an operational flow/algorithm structure 700, according to some embodiments. The operational flow/algorithm structure 700 may be performed by the in-vehicle UE or a component thereof. For example, the operational flow/algorithm structure 700 may be performed by the in-vehicle UE 104 or the in-vehicle UE 108 described above with respect to fig. 1.

The operational flow/algorithm structure 700 may include receiving configuration information from a network at 704. In some embodiments, the in-vehicle UE may receive configuration information from a base station (e.g., base station 112) through configuration parameters or information elements included in RRC signaling. The configuration information includes: an indication of sidelink control resources to be used for V2V communication, an indication of one or more PSCCH formats to be transmitted or monitored by the in-vehicle UE, and an indication of one or more SCI formats to be transmitted or monitored by the in-vehicle UE.

In some embodiments, the indication of the one or more PSCCH formats may comprise an indication of a plurality of PSCCH formats, wherein each PSCCH format is associated with a corresponding number of sidelink control channel elements. The association may be similar to the association described above with respect to table 1.

In some embodiments, the in-vehicle UE may select a particular PSCCH format from the available PSCCH formats based on various operations or processes 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 congestion control procedures (or network load determined therefrom). Once selected, the in-vehicle UE may generate and transmit a PSCCH transmission having the selected PSCCH format.

The operational flow/algorithm structure 700 may also include: at 708, PSCCH transmissions including SCIs are sent or monitored based on the configuration information. The sending or monitoring of PSCCH transmissions may be done based on configuration information. For example, the vehicular UE may determine the PSCCH format and then determine which SL-CCEs will carry the corresponding PSCCH transmission. The in-vehicle UE may then monitor the candidate SL-CCEs or select a candidate SL-CCE over which the PSCCH is to be encoded.

Fig. 8 illustrates an operational flow/algorithm structure 800, according to some embodiments. The operational flow/algorithm structure 800 may be performed by the in-vehicle UE or a component thereof. For example, the operational flow/algorithm structure 800 may be performed by the in-vehicle UE 104 or the in-vehicle UE 108 described above with respect to fig. 1.

The operational flow/algorithm structure 800 may include: at 804, sidelink feedback resources reserved by the transmitter for one or more UEs in the group for providing radio layer feedback are detected. In some embodiments, the resource may be a Physical Sidelink Feedback Channel (PSFCH) resource.

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

The operational flow/algorithm structure 800 may also include: at 808, it is determined that the in-vehicle UE did not correctly receive the PSSCH transmission for the group. In some embodiments, the in-vehicle UE may determine from the side link control information that a psch transmission is to be sent to a group of which the in-vehicle UE is a member. If the in-vehicle UE subsequently fails to correctly decode (partially or fully) the scheduled transmission, the UE may determine that the PSSCH transmission was not correctly received.

The operational flow/algorithm structure 800 may also include, at 812, transmitting a NACK over the reserved sidelink feedback resources based on the determination at 808.

Fig. 9 illustrates an example of a platform 900 (or "device 900"), in accordance with various embodiments. In embodiments, computer platform 900 may be suitable for use as any UE of fig. 1 or any other element/device discussed herein. Platform 900 may include any combination of the components shown in the examples. The components of platform 900 may be implemented as an Integrated Circuit (IC), a portion thereof, a discrete electronic device or other module, logic, hardware, software, firmware, or a combination thereof suitable for use in computer platform 900, or as components otherwise incorporated in the chassis (chassis) of a larger system. The block diagram of fig. 9 is intended to illustrate a high-level view of the components of computer platform 900. However, some of the illustrated components may be omitted, additional components may be present, and a different arrangement of components may occur in other implementations.

The application circuitry 905 may include circuitry such as, but not limited to, a single-core or multi-core processor and one or more of the following: a cache memory, a low dropout regulator (LDO), an interrupt controller, a serial interface such as a Serial Peripheral Interface (SPI), an inter-integrated circuit (I2C) or a universal programmable serial interface circuit, a Real Time Clock (RTC), a timer including an interval timer and a watchdog timer, a universal input/output (IO), a memory card controller such as a secure digital/multimedia card (SD/MMC) or the like, a Universal Serial Bus (USB) interface, a Mobile Industry Processor Interface (MIPI) interface, and a Joint Test Access Group (JTAG) test access port. The processor may include any combination of general purpose processors and/or special purpose processors (e.g., graphics processors, application processors, etc.). The processor (or core) 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, the processor of the application circuit 905 may process IP data packets received from the EPC or 5 GC.

The application circuit 905 may be or include a microprocessor, multicore processor, multithreaded processor, ultra low voltage processor, embedded processor, or other known processing element. In one example, the application circuitry 905 can include a microprocessor based

Frame Core (Core)^TMProcessors, e.g. Quark^TM、Atom^TMI3, i5, i7 or MCU grade processors, or may be available from santa clara, california

Another such processor available from companies. The processor of the application circuit 905 may also be one or more of: high-grade mini equipment (AMD)

Processors or acceleratorsA Processing Unit (APU); from

Company A5-A9 processor from

Snapdagon of science and technology^TMProcessor, Texas Instruments (Texas Instruments)

Open type multimedia application platform (OMAP)^TMA processor; MIPS-based designs from MIPS technologies corporation; ARM-based designs, as authorized by ARM holdings llc, and the like. In some embodiments, the application circuit 905 may be part of a system on a chip (SoC), where the application circuit 905 and other components are formed as a single integrated circuit or a single package, such as Edison from intel corporation^TMOr Galileo^TMA system-on-chip motherboard.

Additionally or alternatively, the application circuitry 905 may include circuitry such as, but not limited to, one or more of the following: field Programmable Devices (FPDs), such as FPGAs and the like; programmable Logic Devices (PLDs), such as complex PLDs (cplds), large capacity PLDs (hcplds), and the like; ASICs, such as structured ASICs and the like; programmable soc (psoc), etc. In such embodiments, the circuitry of the application circuitry 905 may include logic blocks or logic structures, as well as other interconnected resources that may be programmed to perform various functions (e.g., the processes, methods, functions, etc., of the various embodiments discussed herein). In such embodiments, the circuitry of the application circuit 905 may include storage units (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), antifuse, etc.) for storing logic blocks, logic structures, data, and so forth in a look-up table (LUT) and so forth).

Baseband circuitry 910 may be implemented, for example, as a solder 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 include one or more digital baseband systems, which may be coupled to a CPU subsystem, an audio subsystem, and an interface subsystem via an interconnect subsystem. The digital baseband subsystem may also be coupled to the digital baseband interface and the mixed signal baseband subsystem via another interconnection subsystem. Each interconnect subsystem may include a bus system, point-to-point connections, a Network On Chip (NOC) fabric, 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 similar components. In one aspect of the disclosure, the baseband circuitry 910 may include protocol processing circuitry with one or more instances of control circuitry (not shown) to provide control functions for digital baseband circuitry and/or radio frequency circuitry (e.g., radio front end module 915).

As used herein, the term "circuitry" may refer to, be part of, or include hardware components configured to provide the described functionality, such as: electronic circuits, logic circuits, processors (shared, dedicated, or group) and/or memory (shared, dedicated, or group), Application Specific Integrated Circuits (ASICs), Field Programmable Devices (FPDs) (e.g., Field Programmable Gate Arrays (FPGAs), Programmable Logic Devices (PLDs), complex PLDs (cplds), high capacity PLDs (hcplds), structured ASICs, or programmable systems on a chip (socs)), Digital Signal Processors (DSPs), and the like. In some embodiments, 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 circuitry used in an electrical or electronic system) and program code for performing the functions of the 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 with "processor circuitry" and may be referred to as "processor circuitry". As used herein, the term "processor circuit" may refer to, be part of, or include the following circuitry: circuits capable of performing a series of arithmetic or logical operations, or recording, storing and/or communicating digital data, sequentially and automatically. The term "processor circuit" may refer to one or more application processors, one or more baseband processors, physical Central Processing Units (CPUs), single-core processors, dual-core processors, tri-core processors, quad-core processors, and/or any other device capable of executing or otherwise operating computer-executable instructions (e.g., program code, software modules, and/or functional processes).

The Radio Front End Module (RFEM)915 may include 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 separate from the millimeter wave RFEM. The RFIC may include a connection to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative embodiments, both millimeter-wave and sub-millimeter-wave radio functions may be implemented in the same physical radio front end module 915. RFEM 915 may incorporate both millimeter wave and sub-millimeter wave antennas.

The memory circuit 920 may include any number and type of memory devices for providing a given amount of system memory. As an example, memory circuitry 920 may include one or more of the following: volatile memory, including Random Access Memory (RAM), dynamic RAM (dram), and/or synchronous dynamic RAM (sdram), and non-volatile 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), and the like. The memory circuit 920 may be developed according to a design based on Joint Electronic Device Engineering Council (JEDEC) Low Power Double Data Rate (LPDDR), such as LPDDR2, LPDDR3, LPDDR4, and the like. The memory circuit 920 may be implemented asOne or more of the following: a solder down(s) packaged integrated circuit, a Single Die Package (SDP), a Dual Die Package (DDP), or a quad die package (Q17P), a socket memory module, a dual in-line memory module (DIMM) including a micro DIMM or a MiniDIMM, and/or soldered to a motherboard via a Ball Grid Array (BGA). In a low power implementation, memory circuit 920 may be an on-die memory or a register associated with application circuit 905. To provide persistent storage of information such as data, applications, operating systems, etc., the memory circuit 920 may include one or more storage devices of sufficient capacity, which may include Solid State Disk Drives (SSDDs), Hard Disk Drives (HDDs), micro HDDs, resistance change memory, phase change memory, holographic or chemical memory, etc. For example, computer platform 900 may incorporate information from

And

three-dimensional (3D) cross point (XPO1NT) memory.

Removable memory circuit 923 may comprise devices, circuitry, enclosures/housings, ports or sockets, and the like, for coupling a portable data storage device with 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 image cards, etc.) as well as USB flash drives, optical disks, external HDDs, and the like.

The platform 900 may also include interface circuitry (not shown) for interfacing external devices with the platform 900. External devices connected to platform 900 via interface circuitry may include sensors 921, such as accelerometers, liquid level sensors, flow sensors, temperature sensors, pressure sensors, barometric pressure sensors, and the like. Interface circuitry may be used to connect platform 900 to electro-mechanical components (EMC)922, which may allow platform 900 to change its state, position, and/or orientation, or to move or control a mechanism or system. The EMC 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.), sound generators, visual warning devices, motors (e.g., dc motors, stepper motors, etc.), wheels, propellers, claws, clamps, hooks, and/or other similar electromechanical components. In embodiments, the 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, interface circuitry may connect the platform 900 with the positioning circuitry 945, which positioning circuitry 945 may be the same as or similar to 945 positioning circuitry discussed with respect to fig. 9.

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

The driver circuitry 946 may include software and hardware elements for controlling particular devices 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 that allow other components of the platform 900 to interact with or control various input/output (I/O) devices that may be present in the platform 900 or connected to the platform 900. For example, driver circuit 946 may include: a display driver to control and allow access to the display device, a touch screen driver to control and allow access to the touch screen interface of platform 900, a sensor driver to acquire sensor readings of sensor 921 and control and allow access to sensor 921, an EMC driver to acquire actuator position of EMC 922 and/or control and allow access to EMC 922, a camera driver to control and allow access to the embedded image capture device, an audio driver to control and allow access to one or more audio devices.

A Power Management Integrated Circuit (PMIC)925 (also referred to as "power management circuit 925") may manage power provided to various components of platform 900. In particular, for the baseband circuit 910, the PMIC 925 may control power supply selection, voltage scaling, battery charging, or DC-DC conversion. The PMIC 925 may typically be included when the platform 900 is capable of being powered by the battery 930, for example, when the device is included in a UE XQ01, 10XQ02, XR 101.

In some embodiments, PMIC 925 may control or otherwise be part of various power saving mechanisms of platform 900. For example, if platform 900 is in RRC _ Connected state, it is still Connected to the RAN node as long as it expects to receive traffic for a short time, and then it may enter a state called discontinuous reception mode (DRX) after a period of inactivity. During this state, the platform 900 may be powered down for a short time interval, thereby conserving power. If there is no data traffic activity for an extended period of time, platform 900 may transition to an RRC _ Idle state where it is disconnected from the network and does not perform operations such as channel quality feedback, handovers, etc. The platform 900 enters a very low power consumption state and it performs a page during which it wakes up again periodically to listen to the network and then powers down again. In this state, platform 900 may not receive data; to receive data, it must transition back to the RRC _ Connected state. The additional power-save mode may allow the device to be unavailable to use the network for a period of time that exceeds the paging interval (which may vary from a few seconds to a few hours). During this time, the device is completely inaccessible to the network and may be completely powered down. Any data sent at this time will cause a large delay and it is assumed that the delay is acceptable.

Battery 930 may provide power to platform 900, although in some examples, platform 900 may be installed deployed in a fixed location and may have a power source coupled to a power 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, or the like. In some embodiments, such as in a V2X application, the battery 930 may be a typical lead-acid automotive battery.

In some embodiments, the battery 930 may be a "smart battery" that includes or is coupled to a Battery Management System (BMS) or a battery monitoring integrated circuit. The BMS may be included in the platform 900 to track the state of charge (SoCh) of the battery 930. The BMS may be used to monitor other parameters of the battery 930 to provide fault predictions, such as the state of health (SoH) and the functional state (SoF) of the battery 930. The BMS may communicate information of the battery 930 to the application circuitry 905 or other components of the platform 900. The BMS may also include an analog-to-digital (ADC) converter that allows the application circuit 905 to directly monitor the voltage of the battery 930 or the current from the battery 930. The battery parameters may be used to determine actions that platform 900 may perform, such as transmission frequency, network operation, sensing frequency, and the like.

A power block or other power source coupled to the grid may be coupled with the BMS to charge the battery 930. In some examples, power block XS30 may be replaced with a wireless power receiver to obtain power wirelessly, for example, through a loop antenna in computer platform 900. In these examples, the wireless battery charging circuit may be included in a BMS. The particular charging circuit selected may depend on the size of the battery 930, and thus the current required. The charging may be performed using an air fuel standard promulgated by the air fuel Alliance (air fuel Alliance), a Qi Wireless charging standard promulgated by the Wireless Power Consortium (Wireless Power Consortium), or a Rezence charging standard promulgated by the Wireless Power Consortium (Alliance for Wireless Power).

User interface circuitry 950 includes various input/output (I/O) devices that reside within platform 900 or are connected to the interior of platform 900, and includes one or more user interfaces designed to enable a user to interact with platform 900, and/or peripheral component interfaces designed to enable peripheral components to interact with 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 input, including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touch screen, a microphone, a scanner, a headset, and so forth. Output device circuitry includes any physical or virtual means for displaying information or otherwise communicating information (e.g., sensor readings, actuator positions, or other similar information). Output device circuitry may include any number and/or combination of audio or visual displays including 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 touch screens (e.g., Liquid Crystal Displays (LCDs), LED displays, quantum dot displays, projectors, etc.) with outputs generated or produced from operation of platform 900, such as characters, graphics, multimedia objects, etc. output device circuitry may also include speakers or other audio transmission devices, printers, etc. Actuators providing haptic feedback, etc.). In another example, an NFC circuit may be included having an NFC controller and a processing device coupled with an antenna element for reading an electronic tag and/or connecting with another NFC-enabled device. The 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 interface, and the like.

Although not shown, the components of platform 900 may communicate with each other using suitable bus technologies, which may include any number of technologies, including Industry Standard Architecture (ISA), extended ISA (eisa), Peripheral Component Interconnect (PCI), peripheral component interconnect extension (PCI), PCI express (pcie), Time Triggered Protocol (TTP) systems, FlexRay systems, or any number of other technologies. The bus may be a dedicated bus, such as a bus used in SoC-based systems. Other bus systems may be included, such as an I2C interface, an SPI interface, a point-to-point interface, a power bus, and so forth.

Fig. 10 illustrates example components of a baseband circuit 910 and a Radio Front End Module (RFEM)915, in accordance with various embodiments. As shown, RFEM 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. Baseband circuitry 910 may include one or more baseband processors or control logic to process baseband signals received from the receive signal path of RF circuitry 1006 and to generate baseband signals for the transmit signal path of RF circuitry 1006. The baseband processing circuitry 910 may interact with application circuitry 905 to generate and process baseband signals and control the operation 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 1004D for other existing generations, generations under development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). Baseband circuitry 910 (e.g., one or more baseband processors 1004A-D) may process various radio control functions that enable communication with one or more radio networks via RF circuitry 1006. In other embodiments, some or all of the functionality of the baseband processors 1004A-D may be included in modules stored in the memory 1004G and may be performed 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, and the like. In some embodiments, the modulation/demodulation circuitry of baseband circuitry 910 may include Fast Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, the encoding/decoding circuitry of baseband circuitry 910 may include convolutional, tail-bit convolutional, turbo, viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments.

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

In some embodiments, baseband circuitry 910 may provide communications 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 WMANs, WLANs, WPANs. 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.

The RF circuitry 1006 may enable communication with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1006 may include switches, filters, amplifiers, and the like to facilitate 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 FEM circuitry 1008 and provide baseband signals to baseband circuitry 910. RF circuitry 1006 may also include a transmit signal path, which may include circuitry to upconvert baseband signals provided by baseband circuitry 910 and provide an RF output signal to FEM circuitry 1008 for transmission.

In some embodiments, the receive signal path of the RF circuitry 1006 may include a mixer circuit 1006a, an amplifier circuit 1006b, and a filter circuit 1006 c. In some embodiments, the transmit signal path of the RF circuitry 1006 may include filter circuitry 1006c and mixer circuitry 1006 a. The RF circuitry 1006 may also include synthesizer circuitry 1006d for synthesizing frequencies for use by the mixer circuitry 1006a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuit 1006a of the receive signal path may be configured to down-convert the RF signal received from the FEM circuit 1008 based on the synthesized frequency provided by the synthesizer circuit 1006 d. The amplifier circuit 1006b may be configured to amplify the downconverted signal, and the filter circuit 1006c may be a Low Pass Filter (LPF) or a Band Pass Filter (BPF) configured to remove unwanted signals from the downconverted signal to produce an output baseband signal. The output baseband signal may be provided to baseband circuitry 910 for further processing. In some embodiments, the output baseband signal may be a zero frequency baseband signal, although this is not required. In some embodiments, mixer circuit 1006a of the receive signal path may comprise a passive mixer, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 1006a of the transmit signal path may be configured to upconvert the input baseband signal based on a synthesis frequency provided by the synthesizer circuitry 1006d to generate an RF output signal for the FEM circuitry 1008. The baseband signal may be provided by baseband circuitry 910 and may be filtered by filter circuitry 1006 c.

In some embodiments, mixer circuitry 1006a of the receive signal path and mixer circuitry 1006a of the transmit signal path may comprise two or more mixers and may be arranged for quadrature down-conversion and up-conversion, respectively. In some embodiments, the mixer circuit 1006a of the receive signal path and the mixer circuit 1006a 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, mixer circuitry 1006a of the receive signal path and mixer circuitry 1006a of the transmit signal path may be arranged for direct down-conversion and direct up-conversion, respectively. In some embodiments, mixer circuit 1006a of the receive signal path and mixer circuit 1006a of the transmit signal path may be configured for superheterodyne operation.

In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative 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, separate radio IC circuits may be provided to process signals for each spectrum, although the scope of the embodiments is not limited in this respect.

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

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

In some embodiments, the frequency input may be provided by a Voltage Controlled Oscillator (VCO), but this is not required. The divider control input may be provided by baseband circuitry 910 or application circuitry 905 depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a look-up table based on the channel indicated by the application circuitry 905.

Synthesizer circuit 1006d of RF circuit 1006 may include a frequency divider, a Delay Locked Loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the divider may be a dual-mode divider (DMD) and the phase accumulator may be a Digital Phase Accumulator (DPA). In some embodiments, the DMD may be configured to divide an input signal by N or N +1 (e.g., based on a carry) to provide a fractional division ratio. In some example embodiments, a DLL may include a set of cascaded adjustable delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these embodiments, the delay elements may be configured to divide the VCO period into up to Nd equal phase groups, where Nd is the number of delay elements in the delay line. Thus, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, the synthesizer circuit 1006d 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 the quadrature signal generator and divider circuit to produce a plurality of signals at the carrier frequency having a plurality of different phases from one another. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuitry 1006 may include an IQ/polarity 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 amplified versions of the received signals to RF circuitry 1006 for further processing. FEM circuitry 1008 may also include a transmit signal path, which may include circuitry configured to amplify signals provided by RF circuitry 1006 for transmission by one or more of the one or more antennas 1011. In various embodiments, amplification by the transmit signal path or the receive signal path may be done in the RF circuitry 1006 only, the FEM circuitry 1008 only, 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. 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 the received RF signal and provide the amplified receive RF signal 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 an input RF signal (e.g., provided by RF circuitry 1006); and one or more filters to generate RF signals for subsequent transmission (e.g., via one or more of the one or more antennas 1011).

The processor of the application circuit 905 and the processor of the baseband circuit 910 may be used to execute elements of one or more instances of a protocol stack. For example, the processor of the baseband circuitry 910 may be used, alone or in combination, to perform layer 3, layer 2, or layer 1 functions, while the processor of the application circuitry 905 may utilize data (e.g., packet data) received from these layers and further perform layer 4 functions (e.g., TCP and UDP layers). As mentioned herein, layer 3 may include an RRC layer, described in further detail below. As mentioned herein, the layer 2 may include a MAC layer, an RLC layer, and a PDCP layer, which will be described in further detail below. As mentioned herein, layer 1 may include the PHY layer of the UE/RAN node, as described in further detail below.

Fig. 11 illustrates an exemplary interface of a baseband circuit, in accordance with various embodiments. As discussed above, the baseband circuitry 910 of fig. XS1, 9, and XT may include processors 1004A-1004E and memory 1004G used by the processors. Each of the processors 1004A-1004E may include a memory interface 11104A-11104E, respectively, to send data to/receive data from memory 1004G.

The baseband circuitry 910 may also include one or more interfaces to communicatively couple to other circuitry/devices, such as: a memory interface 11112 (e.g., an interface for transmitting/receiving data to/from memory external to the baseband circuitry 910), an application circuitry interface 11114 (e.g., an interface for transmitting/receiving data to/from the application circuitry 905 of figure XS 1-XT), an RF circuitry interface 11116 (e.g., an interface for transmitting/receiving data to/from the RF circuitry 1006 of figure XT), a wireless hardware connection interface 11118 (e.g., an interface for transmitting/receiving data to/from Near Field Communication (NFC) components, a wireless communication interface 1112, a wireless communication interface, a wireless communication,

The components (e.g.,

low energy consumption),

An interface for components and other communication components to send/receive data) and a power management interface 11120 (e.g., an interface for sending/receiving power or control signals to/from the PMIC 925).

Fig. 12 illustrates a block diagram of components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, in accordance with some embodiments. In particular, fig. 12 shows a diagrammatic representation of hardware resources 1200, hardware resources 1200 comprising 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 terms "computing resource," "hardware resource," and the like may refer to a physical or virtual device, a physical or virtual component within a computing environment, and/or a physical or virtual component in a particular device, such as a computer device, a mechanical device, a memory space, processor/CPU time and/or processor/CPU usage, processor and accelerator load, hardware time or usage, electrical power, input/output operations, ports or network sockets, channel/link allocations, throughput, memory usage, storage, networks, databases, applications, and the like. For embodiments in which node virtualization (e.g., NFV) is utilized, hypervisor 1202 may be executed to provide an execution environment for one or more network slices/subslices to utilize hardware resources 1200. "virtualized resources" may refer to computing, storage, and/or network resources that the virtualization infrastructure provides to an application, device, system, and the like.

Processor 1210, such as 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) (e.g., 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, processor 1212 and processor 1214.

Memory/storage device 1220 may include a main memory, a disk storage, or any suitable combination thereof. The memory/storage 1220 may include, but is not limited to, any type of volatile or non-volatile 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 memory, and the like.

The communication resources 1230 may include interconnection or network interface components or other suitable devices to communicate with one or more peripherals 1204 or one or more databases via the network 12081206. For example, communication resources 1230 can include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, and/or wireless communication components,

The components (e.g.,

low power consumption),

Components and other communication components. As used herein, the term "network resource" or "communication resource" may refer to a computing resource accessible to a computer device via a communication network. The term "system resource" may refer to any kind of shared entity that provides a service, and may include computing and/or network resources. A system resource can be thought of as a set of coherent functions, network data objects, or services that can be accessed through a server, where such system resource resides on a single host or multiple hosts and is clearly identifiable.

The instructions 1250 may include software, a program, an application, an applet, an application, or other executable code for causing at least any one 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 processor 1210 (e.g., within a cache memory of the processor), the memory/storage device 1220, or any suitable combination thereof. Further, any portion of instructions 1250 may be transferred to hardware resource 1200 from any combination of peripheral devices 1204 or databases 1206. Thus, the memory of processor 1210, memory/storage 1220, peripherals 1204, and database 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 foregoing 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, baseband circuitry as described above in connection with one or more of the foregoing figures may be configured to operate in accordance with one or more examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc., described above in connection with one or more of the preceding figures, can be configured to operate in accordance with one or more examples set forth below in the examples section.

Some non-limiting examples are provided below.

Example 1 includes a method comprising: receiving configuration information from a network, the configuration information comprising: an indication of sidelink control resources to be used for vehicle-to-vehicle (V2V) communications, an indication of one or more Physical Sidelink Control Channel (PSCCH) formats to be transmitted or monitored by the in-vehicle UE, and an indication of one or more Sidelink Control Information (SCI) formats to be transmitted or monitored by the in-vehicle UE; and sending or monitoring PSCCH transmissions comprising SCIs 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 comprises an indication of a plurality of PSCCH formats, wherein each PSCCH format is 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 comprises: 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 process, a channel quality measurement or a congestion control process; and transmitting the PSCCH transmission using the selected PSCCH format.

Example 5 includes the method of example 4 or 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 rules for mapping the PSCCH transmission to one or more side link control channel elements in a side link 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, the method further comprising: determining a first set of control resources available to all UEs in a network based on the configuration information; and determining a second set of control resources available to a subset of the UEs in the network.

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

Example 10 includes the method of example 9 or some other example herein, wherein the PSCCH and PSCCH multiplexing schemes are at the following levels: a sub-slot level where the PSCCH and the PSSCH are time division multiplexed in the same slot; a slot level in the case where the PSCCH and the PSSCH are frequency division multiplexed in the same slot; a slot level where the PSCCH and the PSCCH are time division multiplexed in different slots; or a sub-slot level in the case where the PSCCH and PSCCH are time division multiplexed in different slots.

Example 11 includes a method, comprising: storing configuration information indicating: a sidelink control resource for vehicle-to-vehicle (V2V) communications, one or more Physical Sidelink Control Channel (PSCCH) formats to be transmitted or monitored by the in-vehicle UE, and a mapping rule for mapping PSCCH transmissions to multiple sidelink control channel elements frequency-multiplexed or time-multiplexed using a continuous allocation characteristic; and causing the PSCCH transmission to transmit or monitor the plurality of sidelink control channel elements for the PSCCH transmission on the plurality of sidelink control channel elements 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 includes 12 resource elements in a frequency domain and 3 symbols in a time domain.

Example 13 includes the method of example 11 or some other example herein, wherein the PSCCH transmission includes preemption side link 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 link control information of the preemption side; determining an overlapping schedule for scheduled transmissions in time and frequency resources; and performing resource reselection for the transmission based on the determination of the overlapping schedule and the preempting sidelink control information.

Example 15 includes the method of example 13 or some other example herein, wherein the preemptive sidelink control information comprises an indication of a priority level value, and the method further comprises: determining an overlapping schedule for transmissions scheduled in time and frequency resources, the transmissions comprising associated transmission priorities; comparing the transmission priority with 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 a transmitter for one or more UEs in a group for providing wireless layer feedback; determining that the in-vehicle UE did not correctly receive a physical side link shared channel (PSSCH) transmission for the group; and transmitting a negative acknowledgement on the side link feedback resource based on the determination.

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

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

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

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

Example 21 may include an apparatus comprising means for performing one or more elements of a method described in examples 1-20 or a method 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 that, when executed by one or more processors of the electronic device, cause the electronic device to perform one or more elements of a method described in or relating 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 relating to any of examples 1-20 or any other method or process described herein.

Example 24 may include, or be part of or a process, a method, a technique, or a process as described in or relating to any of examples 1-20.

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 a method, technique, or process as described in or related to any of examples 1-20, or a portion 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 communications as shown and described herein.

Example 28 may include an apparatus for providing wireless communications as shown and described herein.

The description herein of illustrated embodiments, including what is described in the abstract, is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. While specific embodiments of, and examples for, the disclosure are described herein for illustrative purposes, various alternative or equivalent embodiments or implementations calculated to achieve the same purposes will be apparent to those of ordinary skill in the relevant art from the above detailed description without departing from the scope of the disclosure.

Claims (20)

1. One or more computer-readable media having instructions that, when executed by one or more processors, cause an in-vehicle User Equipment (UE) to:

receiving configuration information from a network, the configuration information comprising: an indication of sidelink control resources to be used for vehicle-to-vehicle (V2V) communications, an indication of one or more Physical Sidelink Control Channel (PSCCH) formats to be transmitted or monitored by the in-vehicle UE, and an indication of one or more Sidelink Control Information (SCI) formats to be transmitted or monitored by the in-vehicle UE; and

transmitting or monitoring a PSCCH transmission including a 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 comprises an indication of a plurality of PSCCH formats, wherein each PSCCH format is associated with a corresponding number of sidelink control channel elements.

3. The one or more computer-readable media of claim 2, wherein the plurality of PSCCH formats comprises: 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 in-vehicle UE to:

selecting a PSCCH format from the plurality of PSCCH formats based on a distributed scheduling process, a channel quality measurement, or a congestion control process; and

transmitting the PSCCH transmission using the selected PSCCH format.

5. The one or more computer-readable media of claim 4, wherein the instructions, when executed, further cause the in-vehicle 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 rules for mapping the PSCCH transmission to one or more side link control channel elements in a side link control resource set.

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

determining 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 in-vehicle UE to:

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

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

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

determining a PSCCH and physical side link shared channel (PSSCH) multiplexing scheme based on the configuration information or the distributed scheduling decision.

10. The one or more computer-readable media of claim 9, wherein the PSCCH and PSCCH multiplexing schemes are on the following level: a sub-slot level where the PSCCH and the PSSCH are time division multiplexed in the same slot; a slot level in the case where the PSCCH and the PSSCH are frequency division multiplexed in the same slot; a slot level where the PSCCH and the PSCCH are time division multiplexed in different slots; or a sub-slot level in the case where the PSCCH and PSCCH are time division multiplexed in different slots.

11. An apparatus to be employed in a vehicular User Equipment (UE), the apparatus comprising:

a memory to store configuration information indicating: a sidelink control resource for vehicle-to-vehicle (V2V) communications, one or more Physical Sidelink Control Channel (PSCCH) formats to be transmitted or monitored by the in-vehicle UE, and a mapping rule for mapping PSCCH transmissions to multiple sidelink control channel elements frequency-multiplexed or time-multiplexed using a continuous allocation characteristic; and

processing circuitry to cause the PSCCH transmission to be sent on 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 side link control channel elements comprises 12 resource elements in a frequency domain and 3 symbols in a time domain.

13. The apparatus of claim 11, wherein the PSCCH transmission comprises preemption side link control information for indicating 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: detecting the link control information of the preemption side; determining an overlapping schedule for scheduled transmissions in time and frequency resources; and performing resource reselection for the transmission based on the determination of the overlapping schedule and the preempting sidelink control information.

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

determining an overlapping schedule for transmissions scheduled in time and frequency resources, the transmissions comprising associated transmission priorities; comparing the transmission priority with 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.

16. One or more computer-readable media having instructions that, when executed by one or more processors, cause an in-vehicle User Equipment (UE) to:

detecting a sidelink feedback resource reserved by a transmitter for one or more UEs in a group for providing wireless layer feedback;

determining that the in-vehicle UE did not correctly receive a physical side link shared channel (PSSCH) transmission for the group; and

transmitting a negative acknowledgement on the side link feedback resource based on the determination.

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

side link control information scheduling data from the transmitter is detected.

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

receiving and successfully decoding a second PSSCH transmission from the transmitter;

detecting a negative acknowledgement from another vehicular UE regarding the second PSSCH transmission; and

transmitting the second PSSCH transmission to the other vehicular UE.

19. The one or more computer-readable media of claim 18, wherein the instructions, when executed, further cause the in-vehicle UE to: detecting PSSCH resources reserved for retransmitting the second PSSCH transmission; and transmitting 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 in-vehicle UE to detect the psch resource based on signaling from the transmitter or the other in-vehicle UE.

Images