Error-free transmission in AVM C-V2X-based wireless networks

Abstract

This disclosure provides "Error-free transmission in an AVM C-V2X-based wireless network". Allocating transmission resources in an Automated Vehicle Formation (AVM) system includes: identifying multiple Roadside Units (RSUs) of the AVM system, each RSU configured to communicate with multiple vehicles; allocating each of the multiple RSUs to a non-overlapping RSU transmission (Tx) pool for semi-persistent scheduling (SPS), such that no RSU shares a common transmission slot within the SPS transmission schedule with another RSU or with any of the vehicles; allocating a common vehicle Tx pool to the vehicles, wherein the vehicles are restricted to transmission within the common vehicle Tx pool to prevent overlapping transmissions with the RSU Tx pool; and having each of the multiple RSUs use its allocated RSU Tx pool to transmit vehicle control messages to prevent overlap with transmissions from other RSUs and / or with the vehicles.

Description

Technical Field

[0001] Various aspects of this disclosure generally relate to error-free transmission in a wireless network for cellular vehicles based on Automated Vehicle Formation (AVM) to the outside world (C-V2X). Background Technology

[0002] Vehicle-to-the-world (V2X) is a type of communication that allows vehicles to communicate with various aspects of the traffic environment. This communication can include interacting with vehicles using vehicle-to-vehicle (V2V) communication and interacting with infrastructure using vehicle-to-infrastructure (V2I) communication.

[0003] Vehicles may include radio transceivers and on-board units (OBUs) to facilitate V2X communication. Roadside units (RSUs) provide wireless communication from roadside infrastructure to the OBU. This type of communication can be referred to as infrastructure-to-vehicle (I2V) communication. RSUs typically operate in the same frequency band as V2X using technologies such as cellular vehicle-to-outside (CV2X) and dedicated short-range communication (DSRC). Some RSUs offer additional functionality, such as local Wi-Fi hotspots for pedestrian, cellular backhaul, and central system information transmission, or direct communication and location using Bluetooth and ultra-wideband (UWB) technologies. Summary of the Invention

[0004] In one or more illustrative examples, a method for allocating transmission resources in an Automated Vehicle Medallion (AVM) system includes: identifying a plurality of Roadside Units (RSUs) of the AVM system, the RSUs being configured to communicate with a plurality of vehicles; assigning each of the plurality of RSUs to a non-overlapping RSU Transmission (Tx) pool for scheduling such that none of the RSUs shares a common transmission slot within the transmission schedule with another RSU or with any of the vehicles; allocating a common vehicle Tx pool to the vehicles, wherein the vehicles are restricted to transmitting within the common vehicle Tx pool to prevent overlapping transmissions with the RSU Tx pool; and having each of the plurality of RSUs use the allocated RSU Tx pool to transmit vehicle control messages to prevent overlap with transmissions from other RSUs and / or with the vehicles.

[0005] In one or more illustrative examples, the scheduling is semi-persistent scheduling (SPS), and the allocation of multiple Tx pools includes a repetition pattern that defines a time transmission interval (TTI) for each of multiple different transport resources for the respective Tx pool.

[0006] In one or more illustrative examples, assigning each of the plurality of RSUs to a corresponding Tx pool includes spatially multiplexing the Tx pools of the plurality of RSUs that are at least separated by one transmission range.

[0007] In one or more illustrative examples, the method further includes setting a hold-up probability parameter for SPS transmissions from the RSU for dedicated cellular vehicle-to-the-outside (C-V2X) networks to ensure continued use of allocated transmission resources.

[0008] In one or more illustrative examples, the method further includes allocating a plurality of transmission time slots to each of the plurality of RSUs, such that the plurality of RSUs are configured to perform a reselection to switch between the plurality of transmission time slots.

[0009] In one or more illustrative examples, the method further includes detecting the traffic volume of each of the plurality of RSUs; and adjusting the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with larger traffic volumes are allocated more resources compared to RSUs with smaller traffic volumes.

[0010] In one or more illustrative examples, the method further includes detecting the traffic density of each of the plurality of RSUs; and adjusting the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with higher traffic densities are allocated more resources compared to RSUs with lower traffic densities.

[0011] In one or more illustrative examples, a system for allocating transport resources for Automated Vehicle Grouping (AVM) includes: a plurality of RSUs configured to communicate with a plurality of vehicles; and an AVM server configured to: allocate each of the plurality of RSUs to a non-overlapping RSU transport (Tx) pool for scheduling such that none of the plurality of RSUs shares a common transport time slot within the transport schedule with another of the plurality of RSUs or with any of the vehicles; allocate a common vehicle Tx pool for the plurality of vehicles operating under the control of the AVM server, wherein the plurality of vehicles are restricted to transport within the common vehicle Tx pool to prevent overlapping transport with the RSU Tx pool; and have each of the plurality of RSUs use the allocated RSU Tx pool to transmit vehicle control messages to prevent overlap with transports from other RSUs and / or with the vehicles.

[0012] In one or more illustrative examples, the scheduling is semi-persistent scheduling (SPS), and the allocation of multiple Tx pools includes a repetition pattern that defines a time transmission interval (TTI) for each of multiple different transport resources for the respective Tx pool.

[0013] In one or more illustrative examples, assigning each RSU to a corresponding Tx pool includes spatially multiplexing Tx pools from RSUs that are at least one transmission range apart.

[0014] In one or more illustrative examples, the AVM server is also configured to set a hold-up probability parameter for SPS transmissions from the RSU for dedicated cellular vehicle-to-the-outside (C-V2X) networks to ensure continued use of allocated transmission resources.

[0015] In one or more illustrative examples, the AVM server is also configured to allocate a plurality of transport time slots to each of the plurality of RSUs, such that the plurality of RSUs are configured to perform a reselection to switch between the plurality of transport time slots.

[0016] In one or more illustrative examples, the AVM server is also configured to detect traffic volume for each RSU; and to adjust the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with larger traffic volumes are allocated more resources compared to RSUs with smaller traffic volumes.

[0017] In one or more illustrative examples, the AVM server is also configured to detect the traffic density of each of the plurality of RSUs; and to adjust the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with higher traffic density are allocated more resources compared to RSUs with lower traffic density.

