Roadside unit message scheduling and congestion control

Abstract

A method, a computing platform, a storage medium, and a system for providing congestion control in roadside unit message ("RSU message") scheduling. One aspect of the present disclosure relates to a method for providing congestion control in RSU message scheduling. Various aspects include measuring a channel busy rate by a PC5 access layer of a roadside unit, comparing the measured channel busy rate with one or more thresholds, and generating and transmitting RSU messages at a rate determined based on whether the measured channel busy rate is equal to or greater than the one or more thresholds.

Description

[Technical field]

[0001] [Background technology]

[0002] Cellular and wireless communication technologies have experienced explosive growth over the past few years and are used to support communications between a host of different types of communication devices, including smartphones, vehicle-based communication devices, infrastructure communication devices, network communication devices, etc. This growth is fueled by better communication hardware, larger networks, and more reliable protocols.

[0003] The ground transportation industry is increasingly seeking to leverage the growing capabilities of cellular and wireless communication technologies through the adoption of Intelligent Transportation Systems (ITS) technologies to enhance intercommunication and safety for both driver-operated and autonomous vehicles. The cellular vehicle-to-everything (C-V2X) protocols defined by the 3rd Generation Partnership Project (3GPP) support ITS technologies and serve as the basis for vehicles to communicate directly with communication devices around them.

[0004] C-V2X communication technology is expected to improve vehicle safety, manage traffic congestion, and support autonomous and semi-autonomous vehicles. Summary of the Invention [Means for solving the problem]

[0005] Various aspects include a method performed by a processor of a roadside unit to provide congestion control in roadside unit (RSU) message ("RSU message") scheduling. Various aspects include measuring a channel busy rate by a PC5 access layer of the roadside unit, comparing the measured channel busy rate to one or more thresholds, and generating and transmitting RSU messages at a rate determined based on whether the measured channel busy rate is equal to or greater than the one or more thresholds.

[0006] Some aspects include generating and transmitting an RSU message at a first rate in response to the measured channel busy rate being less than a first threshold, and generating and transmitting an RSU message at a second rate less frequently than the first rate in response to the measured channel busy rate being equal to or greater than the first threshold.

[0007] Some aspects include generating and transmitting different types of RSU messages at a type-specific first rate in response to the measured channel busy rate being less than a first threshold, and generating and transmitting different types of RSU messages at a type-specific second rate less frequent than the type-specific first rate in response to the measured channel busy rate being equal to or greater than the first threshold. In some aspects, the different types of RSU messages may include signal phase and timing (SPAT) messages, map data (MAP) messages, road sign information (RSI) messages, and road safety messages (RSM).

[0008] Some aspects may further include determining a rate for generating and transmitting the RSU message based on whether the measured channel busy rate is greater than or equal to one or more thresholds using a look-up table of rates and one or more thresholds correlating with the type of RSU message.

[0009] Some aspects may further include determining whether one or more event triggers for RSU message generation and transmission have occurred, and in response to determining that one or more event triggers for RSU message generation and transmission have occurred, generating and transmitting the RSU message at a rate determined based on whether a measured channel busy rate is greater than or equal to one or more thresholds, by generating and transmitting the RSU message at a rate determined based on whether a measured channel busy rate is greater than or equal to one or more thresholds.

[0010] Various aspects may include determining whether one or more event triggers for RSU message generation and transmission have occurred at the RSU, preventing RSU message generation and transmission in response to a determination that the one or more event triggers for RSU message generation and transmission have not occurred, and generating and transmitting an RSU message in response to a determination that the one or more event triggers for RSU message generation and transmission have occurred. In some aspects, generating and transmitting an RSU message in response to a determination that the one or more event triggers for RSU message generation and transmission have occurred may include measuring a channel busy rate by a PC5 access layer of the RSU, comparing the measured channel busy rate with one or more thresholds, and generating and transmitting the RSU message at a rate determined based on whether the measured channel busy rate is equal to or greater than one or more thresholds.

[0011] In some aspects, the one or more event triggers may be based at least in part on an RSU message type. In some aspects, the RSU message type may be an RSM and the event trigger may be detection of a presence of an object or participant in the vicinity of the RSU. In some aspects, the RSU message type may be an RSI and the event trigger may be detection of a vehicle approaching the RSU.

[0012] Various aspects include a roadside unit including a processor configured with processor-executable instructions for performing the operations of the methods summarized above. Various aspects also include a non-transitory processor-readable medium having stored thereon processor-executable instructions configured to cause a processor of the roadside unit to perform the operations of the methods summarized above.

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the claims and, together with the general description given above and the detailed description given below, serve to explain the features of the claims. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 is a system block diagram conceptually illustrating an example Cellular Vehicle-to-Everything (C-V2X) system. [Diagram 2] FIG. 2 is a system block diagram of a computing device suitable for use in a roadside unit, according to various embodiments. [Diagram 3] FIG. 2 is a component block diagram illustrating a communications device that may be configured to implement a method for providing congestion control in roadside unit message scheduling, according to various embodiments. [Figure 4] 1 is a block diagram illustrating an example of interaction between stack architecture layers in a transmitting communication device and a receiving communication device, according to various embodiments. [Diagram 5] 1 is a component block diagram illustrating a system for providing congestion control in RSU message scheduling, according to various embodiments. [Figure 6A] 1 is a process flow diagram illustrating a method for providing congestion control in RSU message scheduling, according to various embodiments. [Figure 6B]1 is a process flow diagram illustrating a method for providing congestion control in RSU message scheduling, according to various embodiments. [Figure 6C] 1 is a process flow diagram illustrating a method for providing congestion control in RSU message scheduling, according to various embodiments. [Figure 6D] 1 is a process flow diagram illustrating a method for providing congestion control in RSU message scheduling, according to various embodiments. [Figure 6E] 1 is a process flow diagram illustrating a method for providing congestion control in RSU message scheduling, according to various embodiments. [Figure 6F] 1 is a process flow diagram illustrating a method for providing congestion control in RSU message scheduling, according to various embodiments. [Figure 6G] 1 is a process flow diagram illustrating a method for providing congestion control in RSU message scheduling, according to various embodiments. [Figure 7] 1 is an example look-up table of RSU message transmission rates and one or more thresholds correlated with types of RSU messages, according to various embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Various aspects will now be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to specific examples and implementations are for illustrative purposes only and do not limit the scope of the claims.

[0016] C-V2X communication technology promises to improve vehicle safety, manage traffic congestion, and support autonomous and semi-autonomous vehicles. However, successful implementation of C-V2X communication technology requires solving the problem of communication congestion that would arise when many vehicles present on the road attempt to send basic safety messages at the same time (e.g., during commuter traffic) as the roadside unit is sending RSU messages. Various aspects provide a method for controlling or limiting communication congestion that may be implemented by each roadside unit based on measuring a channel busy rate in the PC5 access layer, and generating and transmitting RSU messages at a rate determined based on whether the measured channel busy rate is equal to or greater than one or more thresholds.

[0017] As used herein, the term "Roadside Unit" (or "RSU") refers to a highway computing system that includes a processor configured to perform C-V2X communications and operations described herein, and a wireless transceiver configured to broadcast RSU messages, including SPAT messages, MAP messages, RSI messages, and RSMs, to vehicles within a reception radius. The roadside unit may be part of a C-V2X communications network or system.

[0018] As used herein, the term "communications device" refers to any one or all of a cellular telephone, a smartphone, a portable computing device, a driver assistance system, a vehicle controller, a vehicle system controller, a vehicle communication system, an infotainment system, a vehicle telematics system or subsystem, a vehicle display system or subsystem, a vehicle data controller or router, and similar electronic devices that include a programmable processor and memory and circuitry configured to perform the operations described herein. While various aspects are particularly useful for in-vehicle communication systems and / or computing devices, the aspects are generally useful in any communication device that includes communication circuitry for communicating with a roadside unit and a processor that executes an application program.

[0019] The term "system on chip" (SoC) is used herein to refer to a set of interconnected electronic circuits, typically including, but not limited to, one or more processors, memory, and communication interfaces. An SoC may include a variety of different types of processors and processor cores, such as general-purpose processors, central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), accelerated processing units (APUs), subsystem processors, auxiliary processors, single-core processors, and multi-core processors. An SoC may further embody other hardware and combinations of hardware, such as field programmable gate arrays (FPGAs), configuration and status registers (CSRs), application specific integrated circuits (ASICs), other programmable logic devices, discrete gate logic, transistor logic, registers, performance monitoring hardware, watchdog hardware, counters, and time bases. An SoC may be an integrated circuit (IC) configured such that the components of the IC reside on the same substrate, such as a single semiconductor material (e.g., silicon).