[0018] In one or more illustrative examples, a non-transitory computer-readable medium includes instructions for allocating transmission resources in an Automated Vehicle Medallion (AVM) system. When executed by one or more processors of an AVM server communicating with a plurality of RSUs configured to communicate with a plurality of vehicles, the instructions cause the AVM server to perform operations including: allocating each of the plurality of RSUs to a non-overlapping RSU transmission (Tx) pool for scheduling such that none of the plurality of RSUs shares a common transmission slot within the transmission schedule with another RSU or with any of the vehicles; allocating a common vehicle Tx pool to vehicles operating in the AVM system, wherein the vehicles are restricted to transmission within the common vehicle Tx pool to prevent overlapping transmissions with the RSU Tx pool; and having each of the plurality of RSUs use the allocated RSU Tx pool to transmit vehicle control messages to prevent overlap with transmissions from other RSUs and / or with the vehicles.

[0019] In one or more illustrative examples, the scheduling is semi-persistent scheduling (SPS), and the allocation of multiple Tx pools includes a repetition pattern that defines a time transmission interval (TTI) for each of multiple different transport resources for the respective Tx pool.

[0020] In one or more illustrative examples, assigning each of the plurality of RSUs to a corresponding Tx pool includes spatially multiplexing Tx pools in RSUs that are at least one transmission range apart.

[0021] In one or more illustrative examples, the non-transitory computer-readable medium further includes instructions that, when executed by the one or more processors of the AVM server, cause the AVM server to perform operations including: for a dedicated C-V2X network, setting a hold-up probability parameter for SPS transmissions from the RSU to ensure continued use of allocated transmission resources.

[0022] In one or more illustrative examples, the non-transitory computer-readable medium further includes instructions that, when executed by the one or more processors of the AVM server, cause the AVM server to perform operations including: allocating a plurality of transport time slots to each of the plurality of RSUs, such that the plurality of RSUs are configured to perform a reselection to switch between the plurality of transport time slots.

[0023] In one or more illustrative examples, the non-transitory computer-readable medium further includes instructions that, when executed by the one or more processors of the AVM server, cause the AVM server to perform operations including one or more of the following: detecting traffic volume for each of the plurality of RSUs, and adjusting the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with larger traffic volumes are allocated more resources compared to RSUs with smaller traffic volumes; or detecting traffic density for each of the plurality of RSUs, and adjusting the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with larger traffic densities are allocated more resources compared to RSUs with smaller traffic densities. Attached Figure Description

[0024] Figure 1 An exemplary system configured to partition transport resources into non-overlapping Tx pools is shown; Figure 2 An exemplary environment including multiple RSUs and multiple vehicles is shown, illustrating a packet loss scenario; Figure 3An exemplary environment including multiple RSUs and multiple vehicles is shown, illustrating the Tx pool; Figure 4 An exemplary environment including multiple RSUs and multiple vehicles is shown, and details of an exemplary pool configuration are illustrated. Figure 5 An exemplary alternative transport scheduling is shown, comprising multiple RSUs and multiple vehicles, illustrating multiple available resources for RSU reallocation; Figure 6 An example of spatial reuse of Tx pools across multiple geographically distinct RSUs is shown; Figure 7 An exemplary process for allocating transport resources to non-overlapping Tx pools is shown; and Figure 8 An exemplary computing device is shown that supports partitioning transport resources into non-overlapping Tx pools. Detailed Implementation

[0025] Detailed embodiments of the invention are disclosed herein as needed; however, it should be understood that the disclosed embodiments are merely examples of the invention that can be embodied in various forms and alternative forms. The drawings are not necessarily drawn to scale; some features may be enlarged or minimized to show details of specific components. Therefore, the specific structural and functional details disclosed herein are not to be construed as limiting, but only as representative bases for teaching those skilled in the art to employ the invention in various ways.

[0026] Grouping refers to the remote control of a vehicle via commands generated by a server and transmitted to the vehicle over wireless channels, including C-V2X channels. C-V2X, or short-range V2I communication, is one of the options for AVM wireless communication technology. These grouping messages can be transmitted over C-V2X infrastructure, such as fixed RSUs.

[0027] The number of vehicles to be controlled simultaneously may be in the hundreds. To address this issue, multiple RSUs can be used to transmit control messages from the AVM server to the MV (vehicle group). While transmitting vehicle control messages via multiple RSUs mitigates the potential overload of a single RSU, introducing additional RSU devices can exacerbate congestion. Because the C-V2X protocol is based on energy sensing and implicit reservations, packet overlap is possible. For example, a packet sent by one RSU may be sent simultaneously with a packet sent by a vehicle and / or sent as a packet sent by another RSU.

[0028] Strict requirements may exist regarding packet loss between the AVM server and the vehicle. In one example, if two or more consecutive packets are lost, the MV may need to be stopped. This is known as stalling. If multiple RSUs and MVs follow the standard C-V2X protocol, such packet loss can occur frequently on the factory floor, leading to persistent vehicle stalling.

[0029] Various aspects of this disclosure utilize C-V2X features to partition the transmission resources of each RSU into a non-overlapping Tx pool. Vehicles are then configured to use a shared vehicle Tx pool to transmit packets destined for the AVM server.

[0030] In one approach, the hold probability parameter in a dedicated C-V2X network can be extended from a range of [0, …, 0.8] to a value including 1.0. This value allows a specific semi-persistent scheduling (SPS) flow to continue using the same resources until the higher layer revokes the flow. Changes in the value of the hold probability parameter do not affect the operation of the public C-V2X network, since the AVM network is proposed as a dedicated network. In another approach, the hold probability parameter is not adjusted, and instead redundant resources are allocated to RSUs to allow for limited reselection. Further aspects of this disclosure are discussed in detail herein.

[0031] Figure 1 An exemplary system 100 configured to partition transmission resources into non-overlapping Tx pools is shown. System 100 includes vehicles 102 that may be located in an indoor environment 122A and an outdoor environment 122B (collectively referred to as environment 122). Each vehicle 102 may include various controllers, such as a Telematics Control Unit (TCU) 104, a Global Navigation Satellite System (GNSS) controller 108, and an On-Board Unit (OBU) 110. Vehicle 102 may also include various vehicle sensors 112. These components of vehicle 102 may communicate via one or more buses (e.g., Vehicle Controller Area Network (CAN), Ethernet network, Media-Oriented System Transport (MOST) network, wireless network, etc.), which allows the OBU 110 to receive data describing the operation of the components of vehicle 102. System 100 may also include various Remote Subsystems (RSUs) 118 that communicate with vehicle 102. System 100 may include additional components, such as an AVM server 126, that communicate with vehicle 102 and RSUs 118. It should be noted that the components of system 100 are merely examples. Other systems 100 may include more, fewer, or differently positioned components.