[0020] The term "system in package" (SIP) is used herein to refer to a single module or package that may include multiple resources, computing units, cores, and / or processors on two or more IC chips, substrates, or SoCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged in a unifying substrate. A SIP may also include multiple independent SoCs packaged in close proximity coupled to each other via high-speed communication circuits, such as on a single motherboard or within a single mobile communication device. The proximity of the SoCs facilitates high-speed communication and sharing of memory and resources.

[0021] The term "multi-core processor" is used herein to refer to a single IC chip or chip package that includes two or more independent processing cores (e.g., CPU cores, IP cores, GPU cores, etc.) configured to read and execute program instructions. An SoC may include multiple multi-core processors, and each processor in an SoC may be referred to as a core. The term "multiprocessor" may be used herein to refer to a system or device that includes two or more processing units configured to read and execute program instructions.

[0022] A method, computing platform, storage medium, and system for providing congestion control in RSU message scheduling are disclosed. In various embodiments, each roadside unit may measure a channel busy rate by the roadside unit's PC5 access layer, compare the measured channel busy rate with one or more thresholds, and generate and transmit RSU messages at a rate determined based on whether the measured channel busy rate is equal to or greater than the one or more thresholds. The channel busy rate may be determined as a portion of sub-channels in a resource pool whose S-RSSI measured by an ITS station exceeds a (pre-)configured threshold sensed over the last 100 milliseconds (ms), which is access layer dependent and is a definition specified in ETSI TS 136 214. The measured channel busy rate (e.g., CBRmeasured) may be a channel busy rate measured by the roadside unit's PC5 access layer. The rate for generating and transmitting RSU messages may be determined by a processor of the roadside unit using a look-up table function based on the measured channel busy rate or a threshold that the measured channel busy rate exceeds.

[0023] Various embodiments may enable RSU message generation and transmission (e.g., broadcast transmission) based on a measured channel busy rate. The measured channel busy rate may indicate the RSU message load on the PC5 interface and the possibility of potential congestion or collision among RSU messages sent on the PC5 interface. For example, a low measured channel busy rate may indicate a low possibility of congestion or collision in RSU messages, and a high measured channel busy rate may indicate a high RSU message load and thus a high possibility of potential congestion or collision of RSU messages. A high measured channel busy rate may indicate a need to reduce the RSU message generation rate.

[0024] In various embodiments, the measured channel busy ratio may be compared to one or more thresholds, such as one, two, three, four, or more thresholds. As an example, the one or more thresholds may be one or more ranges of channel busy ratios. In various embodiments, the one or more thresholds may be used as an index or reference in a lookup table that correlates the one or more thresholds with a transmission rate at which RSU messages may be generated and transmitted by a roadside unit to control congestion on the frequency used to broadcast the RSU messages. As an example, the lookup table may be a table of rates and one or more thresholds that correlate with RSU message types. In an implementation where there are two or more thresholds, the message generation and transmission rates that correlate with each of the two or more thresholds may be configured such that messages are generated less frequently when the measured channel busy ratio threshold increases. In various embodiments, the message generation and transmission rates may be different for different types of RSU messages that correlate with the same threshold. The types of RSU messages may include signal phase and timing (SPAT) messages, map data (MAP) messages, road sign information (RSI) messages, and road safety messages (RSM).

[0025] In various embodiments, the roadside unit may generate and transmit RSU messages at a rate determined based on the measured channel busy rate being equal to or greater than one or more thresholds. For example, the RSU messages may be generated and transmitted at a rate listed in a lookup table corresponding to a rate correlated with a threshold range determined as the measured channel busy rate decreases. Reducing the rate of RSU message generation and transmission when the measured channel busy rate increases may reduce congestion on the PC5 interface with the roadside unit operating independently (i.e., without the need for a centralized congestion control mechanism). Reducing the rate of RSU message generation and transmission when the measured channel busy rate increases may enable the roadside unit to save energy by generating and transmitting fewer RSU messages when the likelihood of potential congestion on the PC5 interface is higher.

[0026] Various embodiments may include a method for achieving RSU message congestion control by restricting transmission of RSU messages in response to the presence of one or more event triggers regarding whether a need for an RSU message exists (e.g., whether a vehicle is present to receive the message). In various embodiments, the roadside unit may monitor the state of the roadside unit and / or the vicinity around the roadside unit, such as using the roadside unit's sensors (e.g., radar, LIDAR, camera, etc.) and / or detection of messages from other entities, such as monitoring BSMs transmitted by vehicles approaching the roadside unit. For example, the roadside unit may detect the presence of an object (e.g., vehicle, obstacle in the road, etc.) or participant (e.g., pedestrian, bicycle, animal, etc.) in the vicinity of the roadside unit, which may be an event trigger if its presence provides a reason for sending an RSU message or an appropriate recipient for such a message. As another example, the roadside unit may detect a vehicle approaching the roadside unit, which may be an event trigger, such as when the roadside unit has a message to send to any vehicles in the vicinity. For example, if a roadside unit has an RSI message to send about a road sign, the approach of a vehicle that may receive the RSI message may be an event trigger for broadcasting the message. In various embodiments, the event trigger may be based at least in part on the RSU message type. For example, the event trigger for the RSI message may be different from the event trigger for the RSM. As a specific example, the detection of the presence of an object or participant in the vicinity of the roadside unit may be an event trigger for the RSM, and the detection of a vehicle approaching the roadside unit may be an event trigger for the RSI message.

[0027] In various embodiments, the roadside unit may prevent generation and transmission of an RSU message until it is determined that one or more event triggers have occurred. In various embodiments, the roadside unit may determine whether one or more event triggers for RSU message generation and transmission have occurred at the roadside unit. In response to determining that one or more event triggers for RSU message generation and transmission have not occurred, the roadside unit may prevent RSU message generation and transmission. In response to determining that one or more event triggers for RSU message generation and transmission have occurred, the roadside unit may generate and transmit an RSU message. In various embodiments, the rate at which RSU messages are generated and transmitted in response to detection of one or more event triggers may be based at least in part on a measured channel busy rate, as described herein.

[0028] In various embodiments, prevention of RSU message generation and transmission may be RSU message type specific. For example, RSI message generation and transmission may be prevented until it is determined that an event trigger related to the RSI message has occurred (e.g., a vehicle that may receive or should receive the RSI message is approaching). Some RSM messages may be generated and transmitted only in response to detection of an associated event trigger. For example, a road obstacle RSM may be generated and transmitted by the roadside unit in response to determining that an object or participant is present in a road near the roadside unit. Limiting RSU message generation and transmission until an event trigger occurs may reduce the contribution of RSU messages to congestion on the PC5 interface because unnecessary messages will not be transmitted. Limiting RSU message generation and transmission until an event trigger occurs may also enable the roadside unit to save energy by not generating and transmitting unnecessary RSU messages.

[0029] 1 illustrates an exemplary C-V2X system 100 suitable for implementing various embodiments. The C-V2X system 100 may include an in-vehicle communication device 102 configured to exchange wireless communications with other communication devices around a vehicle 112 in which the in-vehicle communication device 102 is located. The vehicle 112 may be any type of vehicle, such as an autonomous vehicle (e.g., a driverless vehicle), a semi-autonomous vehicle, a remotely operated vehicle, etc. The in-vehicle communication device 102 may be a computing device on-board the vehicle 112 or may be a mobile communication device (e.g., a smartphone, a laptop, etc.) temporarily located in the vehicle 112. The C-V2X system 100 may include various devices in addition to the in-vehicle communication device 102, such as another in-vehicle communication device 103 of another vehicle 114, transmitters 106 and 107 connected to roadside units 108, 109, a communication device 105 (e.g., a smartphone, laptop, etc.), a cellular tower or base station 113 connected to a network 115 and a network server 116. The various components of the C-V2X system 100 may be configured to operate as an ITS network to support intercommunication and safety for land-based vehicles.

[0030] The in-vehicle communication device 102 may be configured to perform vehicle-to-vehicle (V2V) communication, vehicle-to-infrastructure (V2I) communication, and vehicle-to-pedestrian (V2P) communication. For example, the in-vehicle communication device 102 may establish a device-to-device (D2D) link with another in-vehicle communication device 103 of another vehicle 114 to exchange V2V communication. As another example, the in-vehicle communication device 102 may establish a D2D link with transmitters 106 and 107 connected to roadside units 108, 109 to exchange V2I communication. As a further example, the in-vehicle communication device 102 may establish a D2D link with a communication device 105, such as a smartphone, laptop, etc., of a user 111 to exchange V2P communication. The D2D links between the in-vehicle communication device 102, the in-vehicle communication device 103, the communication device 105, and the roadside units 108, 109 may be communication links established independent of a cellular network, such as links established in a dedicated ITS 5.9 gigahertz (GHz) spectrum. As a particular example, the D2D links may be dedicated short range communication (DSRC) links, LTE Direct (LTE-D) links, or any other type of link supporting direct device communication.

[0031] The in-vehicle communication device 102 may be configured to perform vehicle-to-network (V2N) communications. For example, the in-vehicle communication device 102 may establish a network-to-device link with a cellular tower or base station 113 connected to a network 115 and a network server 116 to exchange V2N communications. The network-to-device link may include, without limitation, an uplink (or reverse link), a downlink (or forward link), a bidirectional link, etc. The network-to-device link may be established in accordance with mobile broadband systems and technologies, such as third generation wireless mobile communications technologies (3G) (e.g., Global System for Mobile Communications (GSM) Evolution (EDGE) systems, Code Division Multiple Access (CDMA) 2000 systems, etc.), fourth generation wireless mobile communications technologies (4G) (e.g., Long Term Evolution (LTE) systems, LTE-Advanced systems, Mobile Worldwide Interoperability for Microwave Access (Mobile WiMAX) systems, etc.), fifth generation wireless mobile communications technologies (5G) (e.g., 5G New Radio (5G NR) systems, etc.).

[0032] In some embodiments, the in-vehicle communication device 102 and the cellular tower or base station 113 may include 5G NR functionality with an air interface based on Orthogonal Frequency Division Multiplexing (OFDM). The functionality of the cellular tower or base station 113 may be similar in one or more aspects to (or may be incorporated within) the functionality of a Cellular IoT (CIoT) base station (C-BS), a NodeB, an evolved NodeB (eNodeB), a Radio Access Network (RAN) access node, a Radio Network Controller (RNC), a base station (BS), a macro cell, a macro node, a Home eNB (HeNB), a femto cell, a femto node, a pico node, or some other suitable entity based on a radio technology used to establish a network-to-device link between the cellular tower or base station 113 and the in-vehicle communication device 102. The cellular tower or base station 113 may be in communication with a respective router that may be connected to a network 115 (e.g., a core network, the Internet, etc.). Using a connection to a cellular tower or base station 113, the in-vehicle communication device 102 may exchange data with a network 115, as well as devices connected to the network 115, such as a network server 116 or any other communication device connected to the network 115.

[0033] FIG. 2 is a component block diagram of an exemplary roadside unit 200, such as a base station, a smart road sign, etc., suitable for use in various implementations. Such a roadside unit may include at least the components shown in FIG. 2. With reference to FIGS. 1-2, the roadside unit 200 may typically include a processor 201 coupled to a volatile memory 202 and a large capacity non-volatile memory, such as a disk drive 203. The roadside unit 200 may include one or more antennas 207 for sending and receiving wireless RSU messages (e.g., signal phase and timing (SPAT) messages, map data (MAP) messages, road sign information (RSI) messages, and road safety messages (RSM)). The roadside unit 200 may also include a peripheral memory access device, such as a floppy disk drive, a compact disk (CD) or a digital video disk (DVD) drive 206, coupled to the processor 201. The roadside unit 200 may also include a network access port 204 (or interface) coupled to the processor 201 for establishing a data connection with a network, such as the Internet or a local area network coupled to other system computers and servers. The roadside unit 200 may include additional access ports, such as USB, Firewire, Thunderbolt, etc., for coupling to peripherals, external memory, or other devices.

[0034] Various embodiments may be implemented on several single processor and microprocessor communication devices, including SoCs and / or SIPs. Figure 3 shows an exemplary SIP 300 architecture that may be configured to implement a method for providing congestion control in roadside unit message scheduling according to various embodiments. With reference to Figures 1-3, the exemplary SIP 300 architecture may be implemented in any SIP and may be used in any communication device (e.g., in-vehicle communication device 102, in-vehicle communication device 103, roadside units 108, 109, 200, etc.) that implements various embodiments.

[0035] In the example shown in FIG. 3, the SIP 300 includes three SoCs 302, 304, 371. In some embodiments, the first SoC 302 may operate as a central processing unit (CPU) of a communication device, executing instructions of a software application program by performing arithmetic, logic, control, and input / output (I / O) operations specified by the instructions. In some embodiments, the second SoC 304 may operate as a dedicated processing unit. For example, the second SoC 304 may operate as a dedicated 5G processing unit responsible for managing high-capacity, high-speed (e.g., 5 Gbps, etc.), and / or very short wavelength (e.g., 28 GHz mmWave spectrum, etc.) communications to support 5G NR functionality with an OFDM-based air interface. In some embodiments, the third SoC 371 may operate as a dedicated processing unit. For example, the third SoC 371 may operate as a dedicated C-V2X processing unit responsible for managing V2V, V2I, and V2P communications over D2D links, such as a D2D link established in a dedicated ITS 5.9 GHz spectrum communications. The organization of SoCs and functions shown in FIG. 3 is a non-limiting example of a SIP, as other architectures and organization of functions among SoCs are contemplated, including fewer or more SoCs.

[0036] 3, the first SOC 302 includes a digital signal processor (DSP) 310, a modem processor 312, a graphics processor 314, an application processor 316, one or more coprocessors 318 (e.g., vector coprocessors) connected to one or more of the processors, a memory 320, custom circuitry 322, system components and resources 324, an interconnect / bus module 326, one or more temperature sensors 330, and a thermal management unit 332. The second SoC 304 includes a 5G modem processor 352, a power management unit 354, an interconnect / bus module 364, multiple mmWave transceivers 356, a memory 358, and various additional processors 360, such as application processors, packet processors, etc. The third SoC 371 includes an ITS modem processor 372, a power management unit 374, an interconnect / bus module 384, multiple transceivers 376 (e.g., transceivers configured to operate in the dedicated ITS 5.9 GHz spectrum), a memory 378, and various additional processors 380, such as an application processor, a packet processor, etc.

[0037] Each processor 310, 312, 314, 316, 318, 352, 360, 372, 380 may include one or more cores, and each processor / core may perform operations independent of the other processors / cores. For example, the first SoC 302 may include a processor that runs a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that runs a second type of operating system (e.g., MICROSOFT WINDOWS 10). Additionally, any or all of the processors 310, 312, 314, 316, 318, 352, 360, 372, 380 may be included as part of a processor cluster architecture (e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).

[0038] The first, second, and third SOCs 302, 304, 371 may include various system components, resources, and custom circuits for managing sensor data, analog-to-digital conversion, wireless data transmission, and performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for rendering in a web browser or other display application. For example, the system components and resources 324 of the first SoC 302 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components used to support processors and software clients running on the wireless devices. The system components and resources 324 and / or custom circuits 322 may also include circuits for interfacing with peripheral devices, such as cameras, electronic displays, wireless communication devices, external memory chips, autonomous driving systems, traffic sign recognition systems, parking assistance systems, telematics units, tire pressure monitoring systems, collision warning systems, display systems, ADAS, vehicle buses, etc.

[0039] The first, second, and third SoCs 302, 304, 371 may communicate via one or more interconnect / bus modules 350. The processors 310, 312, 314, 316, 318 may be interconnected to one or more memory elements 320, system components and resources 324, and custom circuitry 322, as well as a thermal management unit 332, via an interconnect / bus module 326. Similarly, the processors 352, 360 may be interconnected to a power management unit 354, an mmWave transceiver 356, a memory 358, and various additional processors 360, via an interconnect / bus module 364. Similarly, the processors 372, 380 may be interconnected to a power management unit 374, a transceiver 376, a memory 378, and various additional processors 380, via an interconnect / bus module 384. The interconnect / bus modules 326, 350, 364, 384 may include arrays of reconfigurable logic gates and / or may implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications may be provided by advanced interconnects, such as high-performance networks on chips (NoCs).

[0040] The first, second, and / or third SoCs 302, 304, 371 may further include input / output modules (not shown) for communicating with resources external to the SoC that may be shared by two or more of the internal SoC processors / cores.

[0041] In addition to the SIP 300 discussed above, various aspects may be implemented in a wide variety of communication devices, which may include a single processor, multiple processors, multi-core processors, or any combination thereof.

[0042] 4 illustrates the interaction between stack architecture layers in a transmitting roadside unit 401 and a receiving vehicle on-board unit 415 at a PC5 interface between the roadside unit and a vehicle on-board unit used for V2X sidelink communications, according to various embodiments. With reference to FIGS. 1-4, the roadside unit 401 and the vehicle on-board unit 415 may be configured to exchange information using C-V2X communications.