[0032] Vehicle 102 may include a variety of other types of passenger vehicles, such as sedans, crossover multi-purpose vehicles (CUVs), vans, sports multi-purpose vehicles (SUVs), trucks, recreational vehicles (RVs), scooters, or other mobile machines used for transporting people or goods. In many cases, vehicle 102 may be powered by an internal combustion engine. In such cases, the fuel source may be gasoline or diesel fuel. As another possibility, vehicle 102 may be a hybrid electric vehicle (HEV) powered by both an internal combustion engine and one or more electric motors, such as a series hybrid electric vehicle, a parallel hybrid electric vehicle, or a parallel / series hybrid electric vehicle. As yet another possibility, vehicle 102 may be an electric vehicle (EV) powered by electric motors instead of an internal combustion engine. Because the type and configuration of vehicle 102 can vary, the capabilities of vehicle 102 can vary accordingly. As some other possibilities, vehicle 102 may have different capabilities in terms of passenger capacity, towing capacity and storage capacity. For ownership, inventory, and other purposes, vehicle 102 may be associated with a unique identifier, such as a vehicle identification number (VIN).

[0033] TCU 104 may include network hardware configured to facilitate communication between vehicle 102 and other devices of system 100. TCU 104 may include various types of computing devices supporting the execution of the functions described herein. In one example, TCU 104 may include one or more processors configured to execute computer instructions, and a storage medium on which computer-executable instructions and / or data may be held. Computer-readable storage media (also referred to as processor-readable media or storage devices) include any non-transitory (e.g., tangible) medium involved in providing data (e.g., instructions) that can be read by a computer (e.g., a processor). Generally, a processor receives instructions and / or data, such as from a storage device, into memory and uses the data to execute the instructions, thereby performing one or more processes, including one or more of the processes described herein. Computer-executable instructions can be compiled or interpreted from computer programs created using a variety of programming languages ​​and / or technologies, which individually or in combination include, but are not limited to: JAVA, C, C++, C#, FORTRAN, PASCAL, VISUAL BASIC, PYTHON, JAVASCRIPT, PERL, etc.

[0034] The GNSS controller 108 can allow the vehicle 102 to perform autonomous geospatial positioning. As some examples, the GNSS controller 108 functionality allows the vehicle 102 to use one or more satellite networks (such as Global Positioning System (GPS), GLONASS, Galileo, BeiDou and / or others) to determine its location.

[0035] OBU 110 can be configured to provide telematics services to vehicle 102. As some non-limiting possibilities, these services may include navigation, route guidance, vehicle health reports, local business searches, accident reporting, and hands-free calling. OBU 110 can communicate with transceiver 114. Therefore, OBU 110 can be configured to communicate over a cellular network using transceiver 114 via various protocols. For example, OBU 110 may access a cellular network via a connection to one or more cell towers. To facilitate communication over the communication network, OBU 110 may be associated with a unique device identifier (e.g., Mobile Device Number (MDN), Internet Protocol (IP) address, etc.) to identify OBU 110's communication over the communication network as associated with vehicle 102. Additionally, OBU 110 can be configured to communicate via broadcast peer-to-peer protocols (such as PC5) to facilitate V2X communication with devices such as RSU 118. It should be noted that these protocols are merely examples, and different peer-to-peer and / or cellular technologies may be used.

[0036] Vehicle sensors 112 can be configured to receive information about the surrounding environment of vehicle 102. In one example, these vehicle sensors 112 may include one or more of a camera (e.g., an advanced driver assistance system (ADAS) camera), an ultrasonic sensor, a radio detection and ranging (radar) system, and / or a light detection and ranging (LiDAR) system.

[0037] Transceiver 114 can be configured to provide wireless communication services to TCU 104. TCU 104 may include or otherwise access transceiver 114 configured to facilitate communication with other networked devices such as telematics servers or with other vehicles 102. TCU 104 may also be configured to communicate via various other protocols, such as network protocols (e.g., Uu) with a communication network. It should be noted that these protocols are merely examples and different peer-to-peer and / or cellular technologies may be used.

[0038] RSU 118 may be a device with processing and networking capabilities and may be designed to be placed near a road for communication with vehicle 102. In one example, RSU 118 may include hardware configured to communicate via a broadcast peer-to-peer protocol (such as PC5) to facilitate V2X communication with vehicle 102. RSU 118 may also have wired or wireless backhaul capabilities to allow wired or wireless communication with other components of system 100.

[0039] Infrastructure sensors 120 may include various devices that use cameras, lidar, radar, electromagnetic, wireless backscatter, etc. to track the position or other attributes of vehicles 102, pedestrians or other traffic participants or obstacles, such as red light cameras, wireless toll gantry, parking timers, and under-road traffic volume counter loops.

[0040] Indoor environment 122A may include, for example, a factory, dealership, service center, parking garage, etc. Outdoor environment 122B may include, for example, a parking lot, road, or off-road trail outside indoor environment 122A. In indoor environment 122, communication between vehicle 102 and RSU 118 can be maintained in a dedicated C-V2X network. This allows for greater control compared to outdoor environment 122B, where a closed dedicated network may be difficult to secure.

[0041] AVM server 126 can be configured to monitor vehicle 102, whether vehicle 102 is in indoor environment 122A or outdoor environment 122B. AVM server 126 can be configured to use a wireless network to control and monitor vehicle 102 (e.g., as an MV). AVM server 126 can communicate with vehicle 102 using RSU 118, which can be placed in strategic locations such as intersections, stops, and high-traffic areas. This allows AVM server 126 to relay information to vehicle 102, such as navigation instructions, route optimization, object alerts, and updates on the operational status of machinery or other mobile assets.

[0042] AVM server 126 can be configured to perform GNSS-based location services for locating vehicles 102, including providing a map on a map showing the locations of multiple vehicles 102. AVM server 126 can also be configured to receive sensor data from infrastructure sensors 120 to form a more complete view of the state of each of the vehicles 102 in addition to their location.

[0043] When operating in an outdoor environment 122B, the AVM server 126 can be configured to utilize a constellation of GNSS satellites 128 to facilitate the geolocation of the vehicle 102. This can be achieved, for example, by the vehicle 102 using its GNSS controller 108 to locate itself using the GNSS satellites 128 and wirelessly transmitting that location information via its OBU 110 and transceiver 114 to an RSU 118 communicating with the AVM server 126.

[0044] However, when operating in indoor environment 122A, vehicle 102 can utilize signals from GNSS repeater 130. GNSS repeater 130 can receive signals from the GNSS satellite constellation 128 via antenna 132 located within the line of sight of GNSS satellites 128. GNSS repeater 130 can use antenna 132 to capture GNSS broadcasts and can replay those signals into indoor environment 122A. This allows vehicle 102 to utilize location services while indoors, which would otherwise be impossible because vehicle 102 is not visible to the GNSS satellite constellation 128 when it is in indoor environment 122A. However, the repeater method may reduce the accuracy of GNSS positioning when in indoor environment 122A. It should be noted that this is merely an example, and other positioning technologies, such as a high-precision real-time positioning system (RTLS) with ultra-wideband (UWB) for tracking vehicle 102 in indoor environment 122A, may be used alternatively or in combination.

[0045] An additional purpose of GNSS satellite 128 and GNSS repeater 130 is for precise timing, which can be used to synchronize over-the-air C-V2X transmissions. In the absence of GNSS repeater 130 in an indoor environment, the C-V2X over-the-air interface can provide a feature allowing RSU 118 in indoor environment 122A to provide synchronization with RSU 118 in outdoor environment 122B. This can be achieved if RSU 118 in outdoor environment 122B can receive GNSS signals directly from the satellite and become synchronized. Once RSU 118 in indoor environment 122A is synchronized with at least one RSU 118 in outdoor environment 122B, RSU 118 can provide a synchronization signal to the attached vehicle OBU 108 via over-the-air. When vehicle 102 moves from indoor environment 122A to outdoor environment 122B, the vehicle can switch between RSU 118 in indoor environment 122A as a synchronization source with GNSS satellite 128, and vice versa.

[0046] AVM server 126 can be configured to request and initiate Semi-Persistent Scheduling (SPS) transport scheduling 134 for communication between vehicle 102 and RSU 118. SPS is a resource allocation technique used in wireless networks, such as in C-V2X and 5G-based communications, where AVM server 126 pre-allocates communication resources to vehicle 102 and RSU 118 at periodic intervals, thereby reducing the overhead of frequent scheduling requests. While AVM server 126 can request and initiate new SPSs, the selection of radio resources based on SPS parameters and the maintenance of regular transmissions are managed by RSU 118. In an indoor environment 122A, AVM server 126 can define SPS parameters to ensure that control messages are transmitted between RSU 118 and OBU 110 on vehicle 102 at consistent predefined intervals. This approach minimizes latency, optimizes spectral efficiency, and enhances reliability, which helps control MV. An example of SPS transport scheduling 134 is discussed in detail herein.

[0047] SPS operates by reserving specific time-frequency radio resources for periodic transmissions, eliminating the need for vehicle 102 or RSU 118 to request scheduling authorization for each transmission. Once the SPS configuration is established, RSU 118 allocates a set of transmission opportunities to OBU 110 at predefined intervals, ensuring predictable and low-latency communication. SPS parameters can define the periodicity of transmissions, the specific physical resource blocks (PRBs) allocated, and the modulation and coding scheme (MCS) used for communication. If vehicle 102 or RSU 118 detects a need to modify its SPS allocation, such as to adjust for network congestion or adapt to dynamic radio conditions, vehicle 102 or RSU 118 can trigger a request to reconfigure the SPS parameters. Additionally, SPS can be combined with a semi-adaptive mechanism, where transmissions continue to occur unless a release or reallocation request is received. This scheduling technique is particularly advantageous in high-reliability applications such as vehicle control and cooperative maneuvering because it reduces the overhead associated with dynamic resource allocation while ensuring timely message delivery.

[0048] While SPS-based transport is the preferred method for scheduling transports, in some cases (such as reaching the maximum allowed number of SPS streams), it may be necessary to send transports in a non-SPS manner (sometimes referred to as event-based (or single-transfer) transports). These event-based transports can also be sent through the same Tx pool defined for a specific RSU 118.

[0049] Figure 2An exemplary environment 122 including multiple RSUs 118 and multiple vehicles 102 is shown, illustrating a packet loss scenario. As shown, the multiple RSUs 118 include RSU 118-1 and RSU 118-2. The multiple vehicles 102 include vehicles 102-1, 102-2, 102-3, 102-4, and 102-5. Additionally, two SPS transmission schedules 134 are shown: a first SPS transmission schedule 134-1 and a second SPS transmission schedule 134-2. The vertical axis of the SPS transmission schedule 134 represents different transmission resources in the frequency domain, while the horizontal axis represents time. Each of the vehicles 102 and RSUs 118 is associated with a different mode, where these modes are used to indicate the resources and timing of packets transmitted by the corresponding vehicle 102 and RSU 118. In addition, vehicles 102-1 and 102-2 are within the transmission area of ​​RSU 118-2, while vehicles 102-3, 102-4 and 102-5 are within the transmission area of ​​RSU 118-1.

[0050] In SPS transport schedule 134-1, RSU 118-1 sends periodic transmissions across all resources, as shown here during time indices 11 and 31. Similarly, RSU 118-2 sends periodic transmissions across all resources during time indices 6 and 26.

[0051] For illustrative purposes, vehicle 102-1 uses the first resource block to send periodic transmissions during the first, twenty-first, and forty-first time indices. Vehicle 102-2 uses the third resource block to send periodic transmissions during the third, twenty-third, and forty-third time indices. Vehicle 102-3 uses the second resource block to send periodic transmissions during the tenth and thirtieth time indices. Vehicle 102-4 uses the first resource block to send periodic transmissions during the twelfth and thirty-second time indices. Vehicle 102-5 uses the fourth resource block to send periodic transmissions during the fourth, twenty-fourth, and forty-fourth time indices.

[0052] In SPS transmission scheduling 134-2, vehicle 102-3 has reselected resources. This reselection can occur from time to time by various devices of system 100 according to the C-V2X multi-access protocol. After reselection, all transmissions are identical in SPS transmission scheduling 134-2, except that vehicle 102-3 now uses the fifth resource block and a subsequent time index (here, during the eleventh and thirty-first time indices) for transmission.

[0053] In SPS transmission schedule 134-1, there is no overlapping transmission. Therefore, it is highly likely that all packets will be received at their destination. However, in SPS transmission schedule 134-2, the transmission of vehicle 102-3 overlaps with the transmission of RSU 118-2. This may result in packet loss to vehicle 102 served by RSU 118-2 (e.g., to vehicles 102-1 and 102-2). Furthermore, because the pattern is continuous, multiple consecutive packets may be lost, causing vehicles 102-1 and 102-2 to stall.

[0054] Figure 3 An exemplary environment 122 including multiple RSUs 118 and multiple vehicles 102 is shown, illustrating a Tx pool. As shown, in SPS transport scheduling 134, the transport resources of RSU 118-1 are configured such that the resource set of RSU 118-1 is dedicated solely to use by RSU 118-1. Similarly, the transport resources of RSU 118-2 are configured such that the resource set of RSU 118-2 is dedicated solely to use by RSU 118-2. The remaining transport resources are dedicated to use by the OBU 110 of vehicle 102, allowing vehicle 102 to use only those resources. Using this approach, vehicle 102 will not generate transports that overlap with the transports of RSU 118.