[0043] Each roadside unit 401 and vehicle on-board unit 415 may include one or more upper data layers 402 configured to exchange data with a modem stack (or radio protocol stack) 406. By way of example, the upper data layers 402 may be one or more ITS layers, one or more service layers, one or more messaging layers, application layers, etc. By way of example, the functions performed within the upper data layers 402 may include applications 403 (e.g., ITS safety-critical applications, ITS non-safety-critical applications, messaging applications, etc.), security services 404, Internet Protocol (IP) services 405 (e.g., Transmission Control Protocol (TCP) services, Uniform Datagram Protocol (UDP) services, etc.), other upper data layer functions, or any combination thereof. In some embodiments, the upper data layers 402 and modem stacks 406 on the roadside unit 401 and the vehicle on-board unit 415 may be running on the same processor of the roadside unit 401 and the vehicle on-board unit 415. In some embodiments, the upper data layer 402 and the modem stack 406 on the roadside unit 401 and the vehicle on-board unit 415 may be running on different processors on the roadside unit 401 and the vehicle on-board unit 415. As an example, the upper data layer 402 may be running on an application processor (e.g., application processor 316) and the modem stack 406 may be running on a modem processor (e.g., modem processor 312, modem processor 352, modem processor 372). Although shown in FIG. 4 as being on the same roadside unit 401 and vehicle on-board unit 415, in some embodiments the upper data layer 402 may be running on processors of separate communication devices.For example, the upper data layer 402 may be running on a processor of the ADAS, and the modem stack 406 may be running on a processor of a SIP (e.g., SIP 300) connected to the processor of the ADAS.

[0044] In some embodiments, the modem stack 406 may include a Packet Data Convergence Protocol (PDCP) layer 407, an RLC layer 408, a Medium Access Control (MAC) layer 409, and a Physical (PHY) layer 410. The PHY 410 may be the lowest layer of the modem stack 406, and the PDCP layer 407 may be the highest layer of the modem stack 406.

[0045] The PDCP layer 407 may process PDCP packets and may provide multiplexing, compression, encryption, and / or integrity protection between different radio bearers and logical channels for the PDCP packets. The PDCP layer 407 may receive packets from and output packets to the upper data layer 402. The PDCP layer 407 may receive packets from and output packets to the RLC layer 408.

[0046] The RLC layer 408 may process RLC packets and provide error correction, concatenation, segmentation, reassembly, reordering, duplicate detection, error detection, and / or error recovery for the RLC packets. Additionally, the RLC layer 408 may buffer the RLC packets in a receive buffer to support reordering, to wait for missing RLC packets, etc. The RLC layer 408 may operate in different modes, such as acknowledged mode (AM), unacknowledged mode (UM), and transparent mode (TM). The RLC layer 408 may receive packets from the PDCP layer 407 and may output packets to the PDCP layer 407. The RLC layer 408 may receive packets from the MAC layer 409 and may output packets to the MAC layer 409.

[0047] The MAC layer 409 may process MAC packets and may provide frame definition / recognition, addressing, and / or error protection for the MAC packets. Additionally, the MAC layer may be responsible for hybrid automatic repeat request (HARQ) operations. The MAC layer 409 may receive packets from the RLC layer 408 and may output packets to the RLC layer 408. The MAC layer 409 may receive packets from the PHY layer 410 and may output packets to the PHY layer 410.

[0048] The PHY layer 410 may process PHY packets and provide a communication interface between hardware supporting the physical transmission medium (e.g., transceiver, antenna, etc.) and upper layers of the modem stack 406. The PHY layer 410 may convert PHY packets into a bit stream for transmission and / or convert a received bit stream into PHY packets. The PHY layer 410 provides encoding, transmission, reception, and / or decoding for the PHY packets. The PHY layer 410 may receive packets from the MAC layer 409 and output packets to the MAC layer 409.

[0049] Packets transferred to / from higher data layers of the modem stack 406 may be referred to as service data units (SDUs) within a given layer, and packets transferred to / from lower layers of the modem stack 406 may be referred to as protocol data units (PDUs). For example, packets received from the PDCP layer 407 into the RLC layer 408, as well as packets transferred from the RLC layer 408 to the PDCP layer 407, may be referred to as RLC SDUs. Similarly, packets received from the MAC layer 409 into the RLC layer 408, as well as packets transferred from the RLC layer 408 to the MAC layer 409, may be referred to as RLC PDUs.

[0050] Just as a PDU of a layer may be an SDU of the next lower layer, an SDU of a layer may be a PDU of the next higher layer. For example, a PDCP PDU sent from the PDCP layer 407 to the RLC layer 408 may be referred to as an RLC SDU when received by the RLC layer 408. Similarly, a MAC SDU sent from the MAC layer 409 to the RLC layer 408 may be referred to as an RLC PDU when received by the RLC layer 408.

[0051] A layer in a protocol stack may convert PDUs to SDUs and SDUs to PDUs by performing various operations assigned to that layer on the packets. For example, an RLC SDU may be segmented by the RLC layer 408 to convert the RLC SDU into one or more RLC PDUs. Similarly, multiple received RLC PDUs may be reordered and reassembled to convert multiple received RLC PDUs into RLC SDUs. Furthermore, a layer may add data to a packet to convert an SDU into a PDU, or a layer may remove data from a packet to convert a PDU into an SDU. For example, the RLC layer 408 may add a packet header / footer to an RLC SDU to convert an RLC SDU into an RLC PDU. Similarly, the RLC layer 408 may remove a packet header / footer from an RLC PDU to convert an RLC PDU into an RLC SDU.

[0052] Referring to FIG. 4, the following is an example of packet processing when one communication device 401 sends a communication that is received by another communication device 415.

[0053] An application in the upper data layer 402 of the transmitting communication device 401 may generate packets of a message 420 for transmission to an application 403 of the receiving communication device. The packets of the message 420 may be sent from the upper data layer 402 to the PDCP layer 407 of the modem stack 406 on the transmitting communication device 401.

[0054] The PDCP layer 407 may receive the packets of message 420 as PDCP SDUs and convert the PDCP SDUs into PDCP PDUs 421. The PDCP layer 407 may forward the PDCP PDUs 421 to the underlying RLC layer 408.

[0055] The RLC layer 408 may receive the PDCP PDU 421 as an RLC SDU and may convert the RLC SDU (i.e., the PDCP PDU 421) into one or more RLC PDUs 422, for example, by adding an RLC packet header / footer and / or adding segmentation. As an example, when the RLC SDU (i.e., the PDCP PDU 421) is larger than the maximum RLC PDU size, segmentation may be required to split the RLC SDU into multiple RLC PDUs 422. When segmentation is added to convert the RLC SDU into multiple RLC PDUs 422, each RLC PDU 422 created may be associated with a single RLC SDU (i.e., a single PDCP PDU 421). Additionally, the RLC layer 408 may add a sequence number to the one or more RLC PDUs 422. The sequence number may indicate the order of the one or more RLC PDUs 422. The RLC layer 408 may forward one or more RLC PDUs 422 to the lower MAC layer 409 .

[0056] The MAC layer 409 may receive one or more RLC PDUs 422 as one or more MAC SDUs. The MAC layer 409 may convert one or more MAC SDUs (i.e., one or more RLC PDUs 422) into one or more MAC PDUs 424. For example, the MAC layer 409 may convert one or more MAC SDUs (i.e., one or more RLC PDUs 422) by adding a HARQ indicator to the MAC SDU (i.e., one or more RLC PDUs 422) to support HARQ operation. The MAC layer 409 may forward the one or more MAC PDUs 424 to the lower PHY layer 410.

[0057] The PHY layer 410 may receive one or more MAC PDUs as one or more PHY SDUs. The PHY layer 410 may convert one or more PHY SDUs (i.e., one or more MAC PDUs 424) into a PHY PDU bitstream for transmission to the receiving communication device 415 as a flow 426.

[0058] The PHY layer 410 of the receiving communication device 415 may receive the PHY PDU bitstream flow 426 and convert the PHY PDU bitstream flow 426 into one or more PHY SDUs 428. The PHY layer 408 may forward the one or more PHY SDUs 428 to the upper MAC layer 409.

[0059] The MAC layer 409 may receive one or more PHY SDUs 428 as one or more MAC PDUs. The MAC layer 409 may convert one or more MAC PDUs (i.e., one or more PHY SDUs 428) into one or more MAC SDUs 430. Additionally, the MAC layer 409 may perform HARQ operations (e.g., acknowledgments, retransmission requests, etc.) and remove HARQ data from the MAC PDUs. The MAC layer 409 may forward one or more MAC SDUs 430 to the upper RLC layer 408.