[0055] Figure 4 An exemplary environment 122 comprising multiple RSUs 118 and multiple vehicles 102 is shown, illustrating details of an exemplary pool configuration. As shown, a bitmap 400 is used to configure the Tx pools for RSUs 118-1, RSUs 118-2, and vehicle OBUs 110. This bitmap indicates which time slots (called Time Transmission Intervals (TTIs)) are allowed to be transmitted. The bitmap 400 for the Tx pool describes a specific period of time that then repeats. In the case shown, the period is 20 TTIs, but this is only an example, and bitmaps 400 of different lengths can specify shorter or longer patterns for the Tx pools.

[0056] As shown in the diagram, RSU 118-1 is assigned to the sixth time slot, while RSU 118-2 is assigned to the eleventh time slot. Vehicle 102 is then assigned the remaining time slots, for example, all time slots except for the sixth and eleventh. It should be noted that this is merely an example, and different examples with more RSU 118s or different time slot assignments can be used.

[0057] Given that the transmissions of RSU 118-1 and 118-2 do not overlap, and that the OBU 110 transmissions of vehicle 102 do not overlap with either RSU 118-1 or RSU 118-2 transmissions, packets transmitted by either RSU 118-1 or RSU 118-2 will not experience overlap. It should be noted that packets transmitted by vehicle 102 may still potentially interfere with each other, but this impact will not be worse than a Tx pool not allocated to RSU 118, and in any case, the requirements for packet loss for vehicle packets are less stringent than those for packet loss for AVM server 126.

[0058] In this approach, only one set of resources is allocated to each of the 118 RSUs. This is the minimum allocation that can be used for each 118 RSU. However, upon reselection, the scheduler will determine the probability of finding a different set of resources. This can be problematic because each 118 RSU has only one possible resource choice.

[0059] One approach to this problem is that, for a dedicated C-V2X network provided by AVM server 126, the hold-through probability of the SPS flow of RSU 118 can be set to 1. This means that the resource allocation will always remain unchanged. Therefore, this allows RSU 118 to continue sending on the same set of resources allocated through the Tx pool.

[0060] If packets from RSU 118 are sent as event-based transports instead of SPS streams, a similar extension can be introduced. In this option, AVM server 126 can be reconfigured to allow transports to always use the same resources.

[0061] Figure 5 An exemplary alternative SPS transport schedule 134 is shown, comprising multiple RSUs 118 and multiple vehicles 102, illustrating multiple available resources for reallocation of RSUs 118. Figure 5 A third alternative to those discussed above is shown, which may not be optimal because it allocates twice the required resources to each RSU 118. In this approach, RSU 118 can switch between different resources upon reselection. While not optimal, this solution still guarantees no packet loss for packets sent from RSU 118 to AVM server 126 of vehicle 102.

[0062] Figure 6An example of spatial multiplexing of Tx pools across multiple geographically disparate RSUs 118 is shown. As shown, five RSUs 118-1, 118-2, 118-3, 118-4, and 118-5 are arranged in a single linear array from one side of indoor environment 122A to the other. Two additional RSUs 118-6 and 118-7 are arranged in outdoor environment 122B, outside of indoor environment 122A.

[0063] Due to the distance between RSUs 118, RSUs 118 that are relatively far apart (e.g., at least one transmission range apart) may be able to reuse the same allocated Tx pool. As shown in the figure, RSUs 118-1, 118-4, and 118-7 each use the same first Tx pool, RSUs 118-2 and 118-5 use the same second Tx pool, and RSUs 118-3 and 118-6 use the same third Tx pool. Other combinations of reuse are also possible.

[0064] Variations of the disclosed concept are possible. In one example, the Tx pool configuration can be monitored and adjusted over time by an AVM server 126 that monitors overall traffic volume (e.g., using static and dynamic pool allocation). In another example, an RSU 118 experiencing a larger traffic volume can be assigned a larger Tx pool compared to an RSU 118 experiencing a smaller traffic volume.

[0065] Another variation can be implemented when the total number of resources is not divisible by the number of resources per RSU 118. Figure 6 The example shown assumes that the six TTIs are allocated in pairs; therefore, each RSU 118 is allocated resources of (1, 2), (3, 4), or (5, 6). If the total number of resources is, for example, seven, and the number of resources allocated to each RSU 118 is still two, then the allocation pattern could be, for example, (1, 2), (3, 4), (5, 6), (7, 1), and (2, 3), for RSUs 118-1, 118-2, 118-3, 118-4, and 118-5, respectively.

[0066] Figure 7An exemplary process 700 for allocating transport resources into non-overlapping Tx pools is illustrated. In one example, within the context of system 100, process 700 can be performed via AVM server 126. The goal of spatially allocating Tx resources among various RSUs 118 is to allocate a minimum sufficient amount of resources to each RSU 118, thereby leaving as many resources as possible for vehicle OBU 110 transport. Therefore, resource allocation to each RSU 118 should take into account the traffic load that RSU 118 may experience over time. Consequently, the allocation of Tx pools for RSUs 118 can account for such fluctuations. Allocating resources for resource reselection purposes is also part of this operation. For RSU 118-2, which has a non-uniform traffic load that is higher than its neighbors, an example of Tx pool allocation with the seven resources shown above can be as follows: (1, 2), (3, 4, 5), (6), (7, 1), (2, 3), for RSU 118-1, 118-2, 118-3, 118-4 and 118-5 respectively.

[0067] Another option for configuring radio resources for use by RSU 118 is to allow some resources to be shared more broadly to increase flexibility and potentially be used to carry lower priority traffic. For example, some radio resources could be allocated to RSU 118s that are close enough that they might potentially interfere with each other. In another example, these shared radio resources could also be part of a vehicle Tx pool.

[0068] In addition to allocation under uneven load conditions and / or broader resource sharing among RSUs 118 for lower priority traffic volumes, the allocation may also consider the traffic volume and density of vehicles 102 in bottleneck paths. For example, AVM server 126 may be programmed to understand areas controlled by certain RSUs 118 with higher traffic density. In other examples, AVM server 126 may monitor the location of vehicles 102 (e.g., via RSUs 118) to determine the location of vehicles 102 and thus identify areas of higher density. For higher density cases, the allocation may provide more resources to those vehicles 102 passing through those higher density areas. Doing so addresses the possibility that vehicles 102 traversing narrow paths have a greater chance of blocking traffic behind them.

[0069] At operation 702, AVM server 126 identifies multiple RSUs 118 of system 100. In one example, AVM server 126 can access or identify the configuration of RSUs 118, including RSUs 118 located in indoor environment 122A and RSUs 118 located in outdoor environment 122B.

[0070] At operation 704, AVM server 126 assigns each of the multiple RSUs 118 to a non-overlapping RSUTx pool for SPS. This assignment can be performed such that no RSU 118 shares a common transmission slot within the transmission schedule with another RSU 118 or with any of the vehicles 102. The allocation of multiple Tx pools may include defining a repetition pattern of TTIs for each of the multiple different transmission resources of the respective Tx pools. Assigning each RSU to a corresponding Tx pool includes spatially multiplexing Tx pools between RSUs that are at least N RSU coverage area radii apart, where N can be various values, such as four.

[0071] In some examples, for dedicated C-V2X networks, allocation may include setting a hold-up probability parameter for SPS transmissions from the RSU 118 to ensure continued use of the allocated transmission resources. In other examples, the allocation may include allocating a plurality of transmission time slots to each of the plurality of RSU 118, such that the plurality of RSU 118 are configured to perform reselection to switch between the plurality of transmission time slots. In some examples, the allocation may include detecting traffic volume for each RSU 118 and adjusting the size of the Tx pool allocated to each RSU 118 based on the detected traffic volume.

[0072] At operation 706, AVM server 126 allocates a common vehicle Tx pool for vehicle 102 operating in system 100. Therefore, vehicle 102 is restricted to transmission within the common vehicle 102 Tx pool to prevent overlapping transmissions with the RSU 118 Tx pool.

[0073] At operation 708, AVM server 126 causes RSU 118 to use its allocated RSU 118 Tx pool to transmit vehicle 102 control messages. By enabling RSU 118 to utilize its allocated resources, system 100 can prevent transmission issues with other RSUs 118 and / or concurrent packet issues with vehicle 102. After operation 708, process 700 ends.

[0074] Figure 8 An exemplary computing device is shown that supports partitioning transport resources into non-overlapping Tx pools. (Reference) Figure 8 and refer to Figures 1 to 7Vehicle 102, TCU 104, GNSS controller 108, OBU 110, vehicle sensor 112, transceiver 114, RSU 118, AVM server 106, GNSS satellite 128, GNSS repeater 130, etc., can be examples of such computing devices 802. Computing device 802 typically includes computer-executable instructions, which can be executed by one or more computing devices 802. Computer-executable instructions can be compiled or interpreted according to computer programs created using various programming languages ​​and / or techniques, individually or in combination including but not limited to Java™, C, C++, C#, Visual Basic, JavaScript, Python, Perl, etc. Generally, a processor (e.g., a microprocessor) receives instructions, for example, from memory, computer-readable media, etc., and executes these instructions to perform one or more processes, including one or more of the processes described herein. Such instructions and other data can be stored and transmitted using various computer-readable media.

[0075] As shown in the figure, computing device 802 may include a processor 804 operatively connected to storage device 806, network device 808, output device 810, and input device 812. It should be noted that this is merely an example, and computing device 802 with more, fewer, or different components may be used.

[0076] Processor 804 may include one or more integrated circuits that implement the functionality of a central processing unit (CPU) and / or a graphics processing unit (GPU). In some examples, processor 804 is a system-on-a-chip (SoC) that integrates the functionality of a CPU and a GPU. The SoC may optionally include other components, such as, for example, a storage device 806 and a network device 808, into a single integrated device. In other examples, the CPU and GPU are connected to each other via peripheral connectivity devices, such as Fast Peripheral Component Interconnect (PCI) or another suitable peripheral data connection. In one example, the CPU is a commercially available central processing unit that implements an instruction set, such as x86, ARM, Power, or a family of microprocessor instruction sets without interlocking pipelines (MIPS).

[0077] Regardless of the details, during operation, processor 804 executes stored program instructions retrieved from storage device 806. The stored program instructions accordingly include software that controls the operation of processor 804 to perform the operations described herein. Storage device 806 may include both non-volatile memory and volatile memory devices. Non-volatile memory includes solid-state memory, such as Not-And-(NAND) flash memory, magnetic and optical storage media, or any other suitable data storage device that retains data when the system is disabled or loses power. Volatile memory includes static and dynamic random-access memory (RAM) that stores program instructions and data during operation of system 100.

[0078] The GPU may include hardware and software for displaying at least two-dimensional (2D) and optionally three-dimensional (3D) graphics to the output device 810. The output device 810 may include a graphics or visual display device, such as an electronic display screen, projector, printer, or any other suitable device for reproducing a graphic display. As another example, the output device 810 may include an audio device, such as a speaker or headphones. As yet another example, the output device 810 may include a tactile device, such as a mechanically elevable device, which in one example may be configured to display Braille or another physical output that can be touched to provide information to a user.

[0079] The input device 812 may include any of a variety of devices that enable the computing device 802 to receive control input from a user. Examples of suitable input devices 812 for receiving human-machine interface input may include a keyboard, mouse, trackball, touch screen, microphone, graphics tablet, etc.

[0080] Network device 808 may each include any of a variety of means that enable the described components to transmit and / or receive data over a network and from external devices. Examples of suitable network devices 808 include an Ethernet interface, a Wi-Fi transceiver, a cellular transceiver, or a Bluetooth or Bluetooth Low Energy (BLE) transceiver, or other network adapters or peripheral interconnects that may be useful for receiving large amounts of data in an efficient manner.

[0081] Regarding the processes, systems, methods, heuristics, etc., described herein, it should be understood that although the steps of such processes, etc., have been described as occurring in a certain ordered order, such processes can be practiced by performing the described steps in a different order than that described herein. It should also be understood that some steps may be performed simultaneously, other steps may be added, or some steps described herein may be omitted. In other words, the description of processes herein is provided for the purpose of illustrating specific embodiments and should in no way be construed as limiting the claims.

[0082] Therefore, it should be understood that the above description is intended to be illustrative rather than restrictive. Many embodiments and applications beyond the examples provided will become apparent upon reading the above description. The scope should not be determined by reference to the above description, but rather by reference to the appended claims and the full scope of their equivalents. It is anticipated and expected that the techniques discussed herein will evolve in the future, and the disclosed systems and methods will be incorporated into such future embodiments. In conclusion, it should be understood that modifications and variations are possible with this application.