[0060] The RLC layer 408 may receive one or more MAC SDUs 430 as one or more RLC PDUs. The RLC layer 408 may convert one or more RLC PDUs (i.e., one or more MAC SDUs 430) into a single RLC SDU 432. For example, converting one or more RLC PDUs (i.e., one or more MAC SDUs 430) into a single RLC SDU 432 may include removing any RLC headers, removing any RLC footers, combining / concatenating multiple RLC PDUs associated together into the same RLC SDU, and reordering the RLC PDUs as necessary. Additionally, the RLC layer 408 may buffer one or more RLC PDUs in a receive buffer to support reordering, to wait for missing RLC PDUs, etc. The RLC layer 408 may forward the RLC SDUs 432 to the upper PDCP layer 407.

[0061] The PDCP layer 407 may receive the RLC SDU 432 as a PDCP PDU and convert the PDCP PDU (i.e., the RLC SDU 432) into a PDCP SDU 434. The PDCP SDU 434 at the receiving communication device 415 may correspond to a packet of the message 420 originated by the transmitting communication device 401. The PDCP layer 407 may forward the PDCP SDU 434 to the upper data layer 402 and the application 403.

[0062] 5 is a component block diagram illustrating a system 500 configured to provide congestion control in roadside unit message (RSU message) scheduling, according to various embodiments. In some implementations, the system 500 may include one or more roadside units 502 and / or one or more vehicle on-board units 504. With reference to FIGS. 1-5, the roadside units 502 may include communication devices (e.g., in-vehicle communication device 102, in-vehicle communication device 103, SIP 300, communication devices 401, 415, communication device 105, etc.), transmitters 106, 107, roadside units 108, 109, cellular tower or base station 113, and / or network server 116. The remote platform 504 may include communication devices (e.g., in-vehicle communication device 102, in-vehicle communication device 103, SIP 300, communication devices 401, 415, communication device 105, etc.), transmitters 106, 107, roadside units 108, 109, cellular towers or base stations 113, and / or network servers 116).

[0063] The roadside unit 502 may be configured by machine-readable instructions 506. The machine-readable instructions 506 may include one or more instruction modules. The instruction modules may include computer program modules. The instruction modules may include one or more of a channel ratio measurement module 508, a channel ratio comparison module 510, an RSU message generation module 512, a type generation module 514, a rate determination module 516, and / or other instruction modules.

[0064] The channel ratio measurement module 508 may be configured to measure a channel busy ratio by the PC5 access layer of the roadside unit. The channel busy ratio may be determined as the portion of sub-channels in the resource pool whose S-RSSI measured by the ITS station is sensed over the last 100 milliseconds (ms) and exceeds a (pre)configured threshold, which is access layer dependent and is a definition specified in ETSI TS 136 214. The measured channel busy ratio (e.g., CBRmeasured) may be the channel busy ratio measured by the PC5 access layer of the roadside unit.

[0065] The channel ratio comparison module 510 may be configured to compare the measured channel busy ratio to one or more thresholds. In various embodiments, the measured channel busy ratio may be compared to one or more thresholds, such as one, two, three, four, or more thresholds. In various embodiments, the one or more thresholds may be reflected in a lookup table that correlates the one or more thresholds with transmission rates for various types of RSU messages.

[0066] The RSU message generating module 512 may be configured to generate and transmit RSU messages at a rate determined based on whether the measured channel busy rate is equal to or greater than one or more thresholds. In various embodiments, the roadside unit may generate and transmit RSU messages at a rate determined based on the measured channel busy rate being equal to or greater than one or more thresholds. For example, the RSU messages may be generated and transmitted at a rate listed in a look-up table corresponding to a rate correlated with a threshold range determined to be below which the measured channel busy rate falls. The RSU message generating module 512 may be configured to generate and transmit RSU messages at a first rate in response to the measured channel busy rate being less than a first threshold. The RSU message generating module 512 may be configured to generate and transmit RSU messages at a second rate less frequently than the first rate in response to the measured channel busy rate being equal to or greater than a threshold. The RSU message generating module 512 may be configured to prevent generation and transmission of RSU messages until it is determined that one or more event triggers have occurred, or to generate and transmit RSU messages in response to detection of one or more event triggers. The RSU message generating module 512 may be configured to determine whether one or more event triggers for the RSU message have occurred at the roadside unit. In response to determining that one or more event triggers for the RSU message have not occurred, the RSU message generating module 512 may not transmit the RSU message. In response to determining that one or more event triggers for the RSU message have occurred, the RSU message generating module 512 may generate and transmit the RSU message. In various embodiments, the rate at which the RSU message is generated and transmitted in response to determining that one or more event triggers for the RSU message have occurred may be based at least in part on a measured channel busy rate.

[0067] The type generation module 514 may be configured to generate and transmit different types of RSU messages at a type-specific first rate in response to the measured channel busy rate being less than a first threshold. In various embodiments, the message generation and transmission rates may be different for different types of RSU messages that correlate with the same threshold. As non-limiting examples, the different types of RSU messages may include signal phase and timing messages, map data messages, RSI messages, and road safety messages. The type generation module 514 may be configured to generate and transmit different types of RSU messages at a type-specific second rate that is less frequent than the type-specific first rate in response to the measured channel busy rate being equal to or greater than the threshold.

[0068] The rate determination module 516 may be configured to determine a rate for generating and transmitting an RSU message based on whether a measured channel busy rate is equal to or greater than one or more thresholds using a lookup table of rates and one or more thresholds that correlate with a type of RSU message. The rate for generating and transmitting an RSU message may be determined by a processor of the roadside unit using a lookup table function based on the measured channel busy rate or a threshold that the measured channel busy rate exceeds.

[0069] The event trigger module 517 may be configured to determine whether one or more event triggers for an RSU message have occurred. The event trigger module 517 may be configured to monitor the state of the roadside unit and / or the vicinity around the roadside unit. The event trigger module 517 may be configured to monitor the state of the roadside unit and / or the vicinity around the roadside unit using sensors (e.g., radar, LIDAR, camera, etc.) of the roadside unit and / or detection of messages from other entities (e.g., BSM from a vehicle approaching the roadside unit). For example, the event trigger module 517 may be configured to detect the presence of an object (e.g., vehicle, obstacle, etc.) or participant (e.g., pedestrian, bicycle, animal, etc.) in the road in the vicinity of the roadside unit, which may be an event trigger for the RSM. As another example, the event trigger module 517 may be configured to detect a vehicle approaching the roadside unit, which may be an event trigger for the RSU message. In various embodiments, the event trigger may be based at least in part on the RSU message type. For example, an event trigger for an RSI message may be different from an event trigger for an RSM. As a particular example, detection of the presence of an object or participant in the vicinity of a roadside unit may be an event trigger for an RSM, and detection of a vehicle approaching a roadside unit may be an event trigger for an RSI message.

[0070] 6A, 6B, 6C, 6D, 6E, 6F, and 6G are process flow diagrams illustrating a method for providing congestion control in RSU message scheduling according to various embodiments. The method operations illustrated in FIGS. 6A, 6B, 6C, 6D, 6E, 6F, and 6G presented below are intended to be illustrative. In some embodiments, the method may be accomplished with one or more additional operations not described and / or without one or more of the operations discussed. Furthermore, the order of the operations of the method as illustrated in FIGS. 6A, 6B, 6C, 6D, 6E, 6F, and 6G and described below is not intended to be limiting.