[0083] All terms used in the claims are intended to give their broadest reasonable structure and their general meaning, as would be understood by one of skill in the art described herein, unless explicitly indicated otherwise herein. Specifically, unless the claims explicitly limit the recitation to the contrary, the use of singular articles such as “a,” “the,” or “the” should be interpreted as referring to one or more of the elements indicated by the recitation.

[0084] An abstract of this disclosure is provided to allow the reader to quickly determine the nature of this technical disclosure. It should be understood that the abstract is not intended to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen in the foregoing detailed description, various features are grouped together in various embodiments for the purpose of making the disclosure fluent. This approach of the disclosure should not be construed as reflecting an intention to require more features than expressly stated in each claim. Rather, as reflected in the appended claims, the inventive subject matter lies in fewer than all features of a single disclosed embodiment. Therefore, the appended claims are hereby incorporated into the detailed description, wherein each claim is itself a separately claimed subject matter.

[0085] Although exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms of this disclosure. Rather, the terminology used herein is descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of this disclosure. Furthermore, features of various embodiments may be combined to form other embodiments of this disclosure.

[0086] According to the present invention, a method for allocating transmission resources in an Automated Vehicle Medallion (AVM) system includes: identifying a plurality of Roadside Units (RSUs) of the AVM system, the RSUs being configured to communicate with a plurality of vehicles; assigning each of the plurality of RSUs to a non-overlapping RSU transmission (Tx) pool for scheduling, such that none of the RSUs shares a common transmission slot within the transmission schedule with another RSU or with any of the vehicles; allocating a common vehicle Tx pool to the vehicles, wherein the vehicles are restricted to transmission within the common vehicle Tx pool to prevent overlapping transmissions with the RSU Tx pool; and having each of the plurality of RSUs use the allocated RSU Tx pool to transmit vehicle control messages to prevent overlap with transmissions from other RSUs and / or with the vehicles.

[0087] In one aspect of the invention, the scheduling is semi-persistent scheduling (SPS), and the allocation of multiple Tx pools includes a repetition pattern that defines a time transmission interval (TTI) for each of multiple different transmission resources for the respective Tx pool.

[0088] In one aspect of the invention, allocating each of the plurality of RSUs to a corresponding Tx pool includes spatially reusing the Tx pools of the plurality of RSUs that are spaced apart by the coverage radius of the plurality of RSUs.

[0089] In one aspect of the invention, the method includes setting a hold-up probability parameter for SPS transmissions from the RSU for a dedicated cellular vehicle-to-the-outside (C-V2X) network to ensure the continued use of allocated transmission resources.

[0090] In one aspect of the invention, the method includes allocating a plurality of transmission time slots to each of the plurality of RSUs, such that the plurality of RSUs are configured to perform a reselection to switch between the plurality of transmission time slots.

[0091] In one aspect of the invention, the method includes: detecting the traffic volume of each of the plurality of RSUs; and adjusting the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with larger traffic volumes are allocated more resources compared to RSUs with smaller traffic volumes.

[0092] In one aspect of the invention, the method includes: detecting the traffic density of each of the plurality of RSUs; and adjusting the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with higher traffic density are allocated more resources compared to RSUs with lower traffic density.

[0093] According to the present invention, a system for allocating transmission resources for Automated Vehicle Formation (AVM) is provided, the system comprising: a plurality of Restricted Units (RSUs) configured to communicate with a plurality of vehicles; and an AVM server configured to: allocate each of the plurality of RSUs to a non-overlapping RSU transmission (Tx) pool for scheduling such that none of the plurality of RSUs shares a common transmission time slot within the transmission schedule with another of the plurality of RSUs or with any of the vehicles; allocate a common vehicle Tx pool for the plurality of vehicles operating under the control of the AVM server, wherein the plurality of vehicles are restricted to transmission within the common vehicle Tx pool to prevent overlapping transmissions with the RSU Tx pool; and have each of the plurality of RSUs use the allocated RSU Tx pool to transmit vehicle control messages to prevent overlap with transmissions from other RSUs and / or with the vehicles.

[0094] According to an embodiment, the scheduling is semi-persistent scheduling (SPS), and the allocation of multiple Tx pools includes a repetition pattern that defines a time transmission interval (TTI) for each of multiple different transmission resources in the respective Tx pool.

[0095] According to an embodiment, allocating each RSU to a corresponding Tx pool includes spatially reusing Tx pools from RSUs that are at least a plurality of RSU coverage radii apart.

[0096] According to an embodiment, the AVM server is also configured to set a hold-up probability parameter for SPS transmissions from the RSU for dedicated cellular vehicle-to-the-outside (C-V2X) networks to ensure the continued use of allocated transmission resources.

[0097] According to an embodiment, the AVM server is further configured to allocate a plurality of transmission time slots to each of the plurality of RSUs, such that the plurality of RSUs are configured to perform a reselection to switch between the plurality of transmission time slots.

[0098] According to an embodiment, the AVM server is further configured to: detect the traffic volume of each RSU; and adjust the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with larger traffic volumes are allocated more resources compared to RSUs with smaller traffic volumes.

[0099] According to an embodiment, the AVM server is further configured to: detect the traffic density of each of the plurality of RSUs; and adjust the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with higher traffic density are allocated more resources compared to RSUs with lower traffic density.

[0100] According to the present invention, a non-transitory computer-readable medium is provided having instructions for allocating transmission resources in an Automated Vehicle Medallion (AVM) system. When executed by one or more processors of an AVM server communicating with a plurality of RSUs configured to communicate with a plurality of vehicles, the instructions cause the AVM server to perform operations comprising: allocating each of the plurality of RSUs to a non-overlapping RSU transmission (Tx) pool for scheduling such that none of the plurality of RSUs shares a common transmission slot within the transmission schedule with another RSU or with any of the vehicles; allocating a common vehicle Tx pool to vehicles operating in the AVM system, wherein the vehicles are restricted to transmission within the common vehicle Tx pool to prevent overlapping transmissions with the RSU Tx pool; and having each of the plurality of RSUs use the allocated RSU Tx pool to transmit vehicle control messages to prevent overlap with transmissions from other RSUs and / or with the vehicles.

[0101] According to an embodiment, the scheduling is semi-persistent scheduling (SPS), and the allocation of multiple Tx pools includes a repetition pattern that defines a time transmission interval (TTI) for each of multiple different transmission resources in the respective Tx pool.

[0102] According to an embodiment, allocating each of the plurality of RSUs to a corresponding Tx pool includes spatially reusing Tx pools in RSUs that are at least separated by a plurality of RSU coverage radii.

[0103] According to an embodiment, the invention is further characterized by instructions that, when executed by the one or more processors of the AVM server, cause the AVM server to perform an operation, the operation including: for a dedicated C-V2X network, setting a hold-up probability parameter for SPS transmissions from the RSU to ensure continued use of allocated transmission resources.

[0104] According to an embodiment, the invention is further characterized by instructions that, when executed by the one or more processors of the AVM server, cause the AVM server to perform an operation comprising: allocating a plurality of transmission time slots to each of the plurality of RSUs, such that the plurality of RSUs are configured to perform a reselection to switch between the plurality of transmission time slots.

[0105] According to an embodiment, the invention is further characterized by instructions that, when executed by the one or more processors of the AVM server, cause the AVM server to perform operations including one or more of the following: detecting the traffic volume of each of the plurality of RSUs, and adjusting the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with larger traffic volumes are allocated more resources compared to RSUs with smaller traffic volumes; or detecting the traffic density of each of the plurality of RSUs, and adjusting the size of the Tx pool allocated to each of the plurality of RSUs based on the detected traffic volume, such that RSUs with larger traffic densities are allocated more resources compared to RSUs with smaller traffic densities.

Claims

1. A method for allocating transmission resources in an Automated Vehicle Medallion (AVM) system, the method comprising: Identify multiple roadside units (RSUs) of the AVM system, wherein the RSUs are configured to communicate with multiple vehicles; Each of the plurality of RSUs is assigned to a non-overlapping RSU transport (Tx) pool for scheduling, such that none of the RSUs shares a common transport time slot within the transport schedule with another RSU or with any of the vehicles. The vehicles are assigned to a common vehicle Tx pool, wherein the vehicles are restricted to transmitting within the common vehicle Tx pool to prevent overlapping transmissions with the RSU Tx pool; Vehicle control messages are transmitted by each of the plurality of RSUs using an allocated RSU Tx pool to prevent overlap with transmissions from other RSUs and / or with the vehicle.

2. The method of claim 1, wherein the scheduling is semi-persistent scheduling (SPS), and the allocation of multiple Tx pools includes a repetition pattern defining a time transmission interval (TTI) for each of multiple different transmission resources of the respective Tx pool.

3. The method of claim 1, wherein assigning each of the plurality of RSUs to a corresponding Tx pool includes spatially multiplexing the Tx pools of the plurality of RSUs that are spaced apart by the coverage radius of the plurality of RSUs.

4. The method of claim 1, further comprising setting a hold-up probability parameter for SPS transmissions from the RSU for dedicated cellular vehicle-to-the-outside (C-V2X) networks to ensure continued use of allocated transmission resources.

5. The method of claim 1, further comprising allocating a plurality of transmission time slots to each of the plurality of RSUs, such that the plurality of RSUs are configured to perform a reselection to switch between the plurality of transmission time slots.

6. The method of claim 1, further comprising: Detect the traffic volume of each of the plurality of RSUs; as well as The size of the Tx pool allocated to each of the plurality of RSUs is adjusted based on the detected traffic volume, such that RSUs with larger traffic volumes are allocated more resources compared to RSUs with smaller traffic volumes.

7. The method of claim 1, further comprising: Detect the traffic density of each of the plurality of RSUs; as well as The size of the Tx pool allocated to each of the plurality of RSUs is adjusted based on the detected traffic volume, such that RSUs with higher traffic density are allocated more resources compared to RSUs with lower traffic density.

8. A system for allocating transmission resources for Automated Vehicle Medallions (AVMs), the system comprising: Multiple RSUs, wherein the multiple RSUs are configured to communicate with multiple vehicles; and AVM server, the AVM server being configured as follows: Each of the plurality of RSUs is assigned to a non-overlapping RSU transmission (Tx) pool for scheduling, such that none of the plurality of RSUs shares a common transmission time slot within the transmission schedule with another of the plurality of RSUs or with any of the vehicles. A shared vehicle Tx pool is allocated to the plurality of vehicles operating under the control of the AVM server, wherein the plurality of vehicles are restricted to transmission within the shared vehicle Tx pool to prevent overlapping transmissions with the RSU Tx pool, and Vehicle control messages are transmitted by each of the plurality of RSUs using an allocated RSU Tx pool to prevent overlap with transmissions from other RSUs and / or with the vehicle.

9. The system of claim 8, wherein the scheduling is semi-persistent scheduling (SPS), and the allocation of multiple Tx pools includes a repetition pattern defining a time transmission interval (TTI) for each of multiple different transmission resources for the respective Tx pool.

10. The system of claim 8, wherein assigning each RSU to a corresponding Tx pool comprises spatially multiplexing Tx pools in RSUs that are at least a plurality of RSU coverage radii apart.

11. The system of claim 8, wherein the AVM server is further configured to set a hold-up probability parameter for SPS transmissions from the RSU for dedicated cellular vehicle-to-the-outside (C-V2X) networks to ensure continued use of allocated transmission resources.

12. The system of claim 8, wherein the AVM server is further configured to allocate a plurality of transmission time slots to each of the plurality of RSUs, such that the plurality of RSUs are configured to perform a reselection to switch between the plurality of transmission time slots.

13. The system of claim 8, wherein the AVM server is further configured to: Detect traffic volume for each RSU; and The size of the Tx pool allocated to each of the plurality of RSUs is adjusted based on the detected traffic volume, such that RSUs with larger traffic volumes are allocated more resources compared to RSUs with smaller traffic volumes.

14. The system of claim 8, wherein the AVM server is further configured to: Detecting the traffic density of each of the plurality of RSUs; and The size of the Tx pool allocated to each of the plurality of RSUs is adjusted based on the detected traffic volume, such that RSUs with higher traffic density are allocated more resources compared to RSUs with lower traffic density.

15. A non-transitory computer-readable medium comprising instructions for allocating transport resources in an Automated Vehicle Formation (AVM) system, the instructions, when executed by one or more processors of an AVM server configured to communicate with a plurality of RSUs (Rolling Units) of a plurality of vehicles, causing the AVM server to perform operations including: Each of the plurality of RSUs is assigned to a non-overlapping RSU transport (Tx) pool for scheduling, such that none of the plurality of RSUs shares a common transport time slot within the transport schedule with another RSU or with any of the vehicles; A common vehicle Tx pool is allocated to vehicles operating in the AVM system, wherein the vehicles are restricted to transmission within the common vehicle Tx pool to prevent overlapping transmission with the RSU Tx pool. Vehicle control messages are transmitted by each of the plurality of RSUs using an allocated RSU Tx pool to prevent overlap with transmissions from other RSUs and / or with the vehicle.

Images