[0071] In some embodiments, the methods as shown in Figures 6A, 6B, 6C, 6D, 6E, 6F, and 6G may be implemented in one or more processing devices (e.g., digital processors, analog processors, digital circuits designed to process information, analog circuits designed to process information, state machines, and / or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices that perform some or all of the operations of the methods as shown in Figures 6A, 6B, 6C, 6D, 6E, 6F, and 6G in response to instructions electronically stored on an electronic storage medium. The one or more processing devices may include one or more devices configured to be specifically designed to perform one or more of the operations of the methods as shown in Figures 6A, 6B, 6C, 6D, 6E, 6F, and 6G via hardware, firmware, and / or software. For example, with reference to Figures 1-6G, the operations of the methods shown in Figures 6A, 6B, 6C, 6D, 6E, 6F, and 6G may be performed by a processor (e.g., 201, 300, 302, 304, 371, 316, 318, 380, etc.) of a roadside unit (e.g., 108, 109, 200, 502).

[0072] FIG. 6A illustrates a method 600 according to one or more implementations.

[0073] In block 602, the processor of the roadside unit may measure a channel busy rate by the PC5 access layer of the roadside unit. In various embodiments, each roadside unit may measure a channel busy rate by the PC5 access layer of the roadside unit, compare the measured channel busy rate with one or more thresholds, and generate and transmit RSU messages at a rate determined based on whether the measured channel busy rate is equal to or greater than the one or more thresholds. The channel busy rate may be determined as a portion of sub-channels in the resource pool whose S-RSSI measured by the ITS station exceeds a (pre-)configured threshold sensed over the last 100 milliseconds (ms), which is access layer dependent and is a definition specified in ETSI TS 136 214. The measured channel busy rate (e.g., CBRmeasured) may be a channel busy rate measured by the PC5 access layer of the roadside unit.

[0074] In block 604, the processor of the roadside unit may compare the measured channel busy ratio to one or more thresholds. In various embodiments, the measured channel busy ratio may be compared to one or more thresholds, such as one, two, three, four, or more thresholds. As an example, the one or more thresholds may be one or more ranges of channel busy ratios. In various embodiments, the one or more thresholds may be indicated in a lookup table. The lookup table may correlate the one or more thresholds with a transmission rate to use for generating and transmitting the RSU message. As an example, the lookup table may be a lookup table of rates and one or more thresholds correlating with a type of RSU message.

[0075] In block 606, the processor of the roadside unit may generate and transmit RSU messages at a rate determined based on whether the measured channel busy rate is equal to or greater than one or more thresholds. In various embodiments, the roadside unit may generate and transmit RSU messages at a rate determined based on the measured channel busy rate being equal to or greater than one or more thresholds. For example, the RSU messages may be generated and transmitted at a rate listed in a lookup table corresponding to a rate correlated with a threshold range determined as the measured channel busy rate decreases. Reducing the rate of RSU message generation and transmission when the measured channel busy rate increases may reduce the roadside unit's contribution to potential congestion on the PC5 interface when the potential congestion is more likely. Reducing the rate of RSU message generation and transmission when the measured channel busy rate increases may enable the roadside unit to conserve energy by generating and transmitting fewer RSU messages when the potential congestion on the PC5 interface is more likely.

[0076] 6B illustrates a method 650 according to one or more implementations. Method 650 may be performed together with method 600. The operations of method 650 may be operations performed to generate and transmit RSU messages at a rate determined based on whether a measured channel busy rate is greater than or equal to one or more thresholds.

[0077] At block 608, the processor of the roadside unit may generate and transmit an RSU message at a first rate in response to the measured channel busy rate being less than a first threshold.

[0078] At block 610, a processor of the roadside unit may generate and transmit RSU messages at a second rate less frequently than the first rate in response to the measured channel busy rate being equal to or greater than a threshold.

[0079] 6C illustrates a method 652 according to one or more implementations. The method 652 may be performed in conjunction with the method 600. The operations of the method 652 may be operations performed to generate and transmit RSU messages at a rate determined based on whether a measured channel busy rate is greater than or equal to one or more thresholds.

[0080] In block 612, the processor of the roadside unit may generate and transmit different types of RSU messages at type-specific first rates in response to the measured channel busy rate being less than a first threshold. In various embodiments, the message generation and transmission rates may be different for different types of RSU messages that correlate with the same threshold. The types of RSU messages may include SPAT messages, MAP messages, RSI messages, and RSMs.

[0081] In block 614, the processor of the roadside unit may generate and transmit different types of RSU messages at a type-specific second rate that is less frequent than the type-specific first rate in response to a measured channel busy rate equal to or greater than a threshold.

[0082] 6D illustrates a method 654 according to one or more implementations. Method 654 may be performed in conjunction with method 600. The operations of method 654 may be operations performed to generate and transmit RSU messages at a rate determined based on whether a measured channel busy rate is greater than or equal to one or more thresholds.

[0083] In block 616, the processor of the roadside unit may determine a rate for generating and transmitting the RSU message based on whether the measured channel busy ratio is equal to or greater than one or more thresholds using a lookup table of rates and one or more thresholds correlating with the type of RSU message. In various embodiments, the measured channel busy ratio may be compared to one or more thresholds, such as one, two, three, four, or more thresholds. In various embodiments, the one or more thresholds may be indicated in a lookup table correlating the one or more thresholds with a transmission rate to use for generating and transmitting the RSU message.

[0084] 6E illustrates a method 656 according to one or more implementations. The method 656 may be performed in conjunction with the method 600. The operations of the method 656 may be operations performed to generate and transmit RSU messages at a rate determined based on whether a measured channel busy rate is greater than or equal to one or more thresholds.

[0085] In block 618, the processor of the roadside unit may determine whether one or more event triggers for RSU message generation and transmission have occurred. Various embodiments may include RSU message congestion control based on one or more event triggers. In various embodiments, the roadside unit may monitor the state of the roadside unit and / or the vicinity around the roadside unit. The roadside unit may use the roadside unit's sensors (e.g., radar, LIDAR, camera, etc.) and / or detection of messages from other entities (e.g., BSM from a vehicle approaching the roadside unit) to monitor the state of the roadside unit and / or the vicinity around the roadside unit. For example, the roadside unit may detect the presence of an object (e.g., a vehicle, an obstacle, etc.) or a participant (e.g., a pedestrian, a bicycle, an animal, etc.) in the vicinity of the roadside unit. Detection of the presence of an object or a participant in the vicinity of the roadside unit by the roadside unit may be an event trigger. As another example, the roadside unit may detect a vehicle approaching the roadside unit. Detection of a vehicle approaching the roadside unit may be an event trigger. In various embodiments, the event trigger may be based at least in part on the RSU message type. For example, the event trigger for the RSI message may be different from the event trigger for the RSM. As a specific example, the detection of the presence of an object or participant in the vicinity of the roadside unit may be an event trigger for the RSM, and the detection of a vehicle approaching the roadside unit may be an event trigger for the RSI message.

[0086] In block 620, the processor of the roadside unit may generate and transmit the RSU message at a rate determined based on whether the measured channel busy rate is equal to or greater than one or more thresholds in response to determining that one or more event triggers for the RSU message generation and transmission have occurred. In various embodiments, the roadside unit may not generate the RSU message until it is determined that one or more event triggers have occurred. In various embodiments, the roadside unit may determine whether one or more event triggers for the RSU message have occurred at the roadside unit. In response to determining that one or more event triggers for the RSU message have not occurred, the roadside unit may not transmit the RSU message. In response to determining that one or more event triggers for the RSU message have occurred, the roadside unit may generate and transmit the RSU message. In various embodiments, the generation and transmission of the RSU message in response to determining that one or more event triggers for the RSU message generation and transmission have occurred may be based at least in part on the measured channel busy rate.

[0087] FIG. 6F illustrates a method 658 according to one or more implementations.

[0088] In block 622, the processor of the roadside unit may determine whether one or more event triggers for RSU message generation and transmission have occurred at the roadside unit. In various embodiments, the roadside unit may monitor the state of the roadside unit and / or the vicinity around the roadside unit. The roadside unit may use the roadside unit's sensors (e.g., radar, LIDAR, camera, etc.) and / or detection of messages from other entities (e.g., BSM from a vehicle approaching the roadside unit) to monitor the state of the roadside unit and / or the vicinity around the roadside unit. For example, the roadside unit may detect the presence of an object (e.g., a vehicle, an obstacle, etc.) or a participant (e.g., a pedestrian, a bicycle, an animal, etc.) in the vicinity of the roadside unit. Detection of the presence of an object or a participant in the vicinity of the roadside unit by the roadside unit may be an event trigger. As another example, the roadside unit may detect a vehicle approaching the roadside unit. Detection of a vehicle approaching the roadside unit may be an event trigger. In various embodiments, the event trigger may be based at least in part on an RSU message type. For example, the event trigger for an RSI message may be different from the event trigger for an RSM. As a particular example, detection of the presence of an object or participant in the vicinity of a roadside unit may be an event trigger for an RSM, and detection of a vehicle approaching a roadside unit may be an event trigger for an RSI message.

[0089] In block 624, the processor of the roadside unit may prevent or suspend RSU message generation and transmission in response to determining that one or more event triggers for the RSU message have not occurred. In various embodiments, the roadside unit may not transmit the RSU message until it is determined that one or more event triggers have occurred. In various embodiments, the roadside unit may determine whether one or more event triggers for the RSU message generation and transmission have occurred at the roadside unit.

[0090] In block 626, the processor of the roadside unit may generate and transmit an RSU message in response to determining that one or more event triggers for the RSU message have occurred. In various embodiments, the rate at which the RSU message is generated and transmitted in response to determining that one or more event triggers for the RSU message generation and transmission have occurred may be based at least in part on a measured channel busy rate.

[0091] 6G illustrates a method 660 according to one or more implementations. Method 660 may be performed in conjunction with method 658. The operations of method 660 may be performed in response to a determination that one or more event triggers for RSU message generation and transmission have occurred.

[0092] In block 602, a processor of the roadside unit may measure a channel busy rate by the PC5 access layer of the roadside unit as described for the similar block of numbers in method 600 (FIG. 6A).

[0093] In block 604, the processor of the roadside unit may compare the measured channel busy ratio to one or more thresholds, as described with respect to the similarly numbered block of method 600 (FIG. 6A).

[0094] In block 606, the processor of the roadside unit may generate and transmit RSU messages at a rate determined based on whether the measured channel busy rate is greater than or equal to one or more thresholds, as described with respect to similarly numbered blocks of method 600 (FIG. 6A).

[0095] FIG. 7 illustrates an example lookup table 700 of rates and one or more thresholds correlating with types of RSU messages according to various embodiments. With reference to FIGS. 1-7, the lookup table 700 includes rows for four threshold ranges of measured channel busy ratios correlating with different transmission rates for different types of RSU messages, specifically, SPAT, MAP, RSI, and RSM. For example, according to one or more of the operations of the methods illustrated in FIGS. 6A, 6B, 6C, 6D, 6E, 6F, and / or 6G, the roadside unit may match the measured channel busy ratio with its respective measured channel busy ratio threshold range and determine from the lookup table 700, based on the type of RSU message to be transmitted, the corresponding enumerated transmission rate to be used for the matching threshold range.

[0096] The processor implementing the various embodiments may be any programmable microprocessor, microcomputer, or one or more multi-processor chips that may be configured by software instructions (applications) to perform various functions, including those of the various aspects described herein. In some communication devices, multiple processors may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in an internal memory before being accessed and loaded into the processor. The processor may include sufficient internal memory to store application software instructions.

[0097] As used in this application, terms such as "component," "module," and "system" are intended to include computer-related entities, such as, but not limited to, hardware, firmware, a combination of hardware and software, software, or software in execution, configured to perform a particular operation or function. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. As an example, both an application running on a processor of a communications device and the communications device may be referred to as a component. One or more components may reside within a process and / or thread of execution, and a component may reside on one processor or core and / or be distributed among two or more processors or cores. Furthermore, these components may execute from various non-transitory computer-readable media having various instructions and / or data structures stored thereon. The components may communicate by way of local and / or remote processes, function or procedure calls, electronic signals, data packets, memory reads / writes, and other known network, computer, processor, and / or process related communication methods.

[0098] A number of different cellular and mobile communication services and standards are available or are contemplated in the future, all of which may implement and benefit from various aspects. Such services and standards include, for example, Third Generation Partnership Project (3GPP), Long Term Evolution (LTE) systems, third generation wireless mobile communication technologies (3G), fourth generation wireless mobile communication technologies (4G), fifth generation wireless mobile communication technologies (5G), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020™), EDGE, Advanced Mobile Phone System (AMPS), Digital AMPS (IS-136 / TDMA), Evolution Data Optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), and other related technologies. The technologies may include, for example, Wi-Fi Protected Access I & II (WPA, WPA2), Unified Digital Enhanced Network (iden), C-V2X, V2V, V2P, V2I, and V2N. Each of these technologies relates to the transmission and reception of voice, data, signaling, and / or content messages. Any reference to terminology and / or technical details regarding a particular telecommunications standard or technology is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology unless specifically recited in the claim language.

[0099] The various embodiments shown and described are provided merely as examples to illustrate various features of the claims. However, features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment, but may be used with or combined with other embodiments shown and described. Furthermore, the claims are not intended to be limited by any one exemplary embodiment. For example, one or more of the operations of the method may be substituted for or combined with one or more operations of the method.

[0100] The above method descriptions and process flow diagrams are provided merely as illustrative examples and do not require or imply that the operations of the various aspects must be performed in the order presented. As will be appreciated by one of ordinary skill in the art, the order of operations in the above aspects may be performed in any order. Words such as "then," "then," and "next" do not limit the order of operations, but rather these words are used to guide the reader through the method description. Additionally, any reference to a claim element in the singular, for example using the articles "a," "an," or "the," should not be construed as limiting the element to the singular.

[0101] Various exemplary logic blocks, modules, components, circuits, and algorithmic operations described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various exemplary components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each specific application, but such aspect decisions should not be interpreted as causing a departure from the scope of the claims.

[0102] The hardware used to implement the various example logic, logic blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed using general purpose processors, digital signal processors (DSPs), ASICs, field programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of receiver smart objects, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry specific to a given function.

[0103] In one or more aspects, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on a non-transitory computer-readable or processor-readable storage medium. The operations of the methods or algorithms disclosed herein may be embodied in a processor-executable software module or processor-executable instructions that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that may be accessed by a computer or processor. By way of example and not limitation, such a non-transitory computer-readable or processor-readable storage medium may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. As used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks typically reproduce data magnetically and discs reproduce data optically using lasers. Combinations of the above are also included within the scope of non-transitory computer-readable media and non-transitory processor-readable media. Furthermore, operations of a method or algorithm may reside as one or any combination or set of code and / or instructions on a non-transitory processor-readable storage medium and / or computer-readable storage medium, which may be embodied in a computer program product.

[0104] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the claims. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the aspects shown herein, but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein. [Explanation of symbols]

[0105] 100 C-V2X System 102 In-vehicle communication device 103 In-vehicle communication device 105 Communication Devices 106 Transmitter 107 Transmitter 108 Roadside Unit 109 Roadside Unit 111 users 112 vehicles 113 Cellular Tower or Base Station 114 vehicles 115 Network 116 Network Server 200 Roadside Unit 201 Processor 202 Volatile Memory 203 Disk Drive 204 Network Access Port 206 Floppy disk drive, compact disk (CD) or digital video disk (DVD) drive 207 Antenna 300 SIP 302 SoC 304 SoC 310 Digital Signal Processor (DSP), Processor 312 Modem Processor, Processor 314 Graphics Processor, Processor 316 Application Processor, Processor 318 Coprocessor, Processor 320 Memory 322 Custom Circuit 324 System Components and Resources 326 Interconnect / Bus Modules 330 Temperature Sensor 332 Thermal Management Unit 352 5G modem processor, processor, modem processor 354 Power Management Unit 356 mmWave Transceiver 358 Memory 360 additional processors, processors 364 Interconnect / Bus Modules 371 SoC 372 ITS modem processor, processor, modem processor 374 Power Management Unit 376 Transceiver 378 Memory 380 additional processors, processors 384 Interconnect / Bus Modules 401 Transmitting roadside unit, communication device, transmitting communication device 402 Upper Data Layer 403 Application 404 Security Services 405 Internet Protocol (IP) Service 406 modem stack 407 Packet Data Convergence Protocol (PDCP) Layer, Upper PDCP Layer 408 RLC layer, lower RLC layer 409 Medium Access Control (MAC) Layer, Upper MAC Layer 410 Physical (PHY) Layer, Lower PHY Layer 415 Receiving vehicle on-board unit, vehicle on-board unit, communication device, receiving communication device 420 Message 421 PDCP PDU 422 RLC PDU 424 MAC PDU 426 Flow, PHY PDU Bitstream Flow 428 PHY SDU 430 MAC SDU 432 RLC SDU 434 PDCP SDU 500 Systems 502 Roadside Unit 504 Vehicle On-Board Unit, Remote Platform 506 Machine-Readable Instructions 508 Channel Ratio Measurement Module 510 Channel Ratio Comparison Module 512 RSU message generation module 514 Type Generation Module 516 Rate Decision Module 517 Event Trigger Module 600 ways 650 method 652 method 654 method 656 method 658 method 660 method 700 Lookup Tables

Claims

1. A method for providing congestion control in roadside unit message ("RSU message") scheduling, comprising: measuring a channel busy rate by a PC5 access layer of a roadside unit; comparing the measured channel busy rate to one or more thresholds; generating and transmitting RSU messages at a rate determined based on whether the measured channel busy rate is greater than or equal to the one or more thresholds; Including, The step of generating and transmitting RSU messages at a rate determined based on whether the measured channel busy rate is equal to or greater than the one or more thresholds, In response to the measured channel busy rate being less than a first threshold, generating and transmitting n RSU messages at first n type-specific rates, the first n type-specific rates being type-specific rates of a first plurality of rates; generating and transmitting the n types of RSU messages at second n types of specific rates, the second n types of specific rates being type-specific rates, in response to the measured channel busy rate being equal to or greater than the first threshold; At least one of A k-th unique rate of the first n unique rates is a rate unique to a k-th RSU message among the n types of RSU messages; A k-th unique rate of the second n types of unique rates is a rate unique to the k-th RSU message among the n types of RSU messages; a k-th eigen-rate of the second n eigen-rates is less frequent than a k-th eigen-rate of the first n eigen-rates; k is any one of 1 to n, and n is an integer of 2 or more; The n types of RSU messages are correlated with a certain threshold value. method.

2. The step of generating and transmitting RSU messages at a rate determined based on whether the measured channel busy rate is equal to or greater than the one or more thresholds, generating and transmitting an RSU message at a first rate in response to the measured channel busy rate being less than a first threshold; generating and transmitting RSU messages at a second rate less frequently than the first rate in response to the measured channel busy rate being equal to or greater than the first threshold; 2. The method of claim 1, comprising:

3. The method of claim 1 , wherein the n types of RSU messages include a signal phase and timing (SPAT) message, a map data (MAP) message, a road sign information (RSI) message, and a road safety message (RSM).

4. 10. The method of claim 1, further comprising: determining the rate for generating and transmitting an RSU message based on whether the measured channel busy rate is greater than or equal to the one or more thresholds using a look-up table of rates and the one or more thresholds that correlate with a type of RSU message.

5. determining whether one or more event triggers for RSU message generation and transmission have occurred; Further comprising: The step of generating and transmitting an RSU message at a rate determined based on whether the measured channel busy rate is equal to or greater than the one or more thresholds includes, in response to a determination that the one or more event triggers for generating and transmitting an RSU message have occurred, generating and transmitting an RSU message at the rate determined based on whether the measured channel busy rate is equal to or greater than the one or more thresholds.

5. The method according to any one of claims 1 to 4.

6. A roadside unit, A transceiver; coupled to the transceiver, Measure the channel busy rate by PC5 access layer, comparing the measured channel busy rate to one or more thresholds; Generate and transmit roadside unit messages ("RSU messages") at a rate determined based on whether the measured channel busy rate is greater than or equal to the one or more thresholds. The processor-executable instructions for Processor and Including, The processor, In response to the measured channel busy rate being less than a first threshold, generating and transmitting n types of RSU messages at first n types of type-specific rates among a first plurality of rates; generating and transmitting the n types of RSU messages at second n types of specific rates, the second n types of specific rates being type-specific rates, in response to the measured channel busy rate being equal to or greater than the first threshold; By at least one of further comprising processor-executable instructions for generating and transmitting RSU messages at a rate determined based on whether the measured channel busy rate is greater than or equal to the one or more thresholds; A k-th unique rate of the first n unique rates is a rate unique to a k-th RSU message among the n types of RSU messages; A k-th unique rate of the second n types of unique rates is a rate unique to the k-th RSU message among the n types of RSU messages; a k-th eigen-rate of the second n eigen-rates is less frequent than a k-th eigen-rate of the first n eigen-rates; k is any one of 1 to n, and n is an integer of 2 or more; The n types of RSU messages are correlated with a certain threshold value. Roadside unit.

7. The processor, In response to the measured channel busy rate being less than a first threshold, generating and transmitting an RSU message at a first rate; In response to the measured channel busy rate being equal to or greater than the first threshold, generating and transmitting RSU messages at a second rate less frequently than the first rate; 7. The roadside unit of claim 6, further comprising processor-executable instructions for generating and transmitting RSU messages at a rate determined based on whether the measured channel busy rate is greater than or equal to the one or more thresholds.

8. The roadside unit of claim 6, wherein the n types of RSU messages include a signal phase and timing (SPAT) message, a map data (MAP) message, a road sign information (RSI) message, and a road safety message (RSM).

9. 7. The roadside unit of claim 6, further comprising: processor-executable instructions for: determining, using a lookup table of rates correlating with a type of RSU message and the one or more thresholds, the rate for generating and transmitting an RSU message based on whether the measured channel busy rate is greater than or equal to the one or more thresholds.

10. The processor, Determine whether one or more event triggers for RSU message generation and transmission have occurred and further comprising processor-executable instructions for:

10. The roadside unit of claim 6, further comprising: a processor-executable instruction for: in response to determining that the one or more event triggers for RSU message generation and transmission have occurred, generating and transmitting an RSU message at the rate determined based on whether the measured channel busy rate is greater than or equal to the one or more thresholds, the processor further comprising: a processor-executable instruction for generating and transmitting an RSU message at the rate determined based on whether the measured channel busy rate is greater than or equal to the one or more thresholds, the processor further comprising:

11. A non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions comprising: Measuring a channel busy rate by a PC5 access layer of a roadside unit; comparing the measured channel busy rate to one or more thresholds; generating and transmitting roadside unit messages ("RSU messages") at a rate determined based on whether the measured channel busy rate is greater than or equal to the one or more thresholds; and configured to cause a processor of the roadside unit to perform operations including: generating and transmitting RSU messages at a rate determined based on whether the measured channel busy rate is greater than or equal to the one or more thresholds; In response to the measured channel busy rate being less than a first threshold, generating and transmitting n types of RSU messages at first n types of type-specific rates among a first plurality of rates; generating and transmitting the n types of RSU messages at second n types of specific rates, the second n types of specific rates being type-specific rates, in response to the measured channel busy rate being equal to or greater than the first threshold; At least one of A k-th unique rate of the first n unique rates is a rate unique to a k-th RSU message among the n types of RSU messages; A k-th unique rate of the second n types of unique rates is a rate unique to the k-th RSU message among the n types of RSU messages; a k-th eigen-rate of the second n eigen-rates is less frequent than a k-th eigen-rate of the first n eigen-rates; k is any one of 1 to n, and n is an integer of 2 or more; The n types of RSU messages are correlated with a certain threshold value. A non-transitory processor-readable storage medium.

12. The stored processor-executable instructions are configured to generate and transmit RSU messages at a rate determined based on whether the measured channel busy rate is greater than or equal to the one or more thresholds. In response to the measured channel busy rate being less than a first threshold, generating and transmitting an RSU message at a first rate; generating and transmitting RSU messages at a second rate less frequently than the first rate in response to the measured channel busy rate being equal to or greater than the first threshold; 12. The non-transitory processor-readable storage medium of claim 11 configured to cause a processor of a roadside unit to perform operations including:

13. 12. The non-transitory processor-readable storage medium of claim 11, wherein the n types of RSU messages include a signal phase and timing (SPAT) message, a map data (MAP) message, a road sign information (RSI) message, and a road safety message (RSM).

14. 12. The non-transitory processor-readable storage medium of claim 11, further comprising: determining the rate for generating and transmitting an RSU message based on whether the measured channel busy rate is greater than or equal to the one or more thresholds using a look-up table of rates and the one or more thresholds that correlate with a type of RSU message.

15. Determining whether one or more event triggers for RSU message generation and transmission have occurred. Further comprising: The generating and transmitting an RSU message at the rate determined based on whether the measured channel busy rate is equal to or greater than the one or more thresholds includes, in response to determining that the one or more event triggers for RSU message generation and transmission have occurred, generating and transmitting an RSU message at the rate determined based on whether the measured channel busy rate is equal to or greater than the one or more thresholds.

15. The non-transitory processor-readable storage medium of any one of claims 11 to 14.

16. A roadside unit, means for measuring a channel busy rate by a PC5 access layer of the roadside unit; means for comparing the measured channel busy rate with one or more thresholds; means for generating and transmitting roadside unit messages ("RSU messages") at a rate determined based on whether the measured channel busy rate is greater than or equal to the one or more thresholds; Including, The means for generating and transmitting RSU messages at a rate determined based on whether the measured channel busy rate is greater than or equal to the one or more thresholds, means for generating and transmitting n types of RSU messages at first n types of type-specific rates of a first plurality of rates in response to the measured channel busy rate being less than a first threshold; means for generating and transmitting the n types of RSU messages at second n types of specific rates, the second n types of specific rates being type-specific rates, in response to the measured channel busy rate being equal to or greater than the first threshold; At least one of A k-th unique rate of the first n unique rates is a rate unique to a k-th RSU message among the n types of RSU messages; A k-th unique rate of the second n types of unique rates is a rate unique to the k-th RSU message among the n types of RSU messages; a k-th eigen-rate of the second n eigen-rates is less frequent than a k-th eigen-rate of the first n eigen-rates; k is any one of 1 to n, and n is an integer of 2 or more; The n types of RSU messages are correlated with a certain threshold value. Roadside unit.

Images