Techniques for managing data distribution in V2X environments

Abstract

The technology described herein includes utilizing a mobile device as a proxy receiver and / or transmitter for a vehicle in a V2X network. In some embodiments, a mobile device associated with a mobile device capability may be configured to obtain vehicle capabilities and store such data in a memory at the mobile device. The mobile device may obtain any suitable combination of a receiving credential and one or more transmission credentials. In some embodiments, the one or more transmission credentials may be generated by a credential agency based at least in part on determining that the vehicle capabilities and the mobile device capabilities indicate that the sensor(s) and / or processing resources of the vehicle and / or mobile device meet the transmission requirement threshold of the network. The mobile device may then use at least one of the transmission credentials to transmit any suitable data message on behalf of the vehicle.

Description

[0001] background

[0002] Vehicle-to-everything (V2X) is a communication standard for vehicles to exchange information about the traffic environment with related entities. V2X may include vehicle-to-vehicle (V2V) communication between vehicles with V2X capabilities, vehicle-to-infrastructure (V2I) communication between vehicles and infrastructure-based devices (commonly referred to as roadside units (RSUs)), and vehicle-to-person (V2P) communication between vehicles and nearby people (pedestrians, cyclists, and other road users). Further, V2X can use any of a variety of wireless radio frequency (RF) communication technologies. For example, cellular V2X (CV2X) is a form of V2X that uses cellular-based communications such as long-term evolution (LTE), fifth-generation new radio (5G NR), and / or other cellular technologies in a direct communication mode as defined by the Third Generation Partnership Project (3GPP). Components or devices used to convey V2X messages on vehicles, RSUs, or other V2X entities are generally referred to as V2X devices or V2X user equipment (UE).

[0003] Autonomous and semi-autonomous vehicles, including vehicles with advanced driver assistance systems (ADAS), can use V2X to communicate and coordinate maneuvers. To help vehicles with V2X capabilities ("V2X vehicles") maneuver safely on the road, V2X vehicles can communicate intended maneuvers to other V2X vehicles. This can include maneuvers such as lane changes, intersections, etc. along with corresponding time windows for behavior trajectories.

[0004] Legacy vehicles not equipped with ADAS may not be able to take advantage of the valuable data being communicated, or their participation may not be optimal. Many benefits of a vehicle-to-everything (V2X) environment depend on knowing accurate inter-vehicle distances and relative positions, as well as having environmental and situational awareness. However, legacy vehicles are not able to transmit such information. Both legacy vehicle drivers and autonomous (or semi-autonomous) vehicle drivers can benefit from these types of shared interactions and communications.

[0005] Brief Overview

[0006] The technology described herein provides for the transmission of data by a mobile device on behalf of a vehicle.

[0007] Some embodiments may include a method for transmitting data on behalf of a vehicle by a mobile device. The method may include obtaining, by the mobile device, a vehicle capability associated with the vehicle, the vehicle capability indicating one or more sensors of the vehicle. The method may also include determining, by the mobile device, a mobile device capability indicating one or more sensors, processing resources, or both of the mobile device. The method may also include obtaining, by the mobile device, one or more transmission credentials for vehicle-to-vehicle transmission from a credential authority based at least in part on the vehicle capability and the mobile device capability. The method may also include, in response to obtaining the one or more transmission credentials for vehicle-to-vehicle transmission, transmitting, by the mobile device, one or more data messages via one or more transceivers using the one or more transmission credentials on behalf of the vehicle.

[0008] Some embodiments may include a mobile device. The mobile device may include a memory and one or more processors communicatively coupled to the memory, the memory storing executable instructions for transmitting data by the mobile device on behalf of a vehicle. In some embodiments, the one or more processors are configured to execute the instructions to cause the mobile device to perform operations. These operations may include obtaining a vehicle capability associated with the vehicle by the mobile device, the vehicle capability indicating one or more sensors of the vehicle. These operations may also include determining by the mobile device the mobile device capability indicating one or more sensors, processing resources, or both of the mobile device. These operations may also include obtaining one or more transmission credentials for vehicle network transmission from a credential authority by the mobile device at least in part based on the vehicle capability and the mobile device capability. These operations may also include, in response to obtaining one or more transmission credentials for vehicle network transmission, transmitting one or more data messages on behalf of the vehicle via one or more transceivers by the mobile device using the one or more transmission credentials.

[0009] Some embodiments may include non-transient computer-readable media. The non-transient computer-readable medium may include storage instructions for transmitting data on behalf of a vehicle by a mobile device. In some embodiments, these instructions, when executed by one or more processors of the mobile device, cause the one or more processors to perform operations. These operations may include obtaining a vehicle capability associated with the vehicle by the mobile device, the vehicle capability indicating one or more sensors of the vehicle. These operations may also include determining, by the mobile device, a mobile device capability indicating one or more sensors, processing resources, or both of the mobile device. These operations may also include obtaining, by the mobile device, one or more transmission credentials for vehicle-to-vehicle transmission from a credential authority based at least in part on the vehicle capability and the mobile device capability. These operations may also include, in response to obtaining one or more transmission credentials for vehicle-to-vehicle transmission, transmitting one or more data messages via one or more transceivers by the mobile device using the one or more transmission credentials on behalf of the vehicle.

[0010] Some embodiments may include a mobile device that transmits data by a mobile device representing a vehicle. In some embodiments, the mobile device includes a device for obtaining a vehicle capability associated with the vehicle by the mobile device, the vehicle capability indicating one or more sensors of the vehicle. The mobile device may also include a device for determining a mobile device capability indicating one or more sensors, processing resources, or both of the mobile device. The mobile device may also include a device for obtaining one or more transmission credentials for vehicle-to-vehicle transmission from a credential authority based at least in part on the vehicle capability and the mobile device capability. The mobile device may also include a device for transmitting one or more data messages to at least one other vehicle on behalf of the vehicle using the one or more transmission credentials in response to obtaining the one or more transmission credentials. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a simplified block diagram illustrating an example V2X environment according to an embodiment.

[0013] Figure 2 is a flow chart depicting a method for obtaining transmission credentials on behalf of a vehicle according to an embodiment.

[0014] Figure 3 is a flow chart depicting a method for obtaining transmission credentials on behalf of one or more third-party sensors according to an embodiment.

[0015] Figure 4 is a flow chart depicting a method for determining V2X transmission data using a plurality of mobile devices according to an embodiment.

[0016] Figures 5A-5C Techniques for assigning trust values ​​to one or more entities of a V2X environment are illustrated according to an embodiment.

[0017] Figure 6 is a diagram illustrating an example technique for providing a real-time traffic model in accordance with at least one embodiment.

[0018] Figure 7 is a diagram illustrating an example technique for utilizing directed messaging in a V2X environment in accordance with at least one embodiment.

[0019] Figure 8 is a flow chart depicting a method for managing data transmission by a mobile device on behalf of a second device in a V2X environment.

[0020] Fig. 9 is an illustration of a system in which V2X-capable devices (eg, vehicles, proxy devices, RSUs, servers, etc.) may communicate over various networks, according to an embodiment.

[0021] Fig.10 A functional block diagram of a vehicle according to one embodiment is included.

[0022] Fig.11 is a block diagram of various hardware and software components of a vehicle according to one embodiment.

[0023] Fig.12 is a perspective view of an example vehicle according to an embodiment.

[0024] Fig.13 Included is a functional block diagram of an example mobile device (eg, proxy device) according to an embodiment.

[0025] Similar reference numerals in the various drawings indicate similar elements according to certain example implementations. In addition, multiple instances of the element can be indicated by adding a letter or hyphen and a second numeral after the first numeral of the element. For example, multiple instances of element 109 can be indicated as 109-1, 109-2, 109-3, etc. or as 109, 109, 109, etc. When only the first numeral is used to refer to such an element, it will be understood as any instance of the element (for example, the element 109 in the previous example will refer to elements 109-1, 109-2 and 109-3 or elements 109a, 110b and 110c).

[0026] Detailed Description

[0027] Several illustrative embodiments will now be described with reference to the accompanying drawings which form a part hereof. Although specific embodiments are described below in which one or more aspects of the present disclosure may be implemented, other embodiments may be used and various modifications may be made without departing from the scope of the present disclosure or the spirit of the appended claims.

[0028] Vehicles with V2X capabilities can execute vehicle-to-vehicle (V2V) safety applications built around the Society of Automotive Engineers (SAE) J2735 BSM, which conveys location and motion data about the vehicle's location, time, heading, speed, acceleration, predicted path, path history, and more. Other V2X messages may include, but are not limited to: cooperative perception messages (e.g., for announcing the location, movement, and basic attributes of the transmitting device), decentralized environmental notification messages (e.g., for reporting the detection of traffic events or road hazards), signal phase and timing messages (e.g., information about one or more traffic lights), in-vehicle information messages (e.g., for providing static or dynamic road sign information for in-vehicle presentation), map messages (e.g., for road topography and geometry information), etc.

[0029] Not all vehicles have V2X capabilities. Vehicles that lack the ability to transmit and / or receive V2X messages are referred to herein as legacy vehicles (LV). Some of the techniques provided herein are intended to utilize mobile devices as proxy devices that receive and / or transmit and / or process data on behalf of legacy vehicles. Mobile devices (e.g., smartphones, smart watches, laptops, tablets, etc.) can be devices that are separate from factory vehicles. In some embodiments, the mobile device can be a sensor added after the market. The mobile device can be a device that is different from any device of the factory legacy vehicle. Vehicles and proxy devices with V2X capabilities can be collectively referred to as V2X user devices in this article.

[0030] In addition to transmitting position and motion data about itself / its corresponding V2X vehicle, the V2X user device may also transmit position and motion data and / or any suitable sensor data obtained about other vehicles and / or objects. In some embodiments, the one or more sensors of vehicle capabilities may be associated with corresponding trust values ​​that indicate the accuracy associated with the sensor data collected by these devices. These corresponding trust values ​​may be initially ascertained based at least in part on predetermined data stored at the V2X user device, or these values ​​may be assigned to the data by another V2X participant and / or a certificate authority of the V2X environment, which will be discussed in further detail below. The V2X user device may transmit the corresponding trust values ​​along with the sensor data it transmits.

[0031] In some embodiments, the V2X user device may be configured to obtain and transmit vehicle capabilities. As used herein, "vehicle capabilities" may describe one or more attributes of a V2X vehicle (e.g., the V2X vehicle itself, a V2X vehicle for which a mobile device operates as a proxy). For example, vehicle capabilities may include one or more images of the vehicle, one or more identifiers associated with the vehicle (e.g., license plate, vehicle identification number (VIN), make, model, year of manufacture, vehicle type (e.g., SUV, car, truck, sedan, etc.), etc.), one or more capabilities of the vehicle (e.g., one or more ADAS capabilities, braking distance, factory vehicle sensor(s), post-market sensor(s) added to the vehicle, etc.), one or more physical attributes of the vehicle (e.g., color(s), dent(s) and dent(s) location (e.g., in the left rear fender), rust / rust location, cracked rear windshield, four doors, hatchback, presence and status of convertible roof(s) (e.g., open, closed), presence and status of glass sunroof(s) (e.g., open, closed), roof rack / roof rack location, bicycle rack / bicycle rack location, presence of a trailer hitch, towing a trailer (and in some embodiments, various aspects of a trailer), etc.), or any suitable combination thereof. In some embodiments, vehicle capabilities may be provided by a user via a user interface of the vehicle and / or via a mobile device separate from the vehicle but in communication with the V2X-capable vehicle.

[0032] In some embodiments, the V2X user equipment may also be configured to transmit occupant metadata (also referred to herein as "occupant data"). As used herein, "occupant metadata" includes an identifier of the occupant (e.g., an alphanumeric identifier, first name, middle name, last name, prefix, suffix, etc.), one or more driving credentials associated with the occupant (e.g., a driver's license, a commercial driver's license, a driver's certificate, a driver's permit, etc.), one or more attributes of the occupant (e.g., height, hair length, skin color, age, vision, reaction ability, etc.), driving experience data associated with the occupant (e.g., years of experience, driving aggressiveness, number of accidents, number of at-fault accidents, etc.), one or more passenger attributes of the occupant (e.g., prone to motion sickness, sensitivity (e.g., sensitivity to light, speed, temperature, traffic, noise, etc.), etc.), or any suitable combination of the foregoing. In some embodiments, the occupant metadata may be provided via a user interface of the vehicle and / or via a mobile device that is separate from the vehicle but in communication with the vehicle having V2X capabilities. Various techniques for obtaining vehicle capabilities and / or occupant metadata are discussed more thoroughly below.

[0033] Each V2X-capable device (e.g., V2X vehicle, proxy device, roadside unit, etc.) of a V2X environment may be required to obtain transmission authorization before it may be allowed to transmit data to other devices. In some embodiments, a V2X-capable device may be required to register its capabilities (e.g., ADAS capabilities, one or more sensors, etc.) with a certificate authority to obtain a registration certificate. In some embodiments, the registration certificate may be stored on the V2X-capable device during manufacturing. The certificate authority may determine whether the capabilities of the V2X-capable device meet any suitable combination of transmission requirement thresholds associated with the V2X environment (e.g., accuracy threshold, latency threshold, throughput threshold, etc.). If so, the certificate authority may provide a registration certificate. The registration certificate may include a device identifier, a trust value corresponding to these devices, an identifier of the certificate authority, or any suitable identifier described above. A V2X-capable device may provide its registration certificate to obtain one or more transmission certificates (e.g., from a registration authority that may be the same as or different from the certificate authority). The certificate authority and the registration authority may be collectively or individually referred to as a "credential authority", and the various certificates provided by the certificate authority and / or the registration authority may be individually referred to as "credentials". Credentials for transmission may be referred to as transmission credentials, and credentials for reception may be referred to as reception credentials. In some embodiments, these transmission certificates may be provided in messages transmitted by a V2X-capable device and used by the recipient to confirm the message. If a V2X-capable device does not first obtain a transmission certificate, the V2X-capable device may be configured not to transmit position and motion data, vehicle capabilities, and / or occupant data. In some embodiments, a proxy device may be used primarily to receive V2X data, but is not used for transmission via the V2X network (perhaps because it does not meet the transmission requirement threshold(s). In these scenarios, the VCD may request a reception certificate from a registration authority. If the VCD does not first obtain a reception certificate, the VCD may be configured to discard the V2X message.

[0034] A V2X-capable device (VCD) may receive V2X messages from a remote device (e.g., a nearby V2X-capable vehicle (referred to herein as a remote vehicle (RV)) within communication range, a roadside unit, a nearby proxy device (PD), etc.). For example, a nearby VCD may be broadcast BSM messages up to 10 times per second (10Hz). Thus, if a VCD is surrounded by 200 VCDs (within a threshold distance of the VCD), each of which communicates up to 10 BSMs per second, the VCD may need to process up to 2000 BSM messages per second. The processing may include verifying a digital signature of the message, and determining based on the content of the message whether to provide driver assistance information (e.g., warnings, alerts, graphics and / or audible data, etc.) to the driver, change or perform a maneuver, store received data elements, retransmit received data elements, assign and / or adjust trust values, etc. In addition, additional message types (e.g., non-BSM safety messages) may also be communicated to the VCD from nearby VCDs, and other communications may be received from other remote devices (such as roadside units (RSUs), traffic-related servers, etc.). Further, the information conveyed by the BSM and other messages is typically very time-sensitive and must be processed quickly by the VCD before it becomes irrelevant. As a result, the VCD typically has a limited ability to delay processing of these incoming messages. This can result in a high processing load on the hardware blocks of the PD (e.g., central processing unit (CPU), digital signal processor (DSP), and / or elliptic curve digital signature algorithm (ECDSA)). Generating and / or providing driver assistance information (e.g., warnings, alarms, graphical presentations, audible presentations, maps, models, etc.) based on V2X messages utilizes the processing resources of the VCD (and potentially utilizes the processing resources of the LV if the output devices of the LV are used for presentation of driver assistance information). Storing data elements from received messages (e.g., additional vehicle capabilities provided by remote devices) can utilize the memory resources of the mobile device. Assigning and / or adjusting trust values ​​corresponding to sensor(s) and / or sensor data may utilize processing resources of the VCD. Therefore, it is important that the VCD includes the ability to filter irrelevant messages to prevent the processing and / or memory resources of the VCD from being wasted unnecessarily.

[0035] Using the technology disclosed herein, a V2X network may include a mechanism for ensuring that only approved devices can receive data via the V2X network. In addition, the V2X network may be managed so that only devices that meet a certain threshold level of accuracy, latency, and / or throughput can transmit data via the V2X network, thereby ensuring at least a threshold performance level of the network. By transmitting the data discussed herein, the message recipient can be made aware of other vehicles (and potentially information about the vehicle and its occupants), even if the device lacks line of sight, does not collect any sensor data corresponding to the vehicle, and / or may be outside the receiving range for receiving messages from its original source. In addition, the receiving device can be enabled to find out the extent to which the data should be trusted (e.g., how accurate the data can be). By utilizing this information from multiple sources, devices can not only know their own attributes, but also the attributes of other devices. These attributes or identifiers agreed upon by several V2X participants can be utilized so that V2X messages can be directed to specific recipients, thereby reducing the number of messages processed by each device of the network. Data received via V2X messages can be used to notify the movement and maneuvering of nearby vehicles. As a result, data accuracy, network latency, and throughput are extremely important.

[0036] Figure 1 1 is a simplified block diagram illustrating an example environment 100 (eg, a V2X environment) according to an embodiment. As an example, Figure 1 The mobile device 102 is depicted as being used as a proxy device for the vehicle 104. Figure 1In the example provided in , the mobile device 102 can be configured to receive and / or transmit data on behalf of the vehicle 104 via the network 108 (e.g., a cellular network, a WiFi network, any suitable network configured for V2X communication, etc.). In some embodiments, the vehicle 104 lacks communication capabilities and / or components for the environment 100. That is, the vehicle 104 (an example of a legacy vehicle) cannot transmit and / or receive V2X data messages (e.g., data messages 106, V2X messages) via the network 108. The data message 106 can be transmitted by any suitable remote device (e.g., RV 110, roadside unit 112, or any suitable V2X-capable device (VCD) different from the mobile device 102, which is used to transmit and receive V2X messages for the vehicle 104). It should be understood that the mobile device 102 can be located in the vehicle 104 in time and can be used as a proxy device for transmitting and / or receiving V2X messages on behalf of the vehicle 104. In other embodiments, the vehicle 104 may be a V2X-capable vehicle configured to transmit and receive V2X messages via the network 108. In either scenario, the mobile device 102 and the vehicle 104 may be communicatively coupled (e.g., via the network 108, via Bluetooth pairing, etc.) such that data may be exchanged between the mobile device and the vehicle. In some embodiments, the vehicle 104 may be configured with one or more third-party sensors 105 (e.g., one or more after-market sensors).

[0037] In some embodiments, the mobile device 102 and / or the vehicle 104 may be used to obtain the registration data 114. In some embodiments, the registration data 114 may include any suitable combination of vehicle capabilities describing attributes of the vehicle 104 and / or occupant metadata describing one or more occupants of the vehicle 104 (e.g., a driver, one or more passengers).

[0038] In some embodiments, registration data 114 may be obtained during the generation of a trip session or at any suitable time. A trip session may be initiated by mobile device 102 and / or vehicle 104 (each referred to as a registration device) using input and / or output devices of the registration device via any suitable graphical and / or audible interface (e.g., voice commands). Mobile device 102 and vehicle 104 may be communicatively connected via any suitable communication channel (e.g., WiFi, Bluetooth, cellular, etc.) and may communicate registration data 114 between each other. Either device or both devices may store registration data 114 in local memory.

[0039] In some embodiments, a trip session may be automatically generated based on context (e.g., as a result of one or more determinations). For example, any registered device may be configured to determine that it is being utilized or is likely to be used for transportation. As an example, any registered device may determine that it is being utilized and / or is likely to be utilized based at least in part on a determination that a Bluetooth pairing procedure (e.g., a pairing procedure performed with the mobile device 102 and the vehicle 104) has been completed, based on a determination that the registered device is being used for directions, based on a determination that the speed at which the registered device is traveling has exceeded a threshold, based on detecting an audio signature of a vehicle cab, and the like. In some embodiments, a registered device may generate a trip session in response to determining that it is being utilized or is likely to be used for transportation via any of the determinations listed above.

[0040] Registration data from a previous trip session may be stored at the registration device and may be selectable, or the user may select an option to create new registration data. Any selected registration data may be modifiable by the user via the registration device(s). Subsequently, the registration device may be used to obtain any suitable portion of the vehicle capabilities using one or more interfaces and / or one or more input / output devices (e.g., keyboard, microphone, camera, display, speaker, etc.). For example, in some embodiments, the registration device may present a graphical interface, and the user may use the graphical interface to provide any suitable user input to identify any suitable portion of the vehicle capabilities. In some embodiments, the registration device may be configured to audibly request the user to provide (e.g., vocally, via a graphical interface) the vehicle capabilities of the vehicle. The mobile device and / or the vehicle may be configured to receive such user input and store the received data as vehicle capabilities in an object associated with the vehicle (or another suitable storage container).

[0041] In some embodiments, the camera of the mobile device 102 may be used to capture one or more images of the vehicle 104. The mobile device 102 may be configured to identify one or more vehicle attributes based on the one or more images (e.g., still images, videos, etc.) using any suitable image recognition technology. As an example, the mobile device may store a machine learning model that has been previously trained to identify vehicle attributes based on input data (e.g., one or more images of the vehicle). In some embodiments, the machine learning model may be previously trained using any suitable supervised, unsupervised, semi-supervised and / or reinforcement learning techniques. As a non-limiting example, a supervised learning technique (e.g., a classification algorithm, regression analysis, etc.) may be used to train a machine learning model, wherein the model (e.g., a function) is determined to predict output based on input by analyzing a training data set including samples for which vehicle attributes have been previously identified. For example, a training set may include a sample set of one or more images that have previously been labeled as depicting one or more vehicle attributes and / or images that have previously been identified as lacking one or more vehicle attributes. Any suitable number of vehicle attributes (e.g., color, make, model, year, dents, broken windows, blemishes, license plate number, VIN number, registration tag data, etc.) may be captured based at least in part on the image(s) captured by mobile device 102 .

[0042] The occupant data can be obtained using one or more graphical and / or audible interfaces of the registration device in a manner similar to that described above in conjunction with the vehicle capabilities. As an example, the registration device can be used to provide occupant information of the driver and / or one or more passengers of the vehicle 104, which can be stored in the mobile device 102 and / or the vehicle 104. In some embodiments, the registration device can communicate with multiple mobile devices (e.g., a mobile device of each of the multiple passengers). Each of these multiple mobile devices can store the occupant data of its corresponding user. Therefore, the registration device can obtain occupant data from one or more other mobile devices via any suitable communication channel (e.g., Bluetooth, WiFi, cellular).

[0043] Any suitable combination of vehicle capabilities and / or occupant metadata of the registration data 114 may be used to process data messages and / or operate vehicles and / or perform operations. As an example, any suitable combination of registration data may be used to determine whether a received data message is related to a vehicle. For example, previously stored physical attributes and / or identifiers of vehicle capabilities may be compared with attributes provided in a received data message to identify whether a portion of the data provided in the message is related to the vehicle (e.g., more than a threshold number of attributes of the message match vehicle attributes of vehicle capabilities). If so, the message may be processed (e.g., by a receiving device, which in some embodiments may be a vehicle 104, and in other embodiments may be a mobile device 102 operating as an agent for the vehicle). Otherwise, the message (or a portion of the message) may be discarded and / or ignored. As another example, if the data corresponding to the vehicle attributes indicates a location within a threshold distance of a known location of the vehicle, the data message may be considered relevant. Thus, the vehicle and / or proxy device may store vehicle capabilities and / or occupant metadata obtained from multiple sources (e.g., user input, received from a remote device, etc.). Thus, the received vehicle and / or occupant data may be used to augment the registration data 114. When conflicting data occurs, any suitable set of rules may be utilized to determine what data to utilize. In some embodiments, user input data may be preferred over data received from a V2X data message. Thus, in some embodiments, the received data may not overwrite the user input data. In other embodiments, user input data may be preferred until conflicting information is received a threshold number of times and / or conflicting information is received from a threshold number of sources. If one or both of these thresholds are met, the received data may be used to replace the user input data stored at the registration device.

[0044] Any suitable portion of the registration data 114 may be classified with an indicator that specifies the manner in which the data will be persisted. Some data may be classified as valid only for that trip session (e.g., until the vehicle 104 reaches its destination, is turned off, etc.) and may be deleted when the trip session is complete. Other data (e.g., driver's license number, license plate number, driving experience, etc.) may be classified as typically permanent and may persist until manually deleted and / or modified by the user.

[0045] In some embodiments, the environment 100 may include a certificate authority 116. The certificate authority 116 may be any suitable entity (e.g., a state or federal government agency, a network provider for the network 108, etc.). In some embodiments, a device (e.g., a vehicle 104, a mobile device 102) may provide some portion of the registration data (e.g., data indicating one or more capabilities, and / or one or more sensors, and / or one or more components (such as the processing and memory resources of the device)) to the certificate authority 116 in exchange for a registration certificate (not depicted). In some embodiments, the registration certificate may be stored in a memory of the device during manufacturing or at any suitable time. In some embodiments, the registration certificate may include credentials associated with the certificate authority 116 (e.g., a public key in a public / private key pair associated with the certificate authority, an identifier of the certificate authority, an identifier of the device, etc.). The registration certificate may be used by the device to request one or more transmission and / or reception certificates from the registration authority 118. In some embodiments, the certificate authority 116 and the registration structure 118 may be provided by the same entity (e.g., a government agency) and / or system. About Figure 2-4 Methods for obtaining enrollment, transmitting and / or receiving credentials are discussed in more detail.

[0046] In some embodiments, each transmitting device of the network 108 may be required to provide a corresponding certificate for each data message transmitted via the network 108. In some embodiments, a portion of the data of each data message may be encrypted and / or digitally signed (e.g., using the private key of the transmitting device). The certificate issued by the certificate authority 116 may include the public key of the transmitting device signed by the private key of the certificate authority. In some embodiments, the public / private key may be generated by the transmitting device and provided to the certificate authority 116 when requesting an enrollment certificate or at any suitable time. In some embodiments, the device receiving the data message may utilize the public key of the certificate authority 116 (e.g., known from the enrollment certificate) to obtain the public key of the transmitting device in order to decrypt a portion of the data message encrypted with the private key of the transmitting device. Additionally or alternatively, the public key of the transmitting device may be used to verify the digital signature of the data message, which is generated using the private key of the transmitting device.

[0047] Despite Figure 1Only one mobile device, vehicle, remote vehicle, and roadside unit are depicted in FIG, but it should be understood that any suitable number of such devices may be used. In some embodiments, RV 110 may transmit a data message 106. The data message 106 may be broadcast and / or may be directed to the vehicle 104 (e.g., via a network identifier by which the vehicle 104 is known within the network 108 and / or by containing one or more vehicle attributes of the vehicle 104 that are different from the network identifier). The vehicle 104 or a mobile device 102 operating as an agent for the vehicle 104 (this set is referred to as a "receiving device") may be configured to receive the data message 106. The receiving device may compare the vehicle attributes received via one or more data elements (e.g., data fields) of the data message 106 with the vehicle capabilities stored at the receiving device. In some embodiments, the receiving device may be configured to process the data message when the network identifier of the message matches the network identifier stored in the registration data 114 and / or when a threshold number of data elements of the received message matches the vehicle attributes stored as the registration data 114. In some embodiments, if the network identifier of the data message 106 does not match the network identifier stored in the registration data 114 and / or if the number of vehicle attributes of the data message 106 fails to match a threshold number of vehicle attributes stored in the registration data 114, the receiving device may discard (or process fewer data elements of the data message).

[0048] In some embodiments, the receiving device may process or discard received data messages based at least in part on the occupant metadata of the registration data 114. As an example, when the driver is a relatively inexperienced driver (e.g., the occupant data indicates that the occupant is the current driver and has less than one year of driving experience), certain types of messages may be processed (or discarded), and when the driver is known to be an experienced driver (e.g., a driver with more than one year of experience), these messages may be discarded (or processed). In some embodiments, the receiving device may be configured to process (or discard) certain types of data messages (e.g., data message 106) when the driver of the vehicle 104 is associated with occupant data indicating that the driver has had more than a threshold number of accidents (e.g., greater than 0, greater than 1, etc.) and / or more than a threshold number of accidents of a specific accident type (e.g., an accident in which the driver rear-ends another vehicle, an accident in which the driver side-swipes another vehicle, etc.). The receiving device may be configured to discard the data message if those conditions are not met as indicated by the occupant metadata.

[0049] The receiving device may be configured to perform any suitable operation based at least in part on processing the data message 106. As an example, the receiving device (e.g., a mobile device operating as a proxy for the vehicle 104 or the vehicle 104 in the case where the vehicle 104 has V2X capabilities) may be configured to generate driver assistance information 122. The driver assistance information 122 may include any suitable combination of graphical presentations and / or audible presentations that inform the driver of any suitable conditions (e.g., weather conditions, road conditions, actions of other drivers such as hard braking, at least a real-time model depicting the locations of all V2X devices and sensed vehicles in the environment 100 within a threshold distance of the vehicle 104 or the mobile device 102 (in the case where the mobile device 102 acts as a proxy for the vehicle 104)). The driver assistance information 122 may be presented via one or more output devices (e.g., a display and / or speaker) of the mobile device 102 and / or one or more output devices of the vehicle 104. The following is in conjunction with Figure 6 Let's discuss real-time traffic models. Figure 6 The real-time traffic model of is intended as an example of driver assistance information 122 .

[0050] In some embodiments, additional vehicle capabilities may be provided via data messages 106. As an example, a mobile device 102 operating as a proxy for a vehicle 104 may not currently store the color (or any suitable physical attribute) of the vehicle 104. However, the RV 110 may utilize one or more of its sensors (e.g., a camera) to identify that the vehicle 104 is white. The RV 110 may transmit the vehicle attribute (and / or any suitable number of vehicle attributes identified by sensor data collected by its sensors) in the data message 106. Upon receipt, the recipient device may be configured to store the additional vehicle capabilities (e.g., as part of the vehicle capabilities of the registration data 114, separate from the vehicle capabilities of the registration data 114). The recipient device may be configured to store the additional vehicle capabilities when it can be determined that the received vehicle capabilities are relevant to the recipient device (e.g., describing the recipient device or aspects of the vehicle for which the recipient device operates as a proxy). Determining this relevance will be discussed in further detail below. In some embodiments, if the receiving device can identify that it is the only device within a threshold distance of RV 110, it can determine that any vehicle attributes provided in the message are relevant and can immediately store the received vehicle attributes in local memory along with the vehicle capabilities.

[0051] In some embodiments, the receiving device may be configured to temporarily store the vehicle capabilities received from the remote device until it receives the same data from a threshold number of sources (e.g., a threshold number of remote devices) for more than a threshold number of times. In some embodiments, the temporarily stored data may be stored separately from more reliable data (e.g., user-provided data, previously verified data, etc.). As an example, the temporarily stored data may be stored in a separate object, log, or data container that is different from a data container for storing currently known registration metadata (including vehicle capabilities) of a vehicle. In some embodiments, the receiving device may be configured to store additional vehicle capabilities (e.g., white) with the registration data 114 only after the same attribute has been received by at least a threshold number of different sources (e.g., three different V2X vehicles, two V2X vehicles and roadside units, one V2X vehicle and two proxy devices, four different sources, etc.). Therefore, the receiving device may be configured to obtain vehicle capabilities from other devices in the environment 100. In some embodiments, the vehicle metadata provided by the user may be superior to the vehicle capabilities provided by any other source. That is, in some embodiments, the data provided by the user may not be overwritten by the vehicle capabilities received from the remote device. In some embodiments, the user-provided data may persist until the same vehicle capabilities value has been received from multiple different sources and determined to correspond to the recipient device (or its associated vehicle).

[0052] It should be understood that the mobile device 102 need not transmit any V2X messages on behalf of the vehicle 104. In other embodiments, the mobile device 102 may transmit a V2X message indicating that the mobile device 102 is acting as a proxy for the vehicle 104. In some embodiments, other transmitting devices (e.g., RV 110 and / or roadside unit 112, other proxy devices) may utilize this knowledge when transmitting messages and / or displaying information about the vehicle 104 (e.g., via a real-time model presented at those vehicles / proxy devices). One example may include displaying an indication in a real-time traffic model that the vehicle 104 is a legacy vehicle based at least in part on receiving a message from the mobile device 102 indicating that it is operating as a proxy on behalf of the vehicle 104. In some embodiments, the transmitting device may be configured with a rule set that may cause the transmitting device to modify one or more data elements in the message (or transmit different data elements) if it is known that the recipient device is a proxy device (rather than a V2X-capable vehicle).

[0053] In some embodiments, a transmitting device (e.g., a mobile device 102 and / or a vehicle 104 operating as a proxy device) may transmit registration data and / or any suitable combination of sensor data collected from any suitable sensors of the mobile device 102, the vehicle 104, and / or the third-party sensor(s) 105 via the network 108. As an example, the transmitting device may transmit any suitable combination of vehicle capabilities, occupant metadata, location and motion data of the vehicle 104, sensor data indicating location and / or motion data of one or more vehicles sensed by the mobile device 102, sensors of the vehicle 104, and / or third-party sensor(s), sensor data such as one or more images provided by the mobile device 102, and the like.

[0054] As a non-limiting example, the transmitting device may transmit data indicating which sensors are being utilized (e.g., mobile device 102 and / or vehicle 104) to collect sensor data that is also transmitted in the message. Therefore, the receiving device (e.g., RV 110) may be able to ascertain the accuracy and / or degree of trust of the provided sensor data (e.g., based at least in part on the specific sensor(s) used for collection). Therefore, if RV 110 (or any suitable receiving device) receives sensor data about a common entity (e.g., vehicle 104) from two sources, the receiving device may be configured to prefer sensor data provided by the source with a more accurate sensor. In some embodiments, each device of environment 100 may be configured with a rule set that identifies the accuracy of a predefined number of sensors. In other embodiments, accuracy may also be provided in the transmitted data message and used by the receiver to evaluate whether to utilize the provided sensor data.

[0055] Figure 2 is a flow chart depicting a method 200 for obtaining transmission credentials (eg, temporary transmission certificates) on behalf of a vehicle according to one embodiment. Figure 1 The method may be performed by any suitable combination of the certificate authority 116, the registration authority 118, the vehicle 104, the mobile device 102, and the RV 110. As discussed above, in some embodiments, the certificate authority 116 and the registration authority may be provided by the same system. Figure 2 The examples depicted in are intended to illustrate a use case in which the mobile device 102 is configured to operate as a proxy device on behalf of the vehicle 104 for transmission and / or reception purposes. However, in a scenario where the vehicle 104 has V2X capabilities, the operations performed by the mobile device 102 may be similarly performed by the vehicle 104.

[0056] The method may begin at 202 , where the mobile devices 102 and 104 may execute any suitable connection procedure (eg, a Bluetooth pairing procedure) to establish a communication connection between the mobile device 102 and the vehicle 104 .

[0057] At 204, the registration data may be used by the mobile device 102 using the above combination Figure 1 It should be appreciated that all or some portion of the registration may alternatively be obtained by the vehicle 104 and communicated to the mobile device 102 via the connection established at 202 .

[0058] At 206, the mobile device 102 may transmit any suitable portion of the vehicle capabilities to the certificate authority 116. In some embodiments, the transmitted vehicle capabilities may include: identifiers of any suitable hardware and / or software ADAS capabilities of the vehicle 104, any suitable sensors of the vehicle 104 and / or any suitable sensor(s) of the mobile device 102 (or any other device paired with the vehicle 104), any suitable identifiers of one or more processing devices (e.g., processors) of the device to be used for the transmission (in this case, the mobile device 102), and / or any suitable attributes of the vehicle 104 and / or the mobile device 102. In the case where the vehicle 104 includes one or more third-party sensors (e.g., Figure 1 In embodiments where the vehicle 104 has V2X capabilities and the mobile device is not used as a proxy or for sensor data collection, the vehicle 104 may provide the certificate authority 116 with identifiers of any suitable combination of its ADAS capabilities, onboard sensors, and / or third-party sensors.

[0059] At 208, the certificate authority 116 may be configured to determine whether various capabilities, sensors, and / or processing devices meet requirements for participating in a V2X network (e.g., Figure 1 In some embodiments, the certificate authority 116 may implement different threshold requirements for devices registered as receivers of the network 108 than for devices registered as transmitters of the network 108. By implementing transmit threshold requirements, the certificate authority 116 may ensure that processing devices and sensors being used for transmission meet predefined accuracy, latency, and throughput requirements of the V2X network. In some embodiments, implementing receive threshold requirements may enable the certificate authority 116 to ensure that only certain types of devices can receive data for the V2X network.

[0060] The request at 206 may indicate whether registration is requested for reception and / or transmission. In some embodiments, a reception registration certificate may be provided to enable the device to receive data via the V2X network, and a different transmission registration certificate may be provided to enable the device to transmit data via the V2X network. In some embodiments, the reception registration certificate and / or the transmission registration certificate may be associated with several certificate levels. As an example,

[0061] In some embodiments, the mobile device 102 may include a request type identifier in the data transmitted at 206. The request type identifier may indicate the type of certificate being requested. In some embodiments, different types of enrollment certificates may be requested from and provided by the certificate authority 116. As an example, a receiving enrollment certificate may specify specific data types that may be received and processed by the holder of the receiving enrollment certificate. A receiving device (e.g., mobile device 102) may be configured to discard all or a portion of a data message that includes data that is not authorized by its receiving enrollment certificate.

[0062] Similarly, the transmission registration certificate may specify a transmission level corresponding to a specific type of data that a transmitting device (e.g., mobile device 102) is authorized to transmit. As an example, the transmission registration certificate may specify that the holder of the certificate is granted an enhanced passive transmission level, an active transmission level, or an enhanced active transmission level. A transmitting device granted an enhanced passive transmission level is granted permission to transmit data indicating that it is a proxy device that is listening on the V2X network. Transmitting data indicating that the proxy device is listening may enable the mobile device 102 to influence the data transmitted by other nearby devices. For example, nearby V2X devices may limit the data they transmit (e.g., for privacy, power usage, thermal considerations, etc.) until they know that the device is listening. In some embodiments, the data transmitted and / or the protocols used by other V2X devices when it is known that the proxy device is listening may be different from the data / protocols used when it is not known that the proxy device is listening.

[0063] In some embodiments, the Active Transmission level may grant permission for the certificate holder to transmit any data permitted by the Enhanced Passive Transmission level, as well as any suitable combination of: registration data including vehicle capabilities and occupant metadata (e.g., Figure 1114), sensor data collected by any suitable sensor of the mobile device 102, and / or any suitable data ascertained by the mobile device 102 via one or more images (e.g., images of vehicle instruments and / or consoles, from which any suitable image recognition techniques may be used to determine speed, turn signal usage, warning lights, etc.). In some embodiments, a proxy device (such as the mobile device 102) may be restricted from transmitting certain types of data that are permitted to be transmitted by a V2X-capable vehicle.

[0064] In some embodiments, the enhanced active transmission level may grant permission for the certificate holder to transmit any suitable data permitted by the enhanced passive transmission level and the active transmission level, as well as any suitable sensor data collected by one or more third-party sensors of the vehicle 104. In some embodiments, the mobile device 102 may be configured to authenticate sensor data routed therethrough for transmission. Authenticating the sensor data may include adding a registration certificate to the sensor data prior to transmission. The registration certificate may be described in more detail below.

[0065] In some embodiments, the certificate authority 116 may store different accuracy, latency, and / or throughput thresholds depending on the transmission level. In some embodiments, a specific transmission level may be requested at 206, and at 208, the certificate authority 116 may be configured to determine whether the data received at 206 meets the accuracy, latency, and / or throughput thresholds for the requested transmission level. In other embodiments, the certificate authority 116 may be configured to ascertain the highest transmission level for which the corresponding accuracy, latency, and / or throughput requirements are met. The data received at 206 may additionally or alternatively include a request for receiving a registration certificate. The certificate authority 116 may be configured to determine whether the requesting device (e.g., the mobile device 102) will be granted permission to receive data via the V2X network in response to receiving the request for receiving the registration certificate. In other embodiments, the certificate authority 116 may determine whether receiving the registration certificate will be granted regardless of whether the data received at 206 indicates a request for receiving the registration certificate.

[0066] At 210, certificate authority 116 may transmit any suitable combination of a received enrollment certificate and / or a transmitted enrollment certificate granted as a result of the operations performed at 208. In some embodiments, the certificate(s) may include an identifier of certificate authority 116 and may be separately encrypted with a private key (e.g., a private key of a public / private key pair) associated with certificate authority 116. In some embodiments, the certificate authority's public key may be provided to registration authority 118 and / or mobile device 102 at any suitable time.

[0067] It should be appreciated that in some embodiments, the functionality provided by the certificate authority 116 may additionally and / or alternatively be provided by any suitable V2X-capable device. That is, any suitable V2X-capable device may store predefined accuracy, latency, and / or throughput thresholds and any suitable predefined data indicative of accuracy, latency, and / or throughput associated with sensors and / or processing devices. Thus, the data transmitted by the mobile device 102 at 206 may alternatively be transmitted to any suitable V2X-capable device (or broadcasted) such that the V2X-capable device receiving the data may provide for receiving and / or transmitting registration certificates in a manner similar to that described above in connection with the certificate authority 116. If provided by a V2X-capable device, the certificate(s) may be encrypted with a private key associated with the V2X-capable device, the corresponding public key for which is known to the registration authority 118 due to a previous interaction between the V2X-capable device and the registration authority 118.

[0068] At 212, if the receiving enrollment certificate is provided at 210, the mobile device 102 can be configured to begin receiving the enrollment certificate from the network 108 (e.g., from any suitable remote device such as Figure 1 In some embodiments, the software and / or hardware of the mobile device 102 may be configured to restrict data reception based on receiving the registration certificate.

[0069] At 214, the mobile device 102 may request a temporary transmission certificate by providing its transmission registration certificate to the registration authority 118. In some embodiments, the registration authority 118 may be configured to manage temporary transmission certificates for all transmitting devices of the network 108. The temporary transmission certificate may be required to be included in each data message transmitted via the network 108. The temporary transmission certificate may be used by the receiving device to verify that the transmitting device has permission to transmit data via the network 108.

[0070] At 216, the registration authority 118 may validate the transmission registration certificate received at 214 by decrypting the certificate using a public key associated with the certificate authority 116. The registration authority 118 may verify that an identifier of the certificate authority 116 is included in the certificate. If the registration authority 118 cannot verify that the certificate is provided by the certificate authority 116, the registration authority 118 may discard the data provided at 214. In some embodiments, it may transmit data indicating that the registration authority 118 will not provide a temporary registration certificate to the mobile device 102 at 218. In the absence of a temporary registration certificate, the mobile device 102 may be restricted from transmitting data, or even if it transmits data, all recipient devices may be configured to discard the message based on determining that the data message lacks a temporary registration certificate. Alternatively, if the registration authority 118 is able to verify that the certificate is generated by the certificate authority, the registration authority 118 may generate a temporary transmission certificate according to a predetermined protocol.

[0071] The temporary transmission certificate generated for the mobile device 102 may include a public key associated with the mobile device 102. In some embodiments, the registration authority 118 may generate a public / private key pair for the mobile device 102, which may have generated its own public / private key pair and provided its public key to the registration authority 118 along with its transmission registration certificate at 214. The registration authority 118 may maintain an association between the mobile device 102 and its public key or the mobile device 102. To generate a temporary transmission certificate, the registration authority 118 may encrypt the public key of the mobile device and any suitable data associated with the mobile device 102 using the registration authority's private key. The temporary transmission certificate may be utilized for a temporary period of time (e.g., one week, one day, one month, 12 hours, etc.) that may be implemented by the registration authority 118. If a temporary transmission certificate is generated, the mobile device 102 may receive the certificate and the public key of the registration authority 118 at 218 and store the received data in a local memory. If the public / private key pair of the mobile device 102 is generated by the registration authority 118, the private key may also be provided at 218.

[0072] At 220, the mobile device 102 may begin transmitting data via the network 108 according to the permission granted by the transmission registration certificate received at 210. For example, the mobile device 102 may transmit a BSM data message via the network 108. In some embodiments, the software and / or hardware of the mobile device 102 may be configured to restrict data transmission according to the transmission level provided in its transmission registration certificate. The mobile device 102 may use its private key to encrypt any suitable portion of the data message. In some embodiments, the mobile device may generate a digital signature and include the digital signature in the message. The mobile device 102 may insert its temporary transmission certificate in the data message before transmission. The RV 110 (e.g., a receiver of data messages from the mobile device 102) or any suitable receiver of the data message may be configured to decrypt the certificate using the public key of the registration authority 118 in order to retrieve the public key of the mobile device 102. The public key of the mobile device 102 may then be used by the receiving device to decrypt any suitable portion of the data message and to confirm the digital signature to ensure the authenticity of the sender and / or the integrity of the data message (e.g., to ensure that the message has not been altered).

[0073] At 222, the registry 118 may determine, according to a predetermined protocol, that an expiration time has been reached. In response to this determination, the registry 118 may generate a new public / private key pair for itself.

[0074] At 224, the registration authority 118 may transmit its new public key to all previously registered V2X devices (e.g., all transmitting devices that previously obtained a temporary transmission certificate). Each device that receives the public key may be configured to discard the previously used public key of the registration authority 118 and store the new public key in memory. In some embodiments, each device with a previously provided temporary transmission certificate may be configured to obtain a new temporary transmission certificate in response to receiving the new public key of the registration authority 118. As an example, the mobile device 102 may perform the above operations again at 214. The operations of 214 to 224 may be repeated any suitable number of times.

[0075] It should be understood that since the temporary transfer certificate is obtained by the mobile device 102 at least in part based on the vehicle capabilities associated with the vehicle 104, if the mobile device 102 is paired with another vehicle, the mobile device 102 can be configured to request (registration certificates) and / or temporary transfer certificates applicable to the newly paired vehicle via method 200.

[0076] In some embodiments, mobile device 102 may be allowed to transmit on network 108 even if mobile device 102 cannot meet latency, accuracy, and / or throughput requirements. In these scenarios, mobile device 102 may be required to add metadata in the messages it transmits indicating its limitations / deficiencies.

[0077] Figure 3 1 is a flow chart depicting a method 300 for obtaining one or more transmission credentials on behalf of one or more third-party sensors according to an embodiment. Figure 1 The mobile device 102 of the agent of the vehicle 104, or the vehicle 104 if the vehicle 104 is a V2X-capable device, can be used to request the transmission of the Figure 1 A temporary transmission certificate for sensor data collected by one or more third-party sensors 105.

[0078] The method 300 may begin at 302, where the V2X user device 301 may exchange any suitable data with the third-party sensor(s) 105 to obtain identifier(s) associated with the third-party sensor(s) 105. In some embodiments, the data exchanged at 302 may include a public key of a public / private key pair generated by the third-party sensor(s) 105 or by the V2X user device 301 on behalf of each third-party sensor 105.

[0079] At 304, the V2X user device 301 may transmit the sensor identifier(s) to the certificate authority 116. In some embodiments (e.g., when the V2X user device 301 is to transmit sensor data collected by the third-party sensor(s) 105), the V2X user device 301 may transmit any suitable vehicle capabilities associated with the V2X user device 301 (e.g., vehicle capabilities corresponding to the vehicle 104) along with the sensor identifier(s). In other embodiments (e.g., when one or more of the third-party sensor(s) 105 are to transmit their own sensor data), sensor identifier(s) for the sensors that may be transmitting their own sensor data may be provided.

[0080] At 306, the certificate authority 116 may be configured to identify (e.g., via a predefined set of rules) whether the data received at 304 indicates that the data collected by the third-party sensor(s) 105 meets the accuracy requirements and / or whether the transmitting device(s) (e.g., the V2X user device 301 and / or the third-party sensor(s) 105) are able to meet latency and / or throughput transmission requirements associated with transmitting data messages via the network 108 (e.g., the V2X network). The certificate authority 116 may be configured to generate one or more transmission registration certificates for each of the transmitting device(s) that is determined to meet the accuracy and / or latency transmission requirements (e.g., for any suitable combination of the V2X user device 301 and / or the third-party sensor(s) 105). As described above, the transmission registration certificate may indicate a transmission level corresponding to a particular type of data that the certificate holder is permitted to transmit. In some embodiments, the transmitting device may be granted an enhanced active registration certificate to enable the transmitting device to transmit sensor data obtained from the third-party sensor(s) 105 (and / or enable the third-party sensor(s) 105 to transmit their own sensor data via the network 108).

[0081] At 310 , the certificate authority 116 may transmit any generated registration certificates to the V2X user equipment 301 .

[0082] At 312, the V2X user device 301 may request a temporary transmission certificate for the third-party sensor(s) 105 by providing each transmission registration certificate received at 310 to the registration authority 118. When the V2X user device 301 is the intended transmitting device, the transmission registration certificate provided at 310 and the public key of the public / private key pair generated by and associated with the V2X user device 301 may be provided at 312. When one or more of the third-party sensor(s) 105 are the intended transmitting device(s), the registration certificate corresponding to each third-party sensor and its corresponding public key generated at 302 may be provided at 312. As discussed above, the registration authority 118 may be configured to manage temporary transmission certificates for all transmitting devices of the network 108.

[0083] At 314, registration authority 118 may validate the transmitted enrollment certificate(s) received at 312 by decrypting the certificate(s) using a public key associated with certificate authority 116. Registration authority 118 may verify that an identifier of certificate authority 116 is included in each certificate. If registration authority 118 cannot verify that the certificate(s) were provided by certificate authority 116, registration authority 118 may discard the data provided at 312.

[0084] At 316, the registration authority 118 may transmit data to the V2X user device 301 indicating that the registration authority 118 will not provide the requested temporary registration certificate(s) (e.g., because it cannot verify the one or more certificates provided at 312) or that the registration authority 118 may provide the generated temporary transmission certificate at 316. If the third-party sensor(s) 105 are the intended transmitting device, the V2X user device 301 may forward the temporary transmission certificate to the third-party sensor(s) 105, which may then use the temporary transmission certificate to transmit their individual sensor data via the network 108 at 320. The third-party sensor(s) 105 may encrypt and / or digitally sign the message (or one or more portions of the message) using their temporary transmission certificate, and the temporary transmission certificate may be included in the transmitted message. The RV 110 may use the above in conjunction with Figure 2 The techniques discussed at 220 are used to decrypt and authenticate the data message.

[0085] If the V2X user device 301 is the intended transmitter, the operations of 318 and 320 may be skipped and the method may proceed to 322, where sensor data collected by the third-party sensor(s) 105 may be provided to the V2X user device 301. The V2X user device 301 may be configured to encrypt and / or digitally sign any suitable portion of the sensor data and transmit the encrypted / digitally signed data with the temporary transmission certificate via the network 108 at 324. The temporary transmission certificate(s) transmitted at 320 and / or 324 may include a public key of the transmitting device signed by a private key of the registration authority 118. Thus, the temporary transmission certificate(s) transmitted at 320 and / or 324 may be used by a receiving device (e.g., RV 110) to obtain the public key of the transmitting device, which may be used to confirm the digital signature and / or to decrypt a portion of the received message.

[0086] At 326, the registry 118 may determine, according to a predetermined protocol, that an expiration time has been reached. In response to this determination, the registry 118 may generate a new public / private key pair for itself.

[0087] At 328, the registration authority 118 may transmit its new public key to all previously registered V2X devices (e.g., all transmitting devices that previously obtained temporary transmission certificates for themselves or on behalf of another device). Each device (e.g., V2X user device 301) that receives the public key may be configured to discard the previously used public key of the registration authority 118 and store the new public key in memory. In some embodiments, each device with one or more previously provided temporary transmission certificates may be configured to obtain new (temporary transmission certificates) in response to receiving the new public key of the registration authority 118. As an example, the method may return to 312. The operations of 312 to 328 may be repeated any suitable number of times.

[0088] Figure 4 4 is a flow chart depicting a method 400 for determining V2X transmission data using a plurality of mobile devices according to an embodiment. Figure 1-3 A single mobile device is depicted acting as a proxy for a single vehicle, but any suitable number of mobile devices may act as a proxy for a single vehicle. As an example, mobile device 102 may be a smartphone of a driver (or passenger) of vehicle 104, and mobile device 402 may be a smartphone of a passenger of vehicle 104. In some embodiments, the mobile device(s) may conform to a master / slave model, where one device (the master) processes data provided by other devices (slave) and serves as a communication hub for the group.

[0089] Method 400 can begin at 404 where mobile device 102 and mobile device 402 can execute any suitable selection algorithm to determine which of the two devices will be designated as a “master” and which will be a “slave.” For purposes of illustration, mobile device 102 can be selected as the master.

[0090] At 406 , the mobile device 102 may obtain vehicle data from the vehicle 104 and configuration data from the mobile device 402 identifying the various sensors, processing device(s), memory resource(s), etc. utilized by each device.

[0091] At 408, the mobile device 102 may perform operations similar to method 200 to obtain a certificate from a certificate authority (e.g., Figure 2The mobile device 102 may receive and / or transmit a registration certificate to a certificate authority 116 of the network 108, an RSU of the network 108, a remote vehicle (e.g., RV 110), etc. In some embodiments, the mobile device 102 may send a superset of data to the certificate authority, the superset of data including vehicle capabilities associated with the vehicle 104, configuration data associated with the mobile device 402, and the mobile device 102's own configuration data identifying various sensors, processing devices, memory resources, etc. utilized by the mobile device 102.

[0092] Assuming the registration certificate is received in response to the operations performed at 408 , the mobile device 102 may begin receiving data from the network 108 (eg, from the RV 110 ) at 410 .

[0093] At 412, the mobile device 102 can perform any suitable operations associated with receiving and / or processing the data message. As an example, the mobile device 102 can perform any suitable operations associated with receiving and / or processing the data message by determining that one or more data elements of the data message match the data from the registration data (e.g., Figure 1 The data message may be determined to be relevant to the vehicle 104 by determining a specific threshold of vehicle attributes ascertained from the registration data 114 of the vehicle 104. As another example, if the message is deemed relevant and it contains data elements that provide additional vehicle capabilities of the vehicle 104, the mobile device may store these additional vehicle capabilities in the local memory along with the registration data 114, thereby augmenting the known data about the attributes of the vehicle 104. In some embodiments, the mobile device 102 may be configured to generate driver assistance information. As an example, the mobile device 102 may generate any suitable alerts, warnings, and / or the following information about Figure 6 Real-time traffic model discussed.

[0094] At 414, the driver assistance information generated at 412 can be transmitted to the vehicle 104 for presentation at 414. In some embodiments, the driver assistance information can be graphically displayed at the display of the vehicle 104 and / or the driver assistance information can be audibly presented. According to some embodiments, the data message received at 410 may include a message type. Example message types may include "vehicle to vehicle", "proxy vehicle to vehicle", "vehicle to human driver", "human driver to vehicle", "human driver to human driver" or "general broadcast". Any suitable data provided from the data message can be color-coded and / or otherwise visually distinguishable so that the driver or passenger viewing the information at the display of the vehicle 104 can distinguish the data according to each message type. As an example, some data provided to the human driver from the vehicle can be displayed with blue text, while the data provided by another human driver can be provided with red.

[0095] Assuming the transport enrollment certificate is received in response to the operation of 408, the method can proceed to 416, where the mobile device 102 can transmit the transport enrollment certificate to a registration authority (e.g., Figure 1 In some embodiments, the mobile device 102 may generate a public key / private key pair and transmit the public key at 410 along with the transport enrollment certificate.

[0096] At 418, the mobile device 102 can obtain sensor data from the vehicle 104 and / or the mobile device 402. It should be understood that data can be obtained from these devices at the same time, at different times, according to a schedule, periodically, or at any suitable time. In some embodiments, the sensor(s) of the mobile device 402 and / or the vehicle 104 can collect sensor data at any suitable time and communicate the data to the mobile device 102 for transmission.

[0097] At 420, the mobile device 102 may be configured to format the sensor data collected from the vehicle 104 and / or the mobile device 402 and / or the sensor data collected by its own one or more onboard sensors and transmit one or more data messages via the network 108. As an example, the mobile device 102 may transmit a BSM that may be received by the RV 110 (a participant in the network 108). In some embodiments, the data message(s) transmitted at 420 may be broadcast, or the data message(s) may be directed to specific recipients, as may be referred to in Figure 7 discussed in further detail.

[0098] Figures 5A-5C A technique for assigning trust values ​​to one or more entities of a V2X environment according to an embodiment is shown. The trust value can quantify the accuracy with which data provided by a device can be trusted. Any suitable numbering protocol can be utilized. The specific values ​​used in the following examples are merely illustrative and are not intended to limit the scope of the present disclosure. Although a legacy vehicle (LV), a remote vehicle (RV), and a proxy device (PD) operating as a proxy for a legacy vehicle are used in the following examples, any suitable combination of V2X-capable devices (PD, RV, RSU, etc.) can be similarly utilized.

[0099] Figure 5ASeveral V2X-capable devices transmitting data with corresponding trust values ​​are depicted. As an example, RV504 and PD 506 may obtain sensor data indicating a speed measurement of LV 502 during their respective operations. For example, the sensor(s) of RV 504 may identify the speed of LV 502 as 20 miles per hour (mph), while PD 506 may obtain sensor data (from its own sensors or sensors of the vehicle and / or other mobile devices in the vehicle) that identifies the speed of LV 502 as 22mph. RV 504 may transmit a trust value (e.g., 50) with its measurement, indicating that the sensor that obtained the data is configured to be accurate within plus or minus 0.5mph. Similarly, PD 506 may transmit a measurement of 22mph with a trust value (e.g., 30), wherein the trust value indicates that the sensor that obtained the data is configured to be accurate within 3mph.

[0100] In some embodiments, PD 506 can be configured to prefer (e.g., utilize) measurements provided by RV 504 based at least in part on trust values ​​associated with and / or provided with the corresponding measurements, because the data of RV 504 is more likely to be more accurate than sensor data obtained by PD 506.

[0101] In some embodiments, because the measurements of PD 506 are within the known error range of the sensor, and because PD 506 provides an indication of the accuracy of the measurements, the confidence value associated with PD 506 (at least for the speed measurements) may remain unchanged.

[0102] Figure 5B Depicts an example where a trust value can be modified. Figure 5A . If the trust value of PD 506 instead indicates an accuracy of 1 mph, RV 504 and / or PD 506 may identify that the trust value of PD 506 does not indicate the actual accuracy of the measurement. In some embodiments, RV 504 may transmit a data message to PD 506 to modify the trust value associated with the sensor, or PD 506 may identify the difference itself and adjust its trust value accordingly (e.g., to 20) to indicate the new accuracy (e.g., accuracy within 2 mph). Thereafter, PD 506 may use the trust value when reporting measurements from the sensor.

[0103] Thus, in some embodiments, each portion of the data may be provided with a trust value indicating the accuracy of the sensor that obtained the data. In some embodiments, a V2X-capable device may manage multiple trust values ​​corresponding to each sensor to which it has access. In some embodiments, a V2X-capable device may calculate an aggregated trust value (e.g., an average trust value for all of its sensors). In either scenario, the trust value(s) may be adjusted up or down over time as other data sources are used to identify the accuracy of the data provided by the V2X-capable device. It should be understood that only V2X-capable devices that contain sensor(s) with high trust values ​​can cause the trust value of a sensor of another device to be adjusted upward. This is at least because only a device with a higher accuracy can confirm a higher accuracy in that other device.

[0104] Figure 5C Another view of an ongoing example in which a new RV arrives is depicted. In some embodiments, the RV 508 may operate with a default trust value associated with the sensor(s) providing its measurements. In some embodiments, the RV 504, PD 506, or any suitable V2X-capable device may be configured to assign trust values ​​to measurements provided by the RV 508.

[0105] As an example, PD 506 may ascertain that a speed measurement of 21 mph falls within its own error range (e.g., 22 mph + or -2 mph) based at least in part on its provided measurement of 22 mph. Thus, PD 506 may, at best, identify the trust value of RV 508 as at least as accurate as itself and transmit data to PD 506 indicating that the measurement provided by RV 508 should be associated with a trust value of at least 20. Similarly, RV 504 may be configured to determine that the measurement provided by RV 508 is within 1 mph of the actual speed of LV 502 (at least as determined by RV 504). RV 504 may ascertain that a speed measurement of 21 mph provided by RV 508 is within 1 mph of the speed of LV 502 (at least as determined by RV 504) based at least in part on its own speed measurement of 20 mph. Thus, RV 504 may identify a trust value (e.g., 40) for RV 508 that is less than RV 504's own trust value (e.g., 50) to indicate a higher degree of accuracy than the accuracy of the measurements provided by PD 506, but a lower degree of accuracy relative to the measurements provided by RV 504. As each V2X-capable device operates, the trust value(s) it maintains may fluctuate over time. In some embodiments, if the trust value of a particular sensor drops below a threshold, the device may generate driver assistance information to alert a user to a possible hardware and / or software failure in the sensor.

[0106] Figure 6 is a diagram illustrating an example technique for providing a real-time traffic model 600 according to at least one embodiment. The real-time traffic model 600 is intended to be used as Figure 1 In some embodiments, the real-time traffic model 600 can be generated by an agent device (e.g., Figure 1 mobile device) or can be accessed via Figure 1 The data elements of the real-time traffic model 600 may be derived and generated based at least in part on data elements received via any suitable combination of V2X messages received from any suitable number of sources. In some embodiments, the real-time traffic model 600 may include a map 601 representing an area (e.g., a threshold distance from a device generating the model) and a number of vehicles (e.g., vehicles 602-632) within the area. Vehicles 634 and 636 may be generated based at least in part on data elements received via any suitable combination of V2X messages received from any suitable number of sources. Figure 6 600 to indicate that two additional vehicles are physically present in the area, however, for reasons that will be discussed further below, these vehicles are not displayed in the real-time traffic model 600.

[0107] like Figure 6 As depicted in , the real-time traffic model 600 depicts an “ego vehicle” (e.g., ego vehicle 602), which is a vehicle for which the real-time traffic model 600 is generated and displayed. The real-time traffic model 600 may be composed of components of the ego vehicle (e.g., Figure 1 The real-time traffic model 600 may be generated by a proxy device associated with the ego vehicle (e.g., a processor 1110). Fig.13 In some embodiments, the ego vehicle 602 may be depicted in a different color and / or style than other graphical elements representing other vehicles, such that the color and / or style visually distinguishes the ego vehicle 602 from other vehicles of the real-time traffic model 600. In some embodiments, the ego vehicle 602 (or a proxy device thereof that may be generating the real-time traffic model 600) may be configured to access sensor(s) that may collect data indicating the presence and various attributes of the vehicle. Figure 6 608-618 depicted in.

[0108] In some embodiments, vehicle 604 is an intelligent vehicle (e.g., a vehicle with V2X capabilities), and vehicle 606 is an old vehicle with a transmitter proxy device. The proxy devices of vehicle 604 and vehicle 606 can be configured to access corresponding sensors, which can collect data indicating the presence and various attributes of other vehicles in the area. For example, vehicle 604 can obtain sensor data indicating the presence and various attributes of vehicles 608, 610 and 620-626. Similarly, the proxy device of vehicle 606 can obtain sensor data indicating the presence and various attributes of vehicles 614, 616 and 628-632. Vehicles 634 and 636 may not be displayed in the real-time traffic model 600 because there is no transmitter vehicle (or transmitter proxy device) collecting sensor data for these vehicles. Each of vehicles 634 and 636 is shielded by other vehicles so that they are not detected by self-vehicle 602, nor by intelligent vehicles 604 or 606. If equipped with appropriate sensors (e.g., proximity sensors, cameras, LIDAR, sonar, radar, etc.), vehicle 626 can potentially obtain sensor data about vehicles 634 and 636. Therefore, the real-time traffic model generated at vehicle 626 can display vehicles 634 and 636 based on data collected from the vehicle 626's own sensors. However, because vehicle 626 is a legacy vehicle that includes a proxy device that only receives from the V2X network, none of the other vehicles 602, 603, or 606 can display the presence and / or data associated with vehicles 634 and 636 on their respective real-time traffic models.

[0109] Each of vehicles 602, 604, and 606 is a V2X-capable device (e.g., a V2X-capable vehicle or a vehicle including a proxy device) that can be configured to transmit the corresponding vehicle attributes and / or vehicle attributes of other vehicles sensed by the corresponding device. Vehicles 608-624 and 628-636 are intended to depict legacy vehicles (e.g., vehicles that do not have V2X capabilities). In some embodiments, if vehicle 626 includes a proxy device that transmits data indicating that it is listening on the network, the real-time traffic model generated by vehicles 602-606 (including real-time traffic model 600) can display a distinguishing feature to indicate that vehicle 626 includes a receiving proxy device. Otherwise, vehicle 626 can be displayed similarly to each of the other legacy vehicles (e.g., vehicles 608-624).

[0110] Each graphic element of the depiction vehicle 602-632 of the real-time traffic model 600 can correspond to a storage object maintained by the self-vehicle (or an agent device operating as an agent representing the self-vehicle 602). In some embodiments, the object can store the correlation of data from multiple data sources. As an example, the object corresponding to the vehicle 608 can include data provided by the vehicle 602 and the vehicle 604. The object for the vehicle 610 can store the data provided by the vehicle 602 and 604. The object can store any suitable vehicle attributes, such as the color, brand, model, (all) image, license plate number, speed, acceleration, heading, identification features (e.g., broken left taillight, dent on the right rear fender, broken windshield, etc.), vehicle status (e.g., on fire, smoke, far below the current speed limit, right turn signal on, left turn signal on, etc.), occupant metadata, etc. In a similar manner, vehicles 614 and 616 can correspond to the corresponding objects that store the data provided by vehicles 602 and 606.

[0111] Data corresponding to vehicles 608, 610, 614, and 616 (collectively, anchor vehicles) may be used as reference points. As an example, while graphical elements may be displayed for vehicles 608-618 due to ego vehicle 602 having sensor data about each vehicle, vehicles 620-632 may be stored as objects and displayed graphically due to receiving data indicating the position and / or attributes of each vehicle relative to the anchor vehicle from vehicle 604 or vehicle 606. Thus, while ego vehicle 602 itself does not collect sensor data about vehicles 620-632, it still knows the presence of the vehicles and potentially various attributes of each vehicle based on receiving such data from other V2X transmitting vehicles in the vicinity. Thus, the real-time traffic model 600 may include graphical elements representing vehicles 608-632 even if those vehicles are not (or at all) transmitting V2X messages about themselves.

[0112] Each type of vehicle (e.g., self, smart, legacy with transmitter PD, legacy with receiver PD, legacy (PD unknown), etc.) can be visually distinguishable based at least in part on any suitable attribute (e.g., color, shape, text, etc.) It should be understood that the depiction of the real-time traffic model is intended to be illustrative and non-limiting.

[0113] In some embodiments, each of the vehicles 602-606 may be configured to use any suitable protocol to jointly determine a unique identifier for themselves and the vehicles 608-632. In some embodiments, if a unique vehicle attribute (e.g., license plate number) is known from various sensor data (or in their own case, vehicle capabilities), the vehicles 602-606 may utilize the attribute to identify the vehicle. Otherwise, the vehicles 602-606 may generate a unique identifier for each vehicle. In some embodiments, the vehicles 602-606 may then direct the V2X message to any suitable vehicle in the vehicles 602-632. For example, the vehicle 602 may send a data message (e.g., a person-to-person message type) that includes information indicating a warning from the driver of the vehicle 602 to the driver / (s) of the vehicle 604 that the vehicle 618 is approaching the vehicle 608 quickly from the rear left side and appears to be driving recklessly. This may facilitate operation of vehicle 604, as vehicle 604 and / or the driver / occupants of vehicle 604 may not yet be aware of vehicle 618. In some embodiments, a unique identifier need not be determined, and instead the V2X data message may include attributes of the vehicle to which the message is related and / or directed. Thus, in some embodiments, rather than using a specific identifier determined by a set of V2X devices (e.g., V2X1234), attributes of the vehicle may be used to identify the intended recipient of the message (e.g., White, Acme, Sedan).

[0114] The apparatus for providing a real-time traffic model may include one or more software and / or hardware components of an agent device, such as described in more detail below. Fig.13 1305, processor(s) 1310, memory 1360, wireless transceiver(s) 1330, proxy processing module 1365, and output device(s) 1315 illustrated in FIG.

[0115] In some embodiments, the means for providing a real-time traffic model may include a vehicle with V2X capability (e.g., Figure 1 One or more software and / or hardware components of a vehicle 1100), such as described in more detail below Fig.11 1101, processor(s) 1110, memory 1160, wireless transceiver(s) 1130, vehicle processing module 1165, and input / output device(s) 1168 are illustrated in FIG.

[0116] Figure 7 is an illustration of a method for implementing a V2X environment 700 (eg, Figure 1 100 ). Vehicles AD, N, and M may be V2X-capable devices (e.g., V2X-capable vehicles and / or vehicles with V2X-capable proxy devices). While previously traveling, vehicle A may have known various vehicle attributes associated with any suitable combination of vehicles AG. These attributes may have been communicated to any suitable combination of vehicles BD in a manner similar to Figure 6 Then, vehicle A can stop at intersection 702 according to the red light signal and traffic regulations. Vehicles N and M can also stop at intersection 702.

[0117] At a later point in time, any suitable combination of vehicles A, N, and / or M may collect sensor data indicating that vehicle J is running a red light, thereby creating a potential for a collision. In some embodiments, any suitable combination of vehicles A, N, and / or M may broadcast a V2X message indicating the actions of vehicle J to warn other vehicles of the potential danger. In some embodiments, vehicle A may be configured to determine (based on its own sensor data and sensor data provided by vehicles B and / or C) that vehicles B and C are parked behind it. In some embodiments, vehicle A may use a V2X message such as Figure 6 The data message may be directed specifically to vehicles D, E, F, and G using any suitable combination of unique V2X identifiers previously assigned to vehicles and / or any suitable attributes previously received related to vehicles D, E, F, and G as described in . In some embodiments, if vehicle A knows the approximate location of vehicle DG, it may be configured to send directed messages only to vehicles D and E because those vehicles may themselves slow down to cause vehicles F and G to also slow down.

[0118] Figure 8 is a description of a device used by a mobile device (e.g. Figure 1-4 The mobile device 102) represents a vehicle (e.g., Figure 1-4 Flowchart of method 800 for transmitting data to a vehicle 104). In some embodiments, the mobile device may include a memory (e.g., a non-transitory computer-readable medium) storing executable instructions for transmitting data on behalf of a vehicle and one or more processors communicatively coupled to the memory, the one or more processors being configured to perform method 800 based on executing the instructions stored in the memory. An apparatus for performing method 800 may include software and / or hardware components of the proxy device 1300, such as described in more detail below. Fig.131305, processor(s) 1310, memory 1360, wireless transceiver(s) 1330, proxy processing module 1365, and output device(s) 1315 illustrated in FIG.

[0119] Method 800 may begin at 810, where vehicle capabilities associated with a vehicle are obtained. In some embodiments, the vehicle capabilities indicate one or more sensors of the vehicle.

[0120] At 820, the mobile device can determine mobile device capabilities indicative of one or more sensors, processing resources, or both of the mobile device.

[0121] At 830, the mobile device may request a certificate from a credential authority (e.g., Figure 1-4 The certificate authority 116 and / or registration authority 118) obtains one or more transmission credentials (e.g., for vehicle-to-vehicle transmission within the V2X network).

[0122] At 840, in response to obtaining the one or more transmission credentials for vehicle-to-vehicle transmission, the mobile device may utilize the one or more transmission credentials to transmit on behalf of the vehicle via one or more transceivers (e.g., Fig.13 (s) wireless transceiver 1330) transmits one or more data messages.

[0123] Figure 9-13 is an illustration of systems, structural devices, vehicle components, and other devices, components, and systems that can be used to implement the techniques provided herein for detecting the degree of motion sickness a person may be experiencing while traveling in an autonomously driven vehicle.

[0124] Fig. 9is an illustration of a system 900 in which V2X-capable devices (e.g., vehicles, proxy devices, RSUs, servers, etc.) can communicate over various networks, according to an embodiment. In an embodiment, vehicle A 980 can communicate with a V2X or otherwise communication transceiver-enabled vehicle B 990 over a link 923 using a V2X or other wireless communication transceiver, for example, in an embodiment, to perform inter-vehicle relative positioning, negotiation for lane changes or for crossing intersections, and exchange V2X data elements (such as global navigation satellite system (GNSS) measurements, vehicle status, vehicle position and vehicle capabilities, measurement data and / or calculated status, vehicle capabilities, occupant metadata), and other V2X vehicle status steps that may not be covered in the V2X capabilities data elements. In an embodiment, vehicle A 980 may also communicate with vehicle B 990 over a network, for example, via wireless signals 922 to / from base station 920 and / or via wireless signals 932 to / from access point 930, or via one or more communication-enabled RSUs 925, any of which may relay communications, information, and / or convert protocols for use by other vehicles, such as vehicle B 990, particularly in an embodiment where vehicle B 990 is unable to communicate directly with vehicle A 980 on a common protocol. In an embodiment, the RSU(s) may include various types of roadside beacons, traffic and / or vehicle monitors, traffic control devices, and location beacons.

[0125] In some embodiments, vehicle A 980 may lack a V2X communication component (or such communication component is faulty and / or disabled) such that it is unable to send and / or receive V2X data elements with other entities of the system 900 (e.g., vehicle B 990, RSU(s) 925, servers 940, 945, 950, 955, 960, 965, 968, etc.). Vehicles that are unable to participate in V2X communications are referred to herein as "legacy vehicles." Thus, in some embodiments, vehicle A 980 is a legacy vehicle. In some embodiments, the mobile device 902 ( Fig.13The example of a proxy device 1300 of the system 900 (e.g., vehicle B 990, RSU(s) 925, servers 940, 945, 950, 955, 960, 965, 968, etc.) may be configured to send and / or receive V2X messages to / from any suitable combination of entities of the system 900 (e.g., vehicle B 990, RSU(s) 925, servers 940, 945, 950, 955, 960, 965, 968, etc.). The mobile device 902 may be configured to communicate over a wireless communication network using various wide area network (WAN), wireless local area network (WLAN), and / or personal area network (PAN) protocols to send and / or receive wireless messages with vehicle A 980 (or any suitable component of vehicle A 980) using various protocols. In one embodiment, the mobile device 902 may include various combinations of WAN, WLAN, and / or PAN transceivers. In one embodiment, these transceivers may include The local transceiver, WAN wireless transceiver and / or mobile wireless transceiver may include a WAN transceiver, an access point (AP), a femtocell, a home base station, a small cell base station, a home Node B (HNB), a home evolved Node B (HeNB) or a next generation Node B (gNodeB) and may provide access to a wireless local area network (WLAN, e.g., an IEEE 802.11 network), a wireless personal area network (PAN, e.g., a Bluetooth network) or a cellular network (e.g., an LTE network or other wireless wide area network, such as those discussed in the next paragraph). It should be understood that these are merely examples of networks that can communicate with the mobile device 902 over a wireless link, and the claimed subject matter is not limited in this respect.

[0126] In some embodiments, the mobile device 902 can communicate with vehicle A 980 via a PAN, such as a Bluetooth network. In some embodiments, the mobile device 902 can also communicate with vehicle A 980 via a link 936 or over a network, for example, via wireless signals 937 to / from a base station 920 and / or via wireless signals 934 to / from an access point 930, or via one or more communication-enabled RSUs 925, any of which can relay communications, information, and / or convert protocols for use by other vehicles, such as vehicle B 990, particularly in an embodiment where vehicle B 990 is unable to communicate directly with vehicle A 980 at a common protocol.

[0127] The mobile device 902 may be configured to receive any suitable vehicle data from any suitable combination of components of the vehicle A 980 (e.g., vehicle sensor(s) 1145, vehicle motion sensor(s) 1140, camera(s) 1135, radar 1153, LIDAR 1150, power and drive systems and related systems 1175, input / output device(s) 1168, and / or systems 1155) via one or more communication networks. In some embodiments, the mobile device 902 may be configured to receive vehicle capabilities and / or occupant metadata from one or more interfaces of the mobile device 902, based on one or more images captured by the mobile device 902, from the vehicle A 980, or any suitable combination of the foregoing. The mobile device 902 may be configured with one or more sensors and may exchange locally acquired sensor data with the vehicle. In some embodiments, the mobile device 902 may be configured to communicate with the vehicle A 980. Fig.11 The mobile device 902 may interface (send and / or receive data) with the input / output device(s) 1168 of the vehicle A 980. For example, the mobile device 902 may present data via the input / output device(s) 1168, and / or the mobile device 902 may receive data (e.g., user input) collected and provided by the input / output device(s) 1168 of the vehicle A 980.

[0128] It should be understood that any suitable sensor in sensors / components 1135, 1140, 1145, 1150, 1153 may be installed after market launch. Thus, any of sensors / components 1135, 1140, 1145, 1150, 1153 may be a third party sensor (e.g., Figure 1 Example of (multiple) third-party sensors 105).

[0129] The mobile device 902 may be configured to generate driver assistance information (eg, Figure 1 As an example, the mobile device 902 may be configured with a code (e.g., Fig.131365), which, when executed, causes the generation of visual and / or audible data (e.g., driver assistance information) indicating at least a portion of the data received via one or more V2X messages. As a simple example, the mobile device 902 may receive a V2X message indicating that a vehicle located in front of vehicle A 980 is emergency braking. The mobile device 902 may determine that the V2X message is related to vehicle A 980, and generate visual and / or audible data that may be presented at the mobile device 902 and / or at a display and / or speaker of vehicle A 980 (e.g., via the input / output device(s) 1168) via a display and / or speaker of the mobile device. The visual and / or audible data may indicate that braking is occurring ahead, thereby alerting the driver to the possibility of a collision.

[0130] The mobile device 902 may be configured to store vehicle and / or occupant metadata provided by a user or received as V2X message data. As an example, the mobile device 902 may be configured with code (e.g., Fig.13 The proxy processing module 1365 may be configured with code that, when executed, obtains occupant metadata from one or more nearby user devices (e.g., multiple mobile devices).

[0131] Mobile device 902 may be configured to receive any suitable V2X data messages from any suitable V2X-capable device of system 900. In some embodiments, mobile device 902 may correlate received data with any suitable data stored locally at mobile device 902 (e.g., vehicle capabilities, occupant metadata, sensor data, etc.) and may store data corresponding to entities and received from different sources in a single data container and / or in associated data containers.

[0132] In some embodiments, the mobile device 902 can be configured to transmit any suitable data (e.g., vehicle capabilities, occupant metadata, sensor data, trust values, weather data, road conditions, detected objects, etc.) via any suitable V2X data messages. In some embodiments, these data messages can be broadcast or the data messages can be directed (e.g., using a unique identifier and / or one or more attributes of the intended recipient). ... for itself and / or on behalf of any suitable number of devices (e.g., Figure 1 (the) third party sensor(s) 105) obtain any suitable registration certificates and / or temporary transmission certificates.

[0133] In some embodiments, the mobile device 902 may work in conjunction with one or more other mobile devices for data collection and / or transmission purposes. As an example, the mobile device 902 may perform the above combined Figure 4 The functionality discussed herein may be used with any of the mobile devices described herein.

[0134] generally, Figure 1-8 Any functionality discussed above as being performed by a mobile device may be performed by the mobile device 902 (e.g., by executing Fig.13 's proxy processing module 1365 code).

[0135] The mobile device 902 may communicate with a V2X or otherwise communication transceiver enabled vehicle B 990 over link 935 using a V2X or other wireless communication transceiver, for example, in one embodiment, to perform inter-vehicle relative positioning, negotiations for lane changes or for crossing intersections, and exchange V2X data elements (such as global navigation satellite system (GNSS) measurements, vehicle status, vehicle position and vehicle capabilities, measurement data, vehicle capabilities, occupant metadata and / or calculated status), and other V2X vehicle status steps that may not be covered in the V2X capabilities data elements. In one embodiment, the mobile device 902 can also communicate with vehicle B 990 over a network, for example, via wireless signals 937 to / from the base station 920 and / or via wireless signals 934 to / from the access point 930, or via one or more communication-enabled RSUs 925, any of which can relay communications, information and / or convert protocols for use by other vehicles (such as vehicle B 990), specifically in one embodiment where vehicle B 990 cannot communicate directly with vehicle A 980 according to a common protocol.

[0136] In an embodiment, the RSU(s) 925 may have a processor 925A configured to operate a wireless transceiver 925E to send and receive wireless messages (e.g., BSM or cooperative awareness messages (CAM) or other V2X messages) to / from vehicle A 980 and / or vehicle B 990 and / or mobile device 902, from base station 920 and / or access point 930. For example, the wireless transceiver 925E may send and / or receive wireless messages (such as V2X communications with vehicles) in various protocols, and / or communicate on a wireless communication network using various wide area network (WAN), wireless local area network (WLAN) and / or personal area network (PAN) protocols. In one embodiment, the RSU(s) 925 may include one or more processors 925A communicatively coupled to the wireless transceiver 925E and memory, and may include instructions and / or hardware to function as a traffic control unit 925C, and / or provide and / or process environmental and roadside sensor information 925D or use as a position reference for the GNSS relative position between it and the vehicle. In one embodiment, the RSU(s) 925 may include a network interface 925B (and / or wireless transceiver 925E), which in one embodiment may communicate with an external server (such as a traffic optimization server 965, a vehicle information server 955, and / or an environmental data server 940). In one embodiment, the wireless transceiver 925E may communicate on a wireless communication network by transmitting or receiving wireless signals from a wireless base transceiver subsystem (BTS), a Node B or an evolved Node B (eNodeB) or a next generation Node B (gNodeB) over a wireless communication link. In one embodiment, the wireless transceiver(s) 925E may include various combinations of WAN, WLAN and / or PAN transceivers. In one embodiment, the local transceiver may also be The local transceiver, WAN wireless transceiver and / or mobile wireless transceiver may include a WAN transceiver, an access point (AP), a femtocell, a home base station, a small cell base station, a home Node B (HNB), a home evolved Node B (HeNB) or a next generation Node B (gNodeB) and may provide access to a wireless local area network (WLAN, e.g., an IEEE 802.11 network), a wireless personal area network (PAN, e.g., a Bluetooth network) or a cellular network (e.g., an LTE network or other wireless wide area network, such as those discussed in the next paragraph). It should be understood that these are merely examples of networks that can communicate with the RSU(s) 925 over a wireless link, and the claimed subject matter is not limited in this respect.

[0137] The RSU(s) 925 may receive location, status, GNSS and other sensor measurements, and capability information, such as GNSS measurements, sensor measurements, speed, heading, location, stopping distance, priority or emergency status, and other vehicle-related information (such as vehicle capabilities, occupant metadata, etc.) from Vehicle A 980 and / or Vehicle B 990 and / or the mobile device 902. In some embodiments, the mobile device 902 may obtain such data from Vehicle A 980. In an embodiment, environmental information, such as road surface information / status, weather conditions, and camera information, may be collected and shared with vehicles via point-to-point or broadcast messaging. The RSU(s) 925 may utilize information received from vehicle A 980 and / or vehicle B 990 and / or mobile device 902, environmental and roadside sensors 925D via wireless transceiver 925E, and network information and control messages from, for example, traffic control and optimization server 965 to coordinate and direct traffic flow and provide environmental, vehicle, safety, and notification messages to vehicle A 980 and vehicle B 990. In one embodiment, the RSU(s) 925 may be configured to request and / or receive a receive registration certificate, a transmit registration certificate, and / or one or more temporary transmit certificates, or any suitable combination of the foregoing, from the certificate and registration server 958. In some embodiments, the certificate and registration server 958 may perform the above-described Figure 1-4 and any suitable functionality discussed with respect to the certificate authority 116 and / or registration authority 118 of 8.

[0138] The processor 925A may be configured to operate a network interface 925B, which in one embodiment may be connected to a network 970 via a backhaul, and which in an embodiment may be used to communicate and coordinate with various centralized servers, such as a centralized traffic control and optimization server 965, which monitors and optimizes traffic flow in an area, such as within a city or urban area or in a region. The network interface 925B may also be used to remotely access the RSU(s) 925 for crowdsourcing vehicle data, maintenance of the RSU(s) 925, and / or coordination with other RSU(s) 925, or other purposes. The RSU(s) 925 may have a processor 925A configured to operate a traffic control unit 925C, which may be configured to process data received from vehicles, such as vehicle A 980 and vehicle B 990, such as location data, stopping distance data, road condition data, identification data, and other information related to the status and location of nearby vehicles and the environment. The RSU(s) 925 may have a processor 925A configured to acquire data from environmental and roadside sensors 925D, which may include temperature, weather, cameras, pressure sensors, road sensors (e.g., for car detection), accident detection, motion detection, speed detection, and other vehicle and environment monitoring sensors.

[0139] In an embodiment, vehicle A 980 may also communicate with mobile device 902 using short-range communications and personal networks such as Bluetooth, Wi-Fi, or Zigbee or via V2X or other vehicle-related communication protocols, for example, in an embodiment to access a WAN and / or Wi-Fi network and / or in an embodiment to obtain sensor measurements and / or location measurements from mobile device 902. In an embodiment, vehicle A 980 may communicate with mobile device 902 using WAN-related protocols over a WAN network, such as via a WAN base station 920 or peer-to-peer using Wi-Fi Direct or via a Wi-Fi access point. Vehicle A 980 and / or vehicle B 990 may communicate using various communication protocols. In one embodiment, vehicle A 980 and / or vehicle B 990 may support various and multiple wireless communication modes (such as, for example, using V2X, Global System for Mobile Communications (GSM), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), High Rate Packet Data (HRPD), Wi-Fi, Bluetooth, WiMAX, LTE, 5G New Radio Access Technology (NR) communication protocols, etc.).

[0140] In an embodiment, vehicle A 980 may communicate over a WAN network using a WAN protocol via base station 920 or using a wireless LAN protocol such as Wi-Fi to communicate with a wireless LAN access point 930. The vehicle may also support wireless communications using, for example, WLAN, PAN (such as Bluetooth or ZigBee), digital subscriber line (DSL), or packet cable.

[0141] In one embodiment, vehicle A 980 and / or vehicle B 990 and / or mobile device 902 may include one or more GNSS receivers (e.g., GNSS receiver 1170 for vehicle A and / or B, GNSS receiver 1180 for mobile device 902) for receiving GNSS signals 912 from GNSS satellites 910 for position determination, time acquisition, and time maintenance. Various GNSS systems may be supported individually or in combination, using GNSS receiver xxx or other receivers to receive signals from BeiDou, Galileo, GLONASS and / or Global Positioning System (GPS) and various regional navigation systems such as Quasi-Zenith Satellite System (QZSS) and NavIC or Indian Regional Navigation Satellite System (IRNSS). Other wireless systems may be utilized, such as those that rely on beacons (such as, in one example, one or more RSUs 925, one or more wireless LAN access points 930, or one or more base stations 920). The various GNSS signals 912 may be used in conjunction with vehicle sensors to determine position, speed, proximity to other vehicles (such as between vehicle A 980 and vehicle B 990 ).

[0142] In one embodiment, vehicle A and / or vehicle B may have access to GNSS measurements and / or positions determined at least in part using GNSS provided by mobile device 902, which in one embodiment also has GNSS, WAN, Wi-Fi, and other communications receivers and / or transceivers. In one embodiment, vehicle A 980 and / or vehicle B 990 may have access to GNSS measurements (such as pseudorange measurements, Doppler measurements, and satellite IDs) and / or positions determined at least in part using GNSS provided by mobile device 902 as a fallback in the event that GNSS receiver 770 fails or provides a position accuracy below a threshold level.

[0143] Vehicle A 980 and / or Vehicle B 990 and / or mobile device 902 (as a proxy for Vehicle A 980) may access various servers on the network, such as a vehicle information server 955, a route server 945, a location server 960, a map server 950, an environmental data server 940, and a certificate and registration server 968. In some embodiments, Vehicle A 980 and / or Vehicle B 990 may be configured to request and / or receive a receipt registration certificate, a transmission registration certificate, and / or one or more temporary transmission certificates, or any suitable combination of the foregoing, from the certificate and registration server 958.

[0144] The vehicle information server 955 may provide information describing various vehicles (such as antenna locations, vehicle size, and vehicle capabilities) that may be used to make decisions about maneuvers relative to nearby cars (such as whether they can stop or accelerate in a timely manner, whether they are autonomously driven, whether they have autonomous driving capabilities, whether they have communication capabilities). In one embodiment, the vehicle information server 955 may also provide information about vehicle size, shape, capabilities, identification, ownership, occupancy, and / or determined location points (such as, for example, the location of a GNSS receiver) and the location of the vehicle boundaries relative to the determined location points.

[0145] Route server 945 may receive current location and destination information and provide routing information, map data, alternate route data, and / or traffic and street condition data for a vehicle.

[0146] In one embodiment, the location server 960 may provide location determination capabilities, transmitter signal acquisition assistance (such as GNSS satellite orbit prediction information, time information approximate location information and / or approximate time information), transceiver almanacs (such as those containing identification and locations for Wi-Fi access points and base stations), and in some embodiments, additional information related to routes (such as speed limits, traffic, and road status / building status). The map server 950 may provide map data such as road locations, points of interest along roads, address locations along roads, road sizes, road speed limits, traffic conditions and / or road conditions (wet, slippery, snowy / icy, etc.), road conditions (open, under construction, accidents, etc.). In one embodiment, the environmental data server 940 may provide weather and / or road related information, traffic information, terrain information, and / or road quality and speed information and / or other relevant environmental data.

[0147] In one embodiment, Fig. 9The vehicles 980 and 990 and the mobile device 902 in the embodiment can communicate on the network 970 via various network access points, such as wireless LAN access points 930 or wireless WAN base stations 920 on the network 970. In some embodiments, any suitable combination of vehicles 980, 990 and mobile devices 902 can also use various short-range communication mechanisms to communicate directly between devices, between vehicles, and between devices and vehicles, and between vehicles and devices, to communicate directly without going through the network 870, such as via Bluetooth, Zigbee, and 5G new radio standards.

[0148] Fig.10 The functional block diagram of a vehicle 1000 according to one embodiment is included. The vehicle 1000 may correspond to Figure 1 The vehicle 104 and / or RV 110 are as described in the above embodiments. Fig.10 The hardware and / or software components of the blocks shown in Fig.11 and described in more detail below.

[0149] like Fig.10 As shown in FIG, vehicle 1000 may receive vehicle and environment information from vehicle external sensors 1002, vehicle internal sensors 1004, vehicle capabilities 1006, external wireless information (such as RV's location and GNSS measurement information) 1008 (from the environment, from other vehicles, from (all) RSUs, from system servers) and / or from vehicle motion state 1010 (describing current and / or future motion state). Figure 1 The messages received by the vehicle 104 and / or HV 104 may, for example, convey the data provided in blocks 1008 and / or 1010. In one embodiment, the received vehicle, sensor, and environmental information may be stored in one or more processors 1110, DSP 1120, and memory 1160 (further described in detail in FIG. Figure 1100 ), the processor 1110, the DSP 1230, and the memory 1160 are connected and configured to provide external object sensing and classification, prediction and planning, and maneuver execution, as well as determining and updating V2X or other wireless data element values ​​(including GNSS data element values) and transmitting messaging including the determined data elements via one or more wireless transceivers 1030, the messaging and data elements may be sent and received via various devices, protocols, and standards, such as via SAE or European Telecommunications Standards Institute (ETSI) CV2X messages and data elements or other wireless and wireless V2X protocols supported by (these) wireless transceivers 1130. In some embodiments, the vehicle 1100 may be a legacy vehicle that lacks the ability to exchange messages and / or data elements via CV2X messages and / or via wireless V2X protocols. Therefore, in some embodiments, the vehicle 1100 may receive messages from a wireless V2X protocol. Fig. 9 The mobile device 902 (for example, the following combination Fig.13 In the example of the proxy device 1300 discussed above, the mobile device 902 may receive a V2X data element from a CV2X message received by the vehicle 1000. In the embodiment where the mobile device 902 acts as a proxy for the vehicle 1000, any suitable data received by the vehicle 1000 may additionally and / or alternatively be received by the vehicle 1000 from the mobile device 902 (after the mobile device 902 has received data from a data source such as Fig. 9 After the data is received by the server 940, 945, 950, 955, 960, 965 and / or 968, (the) RSU 925, vehicle B 990, etc.).

[0150] The inter-vehicle relative position determination box 1028 can be used to determine the relative position of vehicles in the area of ​​interest. In one embodiment, GNSS data is exchanged with vehicles (e.g., RV) or other devices (such as RSU) to determine and / or verify and / or improve the accuracy of relative positions associated with other vehicles or devices. In one embodiment, vehicles (or other devices) within the area of ​​interest can use broadcast position information (such as latitude and longitude received in messages (e.g., BSM) from other vehicles, other devices) and the position information of vehicles 1000 to determine approximate relative positions and / or approximate distances between vehicles.

[0151] In one embodiment, other input sources related to the vehicle (such as Fig. 9The servers 955, 945, 960, 950 and 940) may provide information (such as vehicle information, route planning, location assistance, map data and environmental data) and provide input and / or supplement and / or be used in conjunction with other inputs (e.g., road position data, map data, driving condition data and other data inputs related to the vehicle) which are used in conjunction with the inter-vehicle maneuver coordination 1024 to determine the maneuver execution 1026. In one embodiment, the map data may include the position of the roadside unit relative to the road position, wherein the vehicle may utilize the relative positioning between the RSUs in conjunction with the map data to determine the position relative to the road surface, particularly in scenarios where other systems may fail (such as due to low visibility weather conditions (snow, rain, sandstorms, etc.) In one embodiment, the map data from the map server 950 may be used in conjunction with relative and / or absolute data from neighboring vehicles and / or from the RSU(s) 925 to determine a high confidence absolute position and relative position with respect to the road / map for multiple vehicles. For example, if Fig. 9 Vehicle A 980 has a higher accuracy / high confidence position than other vehicles in communication with Vehicle A 980, such as Fig. 9Vehicle B 990 may use the GNSS information to obtain a highly accurate relative position and use the highly accurate position sent from vehicle A 980 to vehicle B 990 to determine a highly accurate position of vehicle B 990, even if the system of vehicle B 990 would otherwise be unable to calculate a highly accurate position in a particular situation or environment. In this scenario, the presence of vehicle A with a highly accurate position determination system provides a benefit to all surrounding vehicles by sharing one or more highly accurate positions along with ongoing relative position information. In addition, assuming the map data from the map server 950 is accurate, the ability to propagate highly accurate position data from vehicle A 980 to surrounding vehicles (such as vehicle B 990) enables surrounding vehicles to also accurately determine their relative positions to the map data, even in otherwise difficult signal / position environments. The vehicle information server 955 may provide vehicle information (such as size, shape, and antenna location) that may be used by, for example, vehicle A or other vehicles to determine not only the relative position between a GNSS receiver on vehicle A 980 and, for example, vehicle B 990, but also the distance between the closest points of vehicle A 980 and vehicle B 990. In one embodiment, traffic information from the traffic control and optimization server 965 may be used to determine overall path selection and route replanning, which is used in conjunction with the route server 945 (in one embodiment). In one embodiment, the environmental data server 940 may provide input regarding road conditions, black ice on the road, snow, water on the road, and other environmental conditions, which may also affect the decisions and decision criteria in the inter-vehicle maneuver coordination block 1024 and the maneuver execution block 1026. For example, in icy or rainy conditions, the vehicle 1000 may execute and / or request an increased inter-vehicle distance with adjacent vehicles or may select a route option that avoids hazardous road conditions (such as black ice and standing water).

[0152] Block 1028 may use various special or general purpose hardware and software (such as using processor 1010 ( Fig.11 110 or DSP 1120) and memory 1160 (again as in Fig.11)) or, in one embodiment, in a dedicated hardware block (such as a dedicated sensor processing and / or vehicle messaging core). According to some embodiments, the location of nearby vehicles may be determined by various means, such as based on timing measurements based on signals (such as round trip time (RTT) and arrival time (TOA)), signal strength of broadcast signals for vehicles, and distances determined based on broadcast latitudes and longitudes from neighboring vehicles and the current location of the vehicle. Additionally or alternatively, the location of nearby vehicles may be determined from sensor measurements (such as 5G new radio (NR), ultra-wideband (UWB), light detection and ranging (LIDAR), radio detection and ranging (RADAR), SONAR, camera measurements, or any combination thereof). In one embodiment, some or all of blocks 1002, 1004, 1006, 1008, and / or 1010 may have dedicated processing cores, for example, to improve performance and reduce measurement latency. In an embodiment, some or all of blocks 1002 , 1004 , 1006 , 1008 , and / or 1010 may share processing with block 1028 .

[0153] In some embodiments, vehicle external sensing 602 may include cameras, LIDAR, radar, proximity sensors, other sensors (e.g., devices for detecting weather, rain, snow, pressure changes, vertical directionality, ground position, proximity detection, etc.), GNSS receiver 770, and data received using these sensors (such as map data, environmental data, location, route) and / or other vehicle information (such as may be received from other vehicles, devices and servers (such as, in one embodiment, map server 950, route server 945, vehicle information server 955, environmental data server 940, location server 960) and / or from associated devices (such as mobile device 902), which may be present in or near a vehicle (such as vehicle A 980)). For example, in one embodiment, mobile device 902 may provide an additional source of GNSS measurements, may provide an additional source of motion sensor measurements, or may provide network access as a communications portal to a WAN, Wi-Fi, or other network, and as a gateway to various information servers (such as servers 940, 945, 950, 955, 960, 965, and / or 968).

[0154] It should be understood that the vehicle 1000 may include one or more cameras. In one embodiment, the camera may be front-mounted, side-mounted, rear-mounted, or have an adjustable field of view (such as a rotatable camera). Fig.12As shown in , for example, there may be multiple cameras facing the same plane. For example, camera 1206 can be one of two front cameras, one camera focused on lower objects and / or a lower perspective for parking purposes (such as mounted on a bumper), and one camera focused on a higher perspective (such as tracking traffic, other vehicles, pedestrians, and more distant objects). In one embodiment, the various views can be stitched and / or can be associated with other inputs (such as V2X inputs from other vehicles) to optimize tracking of other vehicles and external entities and objects and / or calibrate the sensor systems for each other. LIDAR 1204 can be mounted on the top and rotated or can be focused on a specific perspective (such as forward, backward, sideways). LIDAR 1204 can be solid-state or mechanical. The proximity sensor can be ultrasonic, RADAR-based, light-based (such as infrared ranging-based) and / or capacitive (capacitive detection of surface touch or metal bodies). Other sensors may include various sensing capabilities and technologies such as barometric pressure sensors, devices for detecting weather, pressure changes, vertical directionality, ground position, proximity detection, humidity detectors, rain sensors and / or snow sensors and / or light sensors and / or may utilize other pre-existing sensor systems. The GNSS receiver may be mounted overhead, such as in a fin-type antenna assembly at the rear of the roof, mounted on the hood or dashboard or otherwise placed on the exterior or interior of the vehicle.

[0155] In one embodiment, the vehicle internal sensors 1004 may include wheel sensors 812 (such as tire pressure sensors, brake pad sensors, brake status sensors, speedometers and other speed sensors), heading sensors and / or orientation sensors (such as magnetometers and geomagnetic compasses), distance sensors (such as odometers and wheel tick sensors), inertial sensors (such as accelerometers and gyroscopes) and inertial positioning results using the above-mentioned sensors, as well as yaw, pitch and / or roll sensors that can be determined alone or using other sensor systems (such as accelerometers, gyroscopes and / or tilt sensors).

[0156] Both the vehicle internal sensor 1004 and the vehicle external sensor 1002 may have shared or dedicated processing capabilities. For example, a sensor system or subsystem may have one or more sensor processing cores that determine vehicle state values ​​(such as yaw, pitch, roll, heading, speed, acceleration capability and / or distance, and / or stopping distance) based on measurements and other inputs from accelerometers, gyroscopes, magnetometers, and / or other sensing systems. Different sensing systems can communicate with each other to determine the measurement value or send the value to box 1028 to determine the vehicle position. The vehicle state value derived from the measurements of the internal and external sensors can be further combined with the vehicle state value and / or measurements from other sensor systems using a general or application processor. For example, box 1028 and / or 1024 can be implemented on a dedicated or centralized processor to determine the data element value for V2X message transmission, which can be sent using (all) wireless transceivers 1130 or via other communication transceivers. In one embodiment, the sensors may be segmented into related systems (e.g., LIDAR, radar, motion, wheel systems, etc.) that operate through dedicated core processing of raw results to output vehicle state values ​​from each core that are combined and interpreted to derive combined vehicle state values, including capability data elements and state data elements, that may be used to control or otherwise affect vehicle operation and / or be shared with other vehicles and / or systems as a messaging step via V2X or other messaging capabilities. In one embodiment, these messaging capabilities may be based on various wireless-related, optical-related, or other communication standards, such as those supported by wireless transceiver(s) 1130 and antenna(s) 1132.

[0157] In one embodiment, vehicle capabilities 1006 may include performance estimates for stopping, braking, acceleration, and turning radius, as well as autonomous and / or non-autonomous states and / or capabilities or capabilities. Capability estimates may be based on stored estimates, which, in one embodiment, may be loaded into a memory. These estimates may be based on empirical performance figures, either for a specific vehicle, or for an average across one or more vehicles, and / or one or more models for a given performance metric. In the case where performance estimates for multiple models are averaged or otherwise combined, they may be selected based on similar or common features. For example, vehicles with similar or identical weights and identical or similar transmission systems may share performance estimates for driving performance-related estimates (such as braking / stopping distance, turning radius, and acceleration performance). Vehicle performance estimates may also be obtained from a vehicle data server on the network over a wireless network, for example using (multiple) external V2X inputs 1008. This is particularly helpful in obtaining information for vehicles that do not have wireless capabilities and cannot directly provide vehicle information. In one embodiment, vehicle capabilities 1006 may also be affected by the status of vehicle components, such as tire wear, tire brand and capability, brake pad wear, brake brand and capability, and engine status. In one embodiment, vehicle capability 1006 may also be affected by overall vehicle state (such as speed, heading) and external factors (such as road surface, road conditions (wet, dry, slip / traction), weather (windy, rainy, snowy, black ice, slippery roads, etc.). In many cases, wear or other system degradation, as well as external factors (such as weather, road surface, road conditions, etc.) may be used to reduce, verify, or improve performance estimates. In some embodiments, actual measured vehicle performance (such as measuring vehicle stopping distance and / or acceleration time per distance) may be measured and / or estimated based on actual vehicle driving related performance. In one embodiment, if the measurements are inconsistent, the most recently measured performance may be weighted or given preference over older measurements. Similarly, in one embodiment, measurements taken during similar conditions (such as in the same type of weather or on the same type of road surface as the vehicle is currently detecting (such as via vehicle external sensors 1002 and / or vehicle internal sensors 1004)) may be weighted and / or given preference when determining capability.

[0158] The V2X vehicle sensing, prediction, planning execution 1012 handles the receipt and processing of information from blocks 1002, 1004, 1006, 1008, and 1010 via an external object sensing and classification block 1014, correlating, validating, and / or combining data from input blocks 1002, 1004, 1006, 1008, and 1010 in part using a sensor fusion and object classification block 1016. Block 1014 external object sensing and classification determines the objects present, determines the type of object (car, truck, bicycle, motorcycle, pedestrian, animal, etc.) and / or the state of the object relative to the vehicle (such as movement state, proximity, heading, and / or position relative to the vehicle, size, threat level, and vulnerability priority (e.g., a pedestrian will have a higher vulnerability priority than road debris)). In one embodiment, block 1014 may utilize GNSS measurement messages from other vehicles to determine relative positioning to other vehicles. This output from block 1014 may be provided to a prediction and planning block 1018 which determines detected objects and vehicles and their associated trajectories via block 1020 and determines vehicle maneuvers and path plans in block 1022, the output of which is utilized directly in vehicle maneuver execution at block 1026 or via a V2X inter-vehicle negotiation block 1024 which integrates and takes into account maneuver plans, positions, and states received from other vehicles. V2X inter-vehicle negotiation takes into account the states of neighboring vehicles and enables negotiation and coordination between neighboring or otherwise affected vehicles based on vehicle priority, vehicle capabilities (such as the ability to stop, slow down, or speed up to avoid a collision), and in some embodiments, various conditions (such as weather conditions (rain, fog, snow, wind), road conditions (dry, wet, icy, slippery)). These include, for example, negotiation of the timing and order of passing an intersection between cars approaching the intersection, negotiation of lane changes between adjacent cars, negotiation of parking spaces, negotiation of directional travel on a single lane road or negotiation of passing another vehicle. Inter-vehicle negotiations may also include time-based and / or distance-based factors, such as the time of the appointment, the distance to the destination, and the estimated route time to the destination, as well as, in some embodiments, the type of appointment and the importance of the appointment.

[0159] Fig.11A functional block diagram of a vehicle 1100 according to an embodiment is included. The vehicle 1100 may include, for example, a car, a bus, a truck, a motorcycle, and / or other motorized vehicles that may be driven at least partially autonomously. The vehicle 1100 may be an example of a legacy vehicle and / or a vehicle with V2X capabilities. As a legacy vehicle, the vehicle 1100 may lack the ability to communicate via a V2X network and / or may lack a suitable combination of vehicle sensor(s) 1145, vehicle motion sensor(s) 1140, LIDAR 1150, radar 1153, GNSS receiver 1170, camera(s) 1135, or ADAS capabilities that may be considered the minimum requirements for participating in a V2X network.

[0160] like Fig.11 As shown, the vehicle 1100 may include various software and hardware components connected via a bus 1101. For example, the vehicle 1100 may include one or more processors 1110 and a memory 1160. The memory 1160 may include executable instructions that may be executed by the processor(s) 1110 to perform autonomous driving activities, including but not limited to external object sensing and classification, prediction and planning, maneuver execution, receiving and / or transmitting V2X messages (including some combination of vehicle capabilities and / or occupant metadata in some cases). In some embodiments, the memory 1160 may include a vehicle processing module 1165. The vehicle processing module 1165 may correspond to code that, when executed by the processor(s) 1110, causes the processor(s) 1110 to generate and / or present (e.g., via) data elements received in one or more V2X data messages at least in part. Fig.13 The vehicle processing module 1165 may include code that, when executed by the processor(s) 1110, causes the processor(s) 1110 to perform any suitable operations for obtaining, requesting, storing, receiving, transmitting, comparing, or otherwise interacting with any suitable vehicle capabilities and / or occupant metadata. The vehicle processing module 1165 may provide any suitable graphical and / or audible interface by which any suitable combination of vehicle capabilities and / or occupant metadata may be obtained. In general, any functionality described as being provided by a vehicle having V2X capabilities may be performed by executing code of the vehicle processing module 1165.

[0161] Vehicle 1100 may include one or more wireless transceivers (such as wireless transceiver(s) 1130) for transmitting and receiving data via various means, protocols, and standards (such as via SAE or European Telecommunications Standards Institute (ETSI) CV2X messages and data elements or other wireless and radio protocols). In some embodiments, wireless transceiver(s) 1130 may be configured to communicate via short-range wireless communication protocols (e.g., The wireless communication system 1100 may be used to transmit and receive data messages and elements via a wireless link (e.g., LAN, WAN, etc.) and / or via a local area network and / or a wide area network, and / or via a cellular network, and / or via any suitable wireless network. Of course, it should be understood that these are merely examples of networks that can be utilized by the vehicle 1100 over a wireless link, and the claimed subject matter is not limited in this respect. In one embodiment, the wireless transceiver(s) 1130 may include various combinations of WAN, WLAN, and / or PAN transceivers. In one embodiment, the wireless transceiver(s) 1130 may also include a Bluetooth transceiver, a ZigBee transceiver, or other PAN transceivers.

[0162] In some embodiments, the vehicle 1100 may include a global navigation satellite system (GNSS) receiver 1170. The GNSS receiver 1170 may be configured to receive and digitally process signals from navigation satellites (and / or other vehicles) to provide the receiver's position, velocity, and time. The GNSS receiver 1170 may include hardware and / or software components. In one embodiment, the GNSS signals from GNSS satellites received by the GNSS receiver 1170 are used by the vehicle 1100 for position determination and / or for determination of GNSS signal parameters and demodulated data. In one embodiment, the signals received by the wireless transceiver(s) 1130 are used for position determination alone or in combination with the GNSS signals received by the GNSS receiver 1170.

[0163] Examples of network technologies that may support the wireless transceiver(s) 1130 are GSM, CDMA, WCDMA, LTE, 5G or new radio access technology (NR), HRPD, and V2X vehicle-to-vehicle communications. As mentioned, V2X communication protocols may be defined in various standards such as SAE and ETS-ITS standards. GSM, WCDMA, and LTE are technologies defined by 3GPP. CDMA and HRPD are technologies defined by the Third Generation Partnership Project II (3GPP2). WCDMA is also part of the Universal Mobile Telecommunications System (UMTS) and may be supported by the HNB.

[0164] The wireless transceiver(s) 1130 may communicate with the communication network via WAN wireless base stations, which may include deployment of equipment that provides subscribers with access to a wireless telecommunications network for services (e.g., pursuant to a service contract). Here, a WAN wireless base station may perform the functions of a WAN or cell base station to provide services to subscriber devices within a cell determined at least in part based on the range at which the WAN wireless base station is able to provide access services. Examples of WAN base stations include GSM, WCDMA, LTE, CDMA, HRPD, Wi-Fi, Bluetooth, WiMAX, 5G NR base stations. In an embodiment, further wireless base stations may include WLAN and / or PAN transceivers.

[0165] In one embodiment, the vehicle 1100 may include one or more cameras 1135. In one embodiment, the camera(s) 1135 may include a camera sensor and a mounting assembly. Different mounting assemblies may be used for different cameras on the vehicle 1100. For example, a front camera may be mounted in a front bumper, in a rod of a rearview mirror assembly, or in other front areas of the vehicle 1100. A rear camera may be mounted in a rear bumper / fender, on a rear windshield, in a trunk, or on other rear areas of the vehicle. Side mirrors may be mounted on the sides of the vehicle, such as integrated into a mirror assembly or a door assembly. The camera may provide object detection and distance estimation (especially for objects of known size and / or shape (e.g., both stop signs and license plates have standardized sizes and shapes)), and may also provide information about rotational motion relative to the axis of the vehicle (such as during a turn). When used in conjunction with other sensors, the camera may be calibrated to verify travel distance and angular orientation by using other systems (such as by using LIDAR, wheel ticks / distance sensors, and / or GNSS). Cameras may similarly be used to verify and calibrate other systems to verify that distance measurements are correct (e.g., by calibrating against known distances between known objects (landmarks, roadside markings, road mile markers, etc.) and also to verify that object detection is performed accurately so that objects are mapped accordingly by the LIDAR and other systems to the correct position relative to the car. Similarly, when combined with, for example, an accelerometer, the time to impact with a road hazard obstacle may be estimated (e.g., the time elapsed before hitting a pothole), which may be verified against the actual impact time and / or against a parking model (e.g., compared to an estimated stopping distance if a stop is attempted prior to impacting the object) and / or against a maneuvering model (verifying that the current estimate of the turning radius at the current speed and / or the maneuverability measurement at the current speed is accurate under the current conditions and modified accordingly based on the camera and other sensor measurements to update the estimated parameters).

[0166] In some embodiments, at least some of the camera(s) 1135 may be inward facing. The camera(s) 1135 may be used to capture one or more images from which vehicle data may be derived (e.g., an image of a speedometer from which speed may be derived, an image of a heading indicator from which heading may be derived, etc.). In some embodiments, the camera(s) 1135 may be used to capture one or more images of at least some portion of one or more vehicle occupants.

[0167] The vehicle motion sensor(s) 1140 may include any suitable number of accelerometers, gyroscopes, and / or magnetometers. In some embodiments, the vehicle motion sensor(s) 1140 may be part of an inertial measurement unit of the vehicle 1100. The vehicle motion sensor(s) 1140 may be used to provide and / or verify motion and direction information, monitor wheel and driveline performance, and / or measure oscillation amplitude and frequency of the vehicle 1100 and / or components of the vehicle 1100. As an example, an accelerometer (e.g., a 3-axis accelerometer) may measure vibrations of the vehicle 1100, such as movement or mechanical oscillations of a balanced positioning of components of the vehicle 1100. In an embodiment, the accelerometer may also be used to verify the actual collision time of a road hazard obstacle (such as a pothole) relative to the predicted time based on an existing stop and acceleration model and a steering model. In one embodiment, the gyroscope and magnetometer of the vehicle sensor(s) 1145 may be used to measure the rotational state and orientation relative to magnetic north, respectively, of the vehicle, and to measure and calibrate an estimate and / or model of a turning radius at a current speed and / or a maneuverability measurement at a current speed (particularly when used in conjunction with measurements from other external and internal sensors, such as other sensors such as speed sensors, wheel tick sensors, and / or odometer measurements). In some embodiments, the vehicle sensor(s) 745 may be configured to measure oscillations and / or oscillation frequencies corresponding to motions performed by the vehicle 1100.

[0168] The vehicle 1100 may include a LIDAR 1150. The LIDAR 1150 may use a pulsed laser to measure the range to an object. While the camera(s) 1135 may provide object detection, the LIDAR 1150 may provide a means of more definitively detecting the distance (and orientation) of an object, especially with respect to objects of unknown size and shape. The LIDAR 1150 measurements may also be used to estimate travel speed, vector direction, relative position, and stopping distance by providing accurate distance measurements and incremental distance measurements.

[0169] In one embodiment, the power and drive system and related systems 1175 (generator, battery, transmission, engine) and systems 1155 (brakes, actuators, throttle control, steering and electrical) may be controlled by processor(s) 1110 and / or hardware or software or by an operator of the vehicle or by some combination thereof. Systems 1155 and the power and drive system and related systems 1175 may be used in conjunction with performance parameters and operating parameters to enable safe and accurate driving and operation of the vehicle 1100 autonomously (and manually with respect to alarms and emergency overrides / braking / stopping), such as to merge into traffic, stop, accelerate and otherwise operate the vehicle 1100 safely, effectively and efficiently. In one embodiment, inputs from various sensor systems (such as camera(s) 1135, vehicle motion sensor(s) 1140 (including accelerometers, gyroscopes, pressure gauges, etc.), LIDAR1150, GNSS receiver 1170, radar 1153), inputs from wireless transceiver(s) 1130, messaging and / or measurements, or various combinations thereof may be used by processor(s) 1110 and / or DSP 1120 or other processing systems to control the power and drive systems and related systems 1175 and system 1155.

[0170] The GNSS receiver 1170 may be used to determine a position relative to the ground (absolute position), and when used with other information (such as measurements from other objects and / or map data), may be used to determine a position relative to other objects (such as relative to other vehicles and / or relative to the road surface). To determine a position, the GNSS receiver 1170 may receive RF signals from one or more GNSS satellites using one or more antennas 1172. The GNSS receiver 1170 may support one or more GNSS constellations as well as other satellite-based navigation systems. For example, in one embodiment, the GNSS receiver 1170 may support global navigation satellite systems such as GPS, GLONASS, Galileo, and / or BeiDou, or any combination thereof. In one embodiment, the GNSS receiver 1170 may support a regional navigation satellite system such as NavIC or QZSS or a combination thereof and various augmentation systems such as satellite-based augmentation system (SBAS) or ground-based augmentation system (GBAS), such as Doppler orbit diagrams and radio positioning integrated by satellite (DORIS) or Wide Area Augmentation System (WAAS) or European Geostationary Navigation Overlay Service (EGNOS) or Multifunction Satellite Augmentation System (MSAS) or Local Area Augmentation System (LAAS). In one embodiment, the GNSS receiver 1170 and antenna(s) 1172 may support multiple frequency bands and sub-bands such as GPS L1, L2, and L5 bands, Galileo E1, E5, and E6 bands, Compass (Beidou) B1, B3, and B2 bands, GLONASS G1, G2, and G3 bands, and QZSS L1C, L2C, and L5-Q bands.

[0171] The GNSS receiver 1170 may be used to determine position and relative position that may be used for positioning, navigation, and for calibrating other sensors where appropriate, such as for determining the distance between two points in time under clear sky conditions and using the distance data to calibrate other sensors (such as odometers and / or LIDAR). In one embodiment, GNSS-based relative position based on, for example, Doppler and / or pseudorange measurements shared between vehicles may be used to determine a highly accurate distance between two vehicles, and when combined with vehicle information (such as shape and model information and GNSS antenna position), may be used to calibrate, verify, and / or influence confidence levels associated with information from LIDAR, cameras, radar, sonar, and other distance estimation techniques. GNSS Doppler measurements may also be used to determine the linear and rotational motion of a vehicle or vehicles relative to another vehicle, which may be used in conjunction with gyroscopes and / or magnetometers and other sensor systems to maintain calibration of those systems based on measured position data. Relative GNSS position data may also be combined with a high confidence absolute position from a roadside unit (RSU) to determine a high confidence absolute position of a vehicle. Additionally, during inclement weather that may obscure LIDAR and / or camera-based data sources, relative GNSS position data may be used to avoid other vehicles and remain within lanes or other assigned road areas. For example, using a roadside unit (RSU) equipped with a GNSS receiver and V2X capabilities, a vehicle may be provided with GNSS measurement data that, when provided along with the absolute position of the RSU, may be used to navigate the vehicle relative to a map, thereby keeping the vehicle in a lane and / or road despite lack of visibility.

[0172] Radar 1153 uses the transmitted radio waves reflected from the object. The reflected radio waves are analyzed based on the time required for the reflection to arrive and other signal characteristics of the reflected waves to determine the position of nearby objects. Radar 1153 can be used to detect the position of nearby cars, roadside objects (signs, other vehicles, pedestrians, etc.), and objects can usually be detected even in the presence of blurry weather (such as snow, rain or hail). Therefore, radar 1153 can be used to provide ranging and distance measurements and information when vision-based systems usually fail to provide ranging information to LIDAR 1150 and (all) cameras 1135. In addition, radar 1153 can be used to calibrate and / or sanity check other systems (such as LIDAR1150 and (all) cameras 1135). The ranging measurement from radar 1153 can be used to determine / measure the stopping distance at the current speed, acceleration, maneuverability at the current speed, and / or turning radius at the current speed and / or maneuverability measurement at the current speed. In some systems, ground penetrating radar may also be used to track the road surface via, for example, radar reflecting markings on the road surface or terrain features such as ditches.

[0173] Input / output device(s) 1168 may include any suitable audio device(s) (e.g., one or more speakers) and / or one or more displays (e.g., dashboard display, media display, projection display, etc.). Input / output device(s) 1168 may provide an interface for mobile devices (e.g., Fig. 9 The mobile device 902 of the vehicle 1100 may provide data for presentation at the vehicle 1100 through the interface (eg, in a scenario where the mobile device 902 acts as an agent for the vehicle 1100).

[0174] Fig.12 is an example vehicle 1200 (e.g., Fig.11 Examples of vehicles 1000, Figure 1-4 Here, regarding Fig.12 Some components discussed with earlier embodiments are shown. As illustrated and previously discussed, the vehicle 1200 may have one or more cameras (e.g., each camera is Fig.11 The vehicle 1200 may also have a LIDAR 1204 ( Fig.111150); LIDAR 1204 is typically mounted on the roof, however, if multiple LIDAR units are present, they may be oriented around the front, rear, and sides of the vehicle. Vehicle 1200 may have various other location-related systems, such as receiver 1202 (such as a GNSS wireless receiver (typically located in a shark fin unit at the rear of the roof, as indicated) and / or various wireless transceivers (such as WAN, WLAN, V2X; typically but not necessarily located in the shark fin)), radar 1208 (typically in the front bumper), and sonar 1210 (typically located on both sides of the vehicle, if present). Wheel sensors 1212 ( Fig.11 Examples of vehicle motion sensor(s) may also be present and may include wheel sensors and / or powertrain sensors, such as tire pressure sensors, accelerometers, gyroscopes, and wheel rotation detection and / or counters.

[0175] In one embodiment, distance measurements and relative positions determined via various sensors (such as LIDAR, RADAR, cameras, GNSS, and SONAR) can be combined with car size and shape information and information about sensor locations to determine distances and relative positions between surfaces of different vehicles so that the distance or vector from a sensor to another vehicle or between two different sensors (such as two GNSS receivers) is incrementally increased to account for the positioning of the sensors on each vehicle. Therefore, the accurate GNSS distance and vector between two GNSS receivers will need to be modified based on the relative positions of the various car surfaces to the GNSS receivers. For example, when determining the distance between the front bumper of a rear vehicle and the rear bumper of a front vehicle, the distance will need to be adjusted based on the distance between the GNSS receiver on the rear vehicle and the front bumper and the distance between the GNSS receiver of the front vehicle and the rear bumper of the front vehicle. As an example, the distance between the rear bumper of the front vehicle and the front bumper of the rear vehicle is the relative distance of the two GNSS receivers minus the distance from the GNSS receiver of the rear vehicle to the front bumper, minus the distance from the GNSS receiver of the front vehicle to the rear bumper. Recognizing that this list is not intended to be limiting, and Fig.12 It is intended to provide exemplary locations of various sensors in an embodiment of vehicle 1200 .

[0176] It should be understood that Fig.12 Any suitable sensors and / or any suitable devices / components depicted in the may be installed after the listing. Fig.12 Any sensor / device / component depicted in may be a third-party sensor (e.g. Figure 1 Example of (multiple) third-party sensors 105).

[0177] Fig.13is a block diagram of an embodiment of a proxy device 1300 according to at least one embodiment. According to some embodiments, the proxy device 1300 may include a standalone device mobile device (e.g., a smartphone, laptop, tablet, etc.) that may be communicatively coupled with other components / devices of a vehicle or RSU. It may also be noted that the proxy device 1300 may be utilized in a similar manner by a V2X entity other than a vehicle or RSU. Additionally, embodiments may not necessarily be limited to V2X communications. As such, an alternative embodiment may include a device that is similar to the proxy device 1300 and has the same Fig.13 and is capable of performing the functions of the vehicle and / or RSU described in the previously discussed embodiments, but does not have V2X functionality.

[0178] It should also be noted that Fig.13 It is intended only to provide a generalized description of the various components, any or all of which may be utilized as appropriate. Fig.13 The illustrated components may be localized into a single physical device and / or distributed among various networked devices, for example, which may be located at different physical locations on a vehicle, RSU, or other V2X entity.

[0179] The proxy device 1300 is shown as including hardware elements that may be electrically coupled (or may otherwise be in communication as appropriate) via a bus 1305. The hardware elements may include processor(s) 1310, which may include, but are not limited to, one or more general purpose processors, one or more special purpose processors (such as digital signal processing (DSP) chips (e.g., DSP 1320), graphics acceleration processors, application specific integrated circuits (ASICs), etc.), and / or other processing structures or devices.

[0180] The proxy device 1300 may also include one or more input devices 1370, which may include devices associated with a user interface (e.g., a touch screen, a touch pad, a microphone, key(s), dial(s), switch(s), etc.). Similarly, one or more output devices 1315 may be associated with interacting with a user (e.g., via a display, light emitting diode(s) (LED(s), speaker(s), etc.). For example, one or more output devices 1315 may be used by the proxy device 1300 to present (e.g., display, sound, etc.) Figure 1 Driver assistance information 122.

[0181] The proxy device 1300 may also include a wireless transceiver(s) 1330, which may include but is not limited to a modem, a network card, an infrared communication device, a wireless communication device, and / or a chipset (such as Devices, IEEE802.11 devices, IEEE 802.15.4 devices, WiFi devices, WiMax devices, WAN devices and / or various cellular devices, etc.), etc. The wireless transceiver(s) 1330 may enable the proxy device 1300 to communicate with other V2X devices (e.g., Fig. 9 The wireless transceiver(s) 1330 may be capable of transmitting and / or receiving RF signals from various RF channels / bands. Communication using the wireless transceiver(s) 1330 may be performed via one or more wireless communication antennas 1332 that transmit and / or receive wireless signals 1334.

[0182] The proxy device 1300 may further include sensor(s) 1340. The sensor(s) 1340 may include, but are not limited to, one or more inertial sensors and / or other sensors (e.g., accelerometer(s), gyroscope(s), camera(s), magnetometer(s), altimeter(s), microphone(s), proximity sensor(s), light sensor(s), barometer(s), etc.). The sensor(s) 1340 may be used, for example, to determine certain real-time characteristics of the vehicle, such as position, speed, acceleration, etc. As previously indicated, the sensor(s) 1340 may be used to help the vehicle determine its position.

[0183] Embodiments of the proxy device 1300 may also include a GNSS receiver 1380 that is capable of receiving signals 1384 from one or more GNSS satellites using an antenna 1382 (which in some embodiments may be the same as the wireless communication antenna(s) 1332). Positioning based on GNSS signal measurements may be used to determine the current location of the proxy device 1300, and may further be used as a basis for determining the location of detected objects. The GNSS receiver 1380 may extract the location of the proxy device 1300 from GNSS satellites of a GNSS system, such as a Global Positioning System (GPS) and / or similar satellite system, using conventional techniques.

[0184] The proxy device 1300 may further include and / or be in communication with a memory 1360. The memory 1360 may include, but is not limited to, local and / or network accessible storage, disk drives, drive arrays, optical storage devices, solid-state storage devices (such as random access memory (RAM) and / or read-only memory (ROM)), which may be programmable, flash-updatable, etc. Such storage devices may be configured to implement any appropriate data storage, including, but not limited to, various file systems, database structures, etc.

[0185] The memory 1360 of the proxy device 1300 may also include software elements (some of which Fig.13 1300 (not shown), these software elements include operating systems, device drivers, executable libraries, and / or other code (such as one or more applications), which may include computer programs provided by various embodiments, and / or may be designed to implement methods as described herein, and / or configure systems as described herein. Software applications (e.g., agent processing module 1365) stored in memory 1360 and executed by processor(s) 1310 can be used to implement functionality that provides the functionality of the agent device described herein. In addition, one or more procedures described with respect to the method(s) discussed herein can be implemented as part of the agent processing module 1365 and stored in memory 1360. The code / instructions of the agent processing module 1365 can be executed by the agent device 1300 (and / or the processor(s) 1310 or DSP 1320 within the agent device 1300), and may include the above in combination. Figure 1-8 In one aspect, such codes and / or instructions may be used to configure and / or adapt a general purpose computer (or other device) to perform one or more operations according to the described method.

[0186] The proxy processing module 1365 may include code that, when executed by the processor(s) 1310, causes the processor(s) 1310 to perform any suitable operations for obtaining, requesting, storing, receiving, transmitting, comparing, or otherwise interacting with any suitable vehicle capabilities and / or occupant metadata. The proxy processing module 1365 may provide any suitable graphical and / or audible interface by which any suitable combination of vehicle capabilities and / or occupant metadata may be obtained (e.g., from a user of the proxy device 1300). The proxy processing module 1365 may include one or more application programming interfaces that may be used by one or more user devices associated with one or more occupants of a vehicle to obtain and / or provide occupant metadata.

[0187] The processor(s) 1310 may receive and / or transmit the location of vehicle A 980, vehicle capabilities and / or occupant metadata, status, GNSS and other sensor measurements, one or more trust values ​​corresponding to sensor measurements, capability information (such as GNSS measurements, sensor measurements, speed, heading, location, stopping distance, priority or emergency status) from vehicle A 980 and / or vehicle B 990, and other vehicle related information, etc. In one embodiment, environmental information (such as road surface information / status, weather conditions, and camera information) may be transmitted via point-to-point or broadcast messaging (e.g., from RSU(s) 925, vehicle A 980, vehicle B 990, or vehicle B 990). Fig. 9 The processor(s) 1310 may utilize the received information to coordinate and direct traffic flow and provide environmental, vehicular, safety, and advisory messages to vehicle A 980 that would otherwise not be able to ascertain such information. By utilizing the proxy device 1300, legacy vehicles may participate in the V2X environment so that information provided by other V2X entities may be presented to the driver of the legacy vehicle.

[0188] The processor 925A may be configured to operate a network interface 925B, which in one embodiment may be connected to a network 970 via a backhaul, and which in an embodiment may be used to communicate and coordinate with various centralized servers, such as a centralized traffic control and optimization server 965, which monitors and optimizes traffic flow in an area, such as within a city or urban area or in a region. The network interface 925B may also be used to remotely access the RSU(s) 925 for crowdsourcing vehicle data, maintenance of the RSU(s) 925, and / or coordination with other RSU(s) 925, or other purposes. The RSU(s) 925 may have a processor 925A configured to operate a traffic control unit 925C, which may be configured to process data received from vehicles, such as vehicle A 980 and vehicle B 990, such as location data, stopping distance data, road condition data, identification data, and other information related to the status and location of nearby vehicles and the environment. The RSU(s) 925 may have a processor 925A configured to acquire data from environmental and roadside sensors 925D, which may include temperature, weather, cameras, pressure sensors, road sensors (e.g., for car detection), accident detection, motion detection, speed detection, and other vehicle and environment monitoring sensors.

[0189] It will be apparent to those skilled in the art that substantial modifications may be made depending on specific requirements. For example, customized hardware may also be used, and / or specific elements may be implemented in hardware, software (including portable software, such as applets, etc.), or both. Further, connections to other computing devices (such as network input / output devices) may be employed.

[0190] Referring to the drawings, a memory (e.g., Fig.13 The components of the memory 1360) may include non-transient machine-readable media. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any storage medium that participates in providing data that enables the machine to operate in a specific manner. In the embodiments provided above, various machine-readable media may be involved when providing instructions / codes to the processor and / or (other) devices for execution. Additionally or alternatively, machine-readable media may be used to store and / or carry such instructions / codes. In many implementations, computer-readable media are physical and / or tangible storage media. Such media can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Common forms of computer-readable media include, for example: magnetic and / or optical media, any other physical media with hole patterns, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cassette, carrier waves described below, or any other media from which a computer can read instructions and / or codes.

[0191] The methods, systems and devices discussed herein are examples. Various embodiments may appropriately omit, substitute, or add various procedures or components. For example, features described with reference to certain embodiments may be combined in various other embodiments. Different aspects and elements of the embodiments may be combined in a similar manner. The various components of the accompanying drawings provided herein may be embodied in hardware and / or software. Moreover, technology may evolve, and therefore many elements are examples, which do not limit the scope of the present disclosure to those specific examples.

[0192] It has proven convenient at times, primarily for reasons of common usage, to refer to such signals as bits, information, values, elements, symbols, characters, variables, terms, quantities, numbers, and the like. However, it should be understood that all of these or similar terms are to be associated with the appropriate physical quantities and are merely convenient labels. Unless otherwise specifically stated, as will be apparent from the above discussion, it should be appreciated that throughout this specification, discussions utilizing terms such as "processing," "computing," "calculating," "determining," "ascertaining," "identifying," "correlating," "measuring," "performing," and the like refer to the actions or processes of a specific apparatus, such as a special-purpose computer or similar special-purpose electronic computing device. Thus, in the context of this specification, a special-purpose computer or similar special-purpose electronic computing device is capable of manipulating or transforming signals that are typically represented as physical, electronic, electrical, or magnetic quantities within a memory, register, or other information storage device, transmission device, or display device of the special-purpose computer or similar special-purpose electronic computing device.

[0193] As used herein, the terms "and" and "or" may include various meanings that are also intended to depend at least in part on the context in which such terms are used. Generally, "or", if used in association with a list, such as A, B, or C, is intended to mean A, B, and C (inclusive meanings are used here) as well as A, B, or C (exclusive meanings are used here). In addition, the term "one or more" as used herein may be used to describe any feature, structure, or characteristic in the singular, or may be used to describe a certain combination of features, structures, or characteristics. However, it should be noted that this is merely an illustrative example, and the subject matter claimed is not limited to this example. In addition, the term "at least one of", if used in association with a list, such as A, B, or C, may be interpreted to mean any combination of A, B, and / or C, such as A, AB, AA, AAB, AABBCCC, etc.

[0194] Several embodiments have been described, and various modifications, alternative constructions, and equivalents may be used without departing from the spirit of the present disclosure. For example, the above elements may be components of a larger system, where other rules may take precedence over the application of the various embodiments or otherwise modify the application of the various embodiments. In addition, several steps may be taken before, during, or after considering the above elements. Accordingly, the above description does not limit the scope of the present disclosure.

[0195] In view of this description, various embodiments may include different combinations of features. Various implementation examples are described in the following numbered clauses.

[0196] Clause 1: A method for transmitting data on behalf of a vehicle by a mobile device, comprising: obtaining, by the mobile device, vehicle capabilities associated with the vehicle, the vehicle capabilities indicating one or more sensors of the vehicle; determining, by the mobile device, mobile device capabilities indicating one or more sensors, processing resources, or both of the mobile device; obtaining, by the mobile device at least in part based on the vehicle capabilities and the mobile device capabilities, one or more transmission credentials for vehicle-to-vehicle transmission from a credential authority; and in response to obtaining the one or more transmission credentials for vehicle-to-vehicle transmission, transmitting, by the mobile device, one or more data messages on behalf of the vehicle via one or more transceivers using the one or more transmission credentials.

[0197] Clause 2: A method as in Clause 1, wherein obtaining the one or more transmission credentials comprises: transmitting the vehicle capabilities, the mobile device capabilities, and a public key generated by the mobile device to the credential authority, wherein the transmission credentials comprise the public key generated by the mobile device encrypted with a private key associated with the credential authority.

[0198] Clause 3: A method as in clause 2, wherein transmitting the one or more data messages comprises: obtaining data from a sensor of the mobile device, the vehicle, or at least one of the sensors of the vehicle; encrypting the data to generate encrypted data, wherein the data is encrypted using a private key associated with a public key generated by the mobile device; and generating, by the mobile device, a digital signature for the one or more data messages using the private key associated with the public key generated by the mobile device, wherein the one or more data messages when transmitted include the encrypted data, the digital signature, and the transmission credential.

[0199] Clause 4: The method of any of clauses 1-3, wherein the transmission credential is generated by the credential authority based at least in part on determining that the vehicle capabilities and the mobile device capabilities satisfy a set of transmission threshold requirements.

[0200] Clause 5: The method of any of clauses 1-4, wherein the transmission credential is associated with one or more specific data types for which transmission authorization is granted to the mobile device, and wherein the mobile device is configured to limit the transmitted data to the one or more specific types of data.

[0201] Clause 6: The method of any of clauses 1-5, further comprising: providing at least one transmission credential to a sensor device, wherein providing the at least one transmission credential to the sensor device configures the sensor device to transmit data via the network.

[0202] Clause 7: The method of any of clauses 1-6, wherein the one or more data messages are formatted according to a telematics communication protocol.

[0203] Clause 8: A method as described in any of clauses 1-7, further comprising: obtaining, by the mobile device, a receiving credential from the credential authority; receiving, by the mobile device, a data message based at least in part on obtaining the receiving credential; and performing, by the mobile device, one or more operations based at least in part on the received data message.

[0204] Clause 9: A method as in clause 8, wherein performing the one or more operations includes: generating driving assistance information based at least in part on a received data message; providing the driving assistance information to an output device associated with the mobile device or the vehicle; determining that a data element of the data message includes additional vehicle capabilities corresponding to the vehicle; storing the additional vehicle capabilities received from the data message at the mobile device; transmitting at least a portion of the additional vehicle capabilities in one or more data messages; determining whether to adjust a trust value associated with a sensor based at least in part on the received data message; or any combination thereof.

[0205] Item 10: A mobile device comprising: a memory; and one or more processors, the one or more processors being communicatively coupled to the memory, the one or more processors being configured to: obtain vehicle capabilities associated with the vehicle, the vehicle capabilities indicating one or more sensors of the vehicle; determine mobile device capabilities indicating one or more sensors, processing resources, or both of the mobile device; obtain one or more transmission credentials for vehicle network transmission from a credential authority based at least in part on the vehicle capabilities and the mobile device capabilities; and in response to obtaining the one or more transmission credentials for vehicle network transmission, utilize the one or more transmission credentials to transmit one or more data messages on behalf of the vehicle via one or more transceivers.

[0206] Clause 11: A mobile device as in Clause 10, wherein obtaining the one or more transmission credentials comprises: transmitting the vehicle capabilities, the mobile device capabilities and a public key generated by the mobile device to the credential authority, wherein the transmission credentials comprise the public key generated by the mobile device encrypted with a private key associated with the credential authority.

[0207] Clause 12: A mobile device as in clause 11, wherein transmitting the one or more data messages causes the one or more processors to: obtain data from a sensor of the mobile device, the vehicle, or at least one of the sensors of the vehicle; encrypt the data to generate encrypted data, wherein the data is encrypted using a private key associated with a public key generated by the mobile device; and generate a digital signature for the one or more data messages using the private key associated with the public key generated by the mobile device, wherein the one or more data messages when transmitted include the encrypted data, the digital signature, and the transmission credential.

[0208] Clause 13: The mobile device of any of clauses 10-12, wherein the transmission credential is generated by the credential authority based at least in part on determining that the vehicle capabilities and the mobile device capabilities satisfy a set of transmission threshold requirements.

[0209] Clause 14: A mobile device as in any of clauses 10-13, wherein the transmission credentials are associated with one or more specific data types for which transmission authorization is granted to the mobile device, and wherein the mobile device is configured to limit the transmitted data to the one or more specific types of data.

[0210] Clause 15: The mobile device of any of clauses 10-14, wherein the one or more processors are further configured to: provide at least one transmission credential to a sensor device, wherein providing the at least one transmission credential to the sensor device configures the sensor device to transmit data via the network.

[0211] Clause 16: The mobile device of any of clauses 10-15, wherein the one or more data messages are formatted according to a vehicle networking communication protocol.

[0212] Clause 17: A mobile device as in any of clauses 10-16, wherein the one or more processors are further configured to: obtain a receipt credential from the credential authority; receive a data message based at least in part on obtaining the receipt credential; and perform one or more operations based at least in part on the received data message.

[0213] Clause 18: A mobile device as in clause 17, wherein performing the one or more operations further causes the one or more processors to: generate driving assistance information based at least in part on the received data message; provide the driving assistance information to an output device associated with the mobile device or the vehicle; determine that a data element of the data message includes additional vehicle capabilities corresponding to the vehicle; store the additional vehicle capabilities received from the data message at the mobile device; transmit at least a portion of the additional vehicle capabilities in one or more data messages; determine whether to adjust a trust value associated with a sensor based at least in part on the received data message; or any combination thereof.

[0214] Item 19: A non-transitory computer-readable medium having stored thereon instructions for transmitting data on behalf of a vehicle by a mobile device, wherein the instructions, when executed by one or more processors of the mobile device, cause the one or more processors to: obtain vehicle capabilities associated with the vehicle, the vehicle capabilities indicating one or more sensors of the vehicle; determine mobile device capabilities indicating one or more sensors, processing resources, or both of the mobile device; obtain one or more transmission credentials for vehicle-to-vehicle transmissions from a credential authority based at least in part on the vehicle capabilities and the mobile device capabilities; and in response to obtaining the one or more transmission credentials for vehicle-to-vehicle transmissions, utilize the one or more transmission credentials to transmit one or more data messages on behalf of the vehicle via one or more transceivers of the mobile device.

[0215] Clause 20: A non-transitory computer-readable medium as in clause 19, wherein transmitting the one or more data messages causes the one or more processors to: obtain data from a sensor of the mobile device, the vehicle, or at least one of the sensors of the vehicle; encrypt the data to generate encrypted data, wherein the data is encrypted using a private key associated with a public key generated by the mobile device; and generate a digital signature for the one or more data messages using the private key associated with the public key generated by the mobile device, wherein the one or more data messages when transmitted include the encrypted data, the digital signature, and the transmission credential.

[0216] Clause 21: A non-transitory computer-readable medium as in any of clauses 19-20, wherein the transfer credential is associated with one or more specific data types for which transfer authorization is granted to the mobile device, and wherein the mobile device is configured to limit the transmitted data to the one or more specific types of data.

[0217] Clause 22: The non-transitory computer-readable medium of any of clauses 19-21, wherein the one or more processors are further configured to: provide at least one transmission credential to a sensor device, wherein providing the at least one transmission credential to the sensor device configures the sensor device to transmit data via the network.

[0218] Clause 23: A non-transitory computer-readable medium as in any of clauses 19-22, wherein the one or more processors are further configured to: obtain a receiving credential from the credential authority; receive a data message based at least in part on obtaining the receiving credential; and perform one or more operations based at least in part on the received data message.

[0219] Clause 24: A non-transitory computer-readable medium as in any of clauses 19-23, wherein performing the one or more operations further causes the one or more processors to: generate driving assistance information based at least in part on the received data message; provide the driving assistance information to an output device associated with the mobile device or the vehicle; determine that a data element of the data message includes additional vehicle capabilities corresponding to the vehicle; store the additional vehicle capabilities received from the data message at the mobile device; transmit at least a portion of the additional vehicle capabilities in one or more data messages; determine whether to adjust a trust value associated with a sensor based at least in part on the received data message; or any combination thereof.

[0220] Clause 25: A mobile device comprising: a device for obtaining vehicle capabilities associated with the vehicle, the vehicle capabilities indicating one or more sensors of the vehicle; a device for determining mobile device capabilities indicating one or more sensors, processing resources, or both of the mobile device; a device for obtaining one or more transmission credentials for vehicle-to-vehicle transmission from a credential authority based at least in part on the vehicle capabilities and the mobile device capabilities; and a device for transmitting one or more data messages on behalf of the vehicle to at least one other vehicle using the one or more transmission credentials in response to obtaining the one or more transmission credentials for vehicle-to-vehicle transmission.

[0221] Clause 26: A mobile device as in Clause 25, wherein the means for transmitting the one or more data messages further comprises: a means for obtaining data from a sensor of the mobile device, the vehicle, or at least one of the sensors of the vehicle; a means for encrypting the data to generate encrypted data, wherein the data is encrypted using a private key associated with a public key generated by the mobile device; and a means for generating a digital signature for the one or more data messages using the private key associated with the public key generated by the mobile device, wherein the one or more data messages when transmitted include the encrypted data, the digital signature, and the transmission credential.

[0222] Clause 27: A mobile device as in any of clauses 25-26, wherein the transmission credentials are associated with one or more specific data types for which transmission authorization is granted to the mobile device, and wherein the mobile device is configured to limit the transmitted data to the one or more specific types of data.

[0223] Clause 28: The mobile device of any of clauses 25-27, further comprising: means for providing at least one transmission credential to a sensor device, wherein providing the at least one transmission credential to the sensor device configures the sensor device to transmit data via the network.

[0224] Clause 29: A mobile device as in any of clauses 25-28, further comprising: a device for obtaining a receiving credential from the credential authority; a device for receiving a data message based at least in part on obtaining the receiving credential; and a device for performing one or more operations based at least in part on the received data message.

[0225] Clause 30: A mobile device as described in any of clauses 25-29, wherein the device for performing one or more operations also includes: a device for generating driving assistance information based at least in part on a received data message; a device for providing the driving assistance information to an output device associated with the mobile device or the vehicle; a device for determining that a data element of the data message includes additional vehicle capabilities corresponding to the vehicle; a device for storing the additional vehicle capabilities received from the data message at the mobile device; a device for transmitting at least a portion of the additional vehicle capabilities in one or more data messages; a device for determining whether to adjust a trust value associated with a sensor based at least in part on the received data message; or any combination thereof.

Claims

1. A method for transmitting data on behalf of a vehicle by a mobile device, comprising: obtaining, by the mobile device, vehicle capabilities associated with the vehicle, the vehicle capabilities indicating one or more sensors of the vehicle; determining, by the mobile device, mobile device capabilities indicative of processing resources and / or one or more sensors of the mobile device; The mobile device obtains one or more transmission credentials for vehicle-to-vehicle network transmission from a credential authority at least partially based on the one or more sensors of the vehicle and at least partially based on the processing resources of the mobile device and / or the one or more sensors, wherein obtaining the one or more transmission credentials comprises transmitting to the credential authority the vehicle capability indicating the one or more sensors of the vehicle, the mobile device capability indicating the processing resources of the mobile device and / or the one or more sensors, and a public key generated by the mobile device, wherein the transmission credentials are obtained on the condition that the one or more sensors of the vehicle and the processing resources of the mobile device and / or the one or more sensors meet a transmission threshold requirement, wherein the transmission credentials comprise the public key generated by the mobile device encrypted with a private key associated with the credential authority; as well as In response to obtaining the one or more transmission credentials for vehicle-to-vehicle network transmission, one or more data messages are transmitted by the mobile device via one or more transceivers on behalf of the vehicle using the one or more transmission credentials.

2. The method of claim 1, wherein: Transmitting the one or more data messages comprises: obtaining data from at least one of a sensor of the mobile device, the vehicle, or a sensor of the vehicle; encrypting the data to generate encrypted data, wherein encrypting the data utilizes a private key associated with a public key generated by the mobile device; and A digital signature is generated by the mobile device for the one or more data messages using a private key associated with a public key generated by the mobile device, wherein the one or more data messages, when transmitted, include the encrypted data, the digital signature, and the transmission credential.

3. The method of claim 1, wherein: The transmission credentials are associated with one or more specific data types for which transmission authorization is granted to the mobile device, and wherein the mobile device is configured to limit transmitted data to the one or more specific types of data.

4. The method of claim 1, further comprising: At least one transmission credential is provided to a sensor device, wherein providing the at least one transmission credential to the sensor device configures the sensor device to transmit data via a network.

5. The method of claim 1, wherein: The one or more data messages are formatted according to a vehicle networking communication protocol.

6. The method of claim 1, further comprising: obtaining, by the mobile device, a receipt credential from the credential authority; receiving, by the mobile device, a data message based at least in part on obtaining the receipt credential; as well as One or more operations are performed by the mobile device based at least in part on the received data message.

7. The method of claim 6, wherein: Performing the one or more operations includes: generating driver assistance information based at least in part on the received data message, providing the driving assistance information to an output device associated with the mobile device or the vehicle, determining that a data element of the data message includes additional vehicle capabilities corresponding to the vehicle, storing at the mobile device the additional vehicle capabilities received from the data message, transmitting at least a portion of the additional vehicle capabilities in one or more data messages, determining whether to adjust a trust value associated with the sensor based at least in part on the received data message; or any combination thereof.

8. A mobile device, comprising: Memory; as well as one or more processors communicatively coupled to the memory, the one or more processors configured to: obtaining vehicle capabilities associated with a vehicle, the vehicle capabilities indicating one or more sensors of the vehicle; determining a mobile device capability indicative of a processing resource and / or one or more sensors of the mobile device; Obtaining one or more transmission credentials for vehicle-to-vehicle network transmission from a credential authority based at least in part on the one or more sensors of the vehicle and at least in part on the processing resources and / or the one or more sensors of the mobile device, wherein obtaining the one or more transmission credentials comprises transmitting to the credential authority information indicating the vehicle capability of the one or more sensors of the vehicle, indicating the processing resources of the mobile device and / or the mobile device capability of the one or more sensors, and a public key generated by the mobile device, wherein the transmission credentials are obtained on the condition that the one or more sensors of the vehicle and the processing resources and / or the one or more sensors of the mobile device meet transmission threshold requirements, wherein the transmission credentials comprise the public key generated by the mobile device encrypted with a private key associated with the credential authority; as well as In response to obtaining the one or more transmission credentials for vehicle-to-vehicle network transmission, one or more data messages are transmitted on behalf of the vehicle via one or more transceivers using the one or more transmission credentials.

9. The mobile device according to claim 8, wherein: Transmitting the one or more data messages causes the one or more processors to: obtaining data from at least one of a sensor of the mobile device, the vehicle, or a sensor of the vehicle; encrypting the data to generate encrypted data, wherein encrypting the data utilizes a private key associated with a public key generated by the mobile device; as well as A digital signature is generated for the one or more data messages using a private key associated with a public key generated by the mobile device, wherein the one or more data messages, when transmitted, include the encrypted data, the digital signature, and the transmission credential.

10. The mobile device according to claim 8, wherein: The transmission credentials are associated with one or more specific data types for which transmission authorization is granted to the mobile device, and wherein the mobile device is configured to limit transmitted data to the one or more specific types of data.

11. The mobile device according to claim 8, wherein: The one or more processors are further configured to provide at least one transmission credential to a sensor device, wherein providing the at least one transmission credential to the sensor device configures the sensor device to transmit data via a network.

12. The mobile device of claim 8, wherein: The one or more data messages are formatted according to a vehicle networking communication protocol.

13. The mobile device of claim 8, wherein: The one or more processors are further configured to: Obtaining a receipt certificate from the certificate authority; receiving a data message based at least in part on obtaining the receipt credential; and One or more operations are performed based at least in part on the received data message.

14. The mobile device of claim 13, wherein: Executing the one or more operations further causes the one or more processors to: generating driver assistance information based at least in part on the received data message, providing the driving assistance information to an output device associated with the mobile device or the vehicle, determining that a data element of the data message includes additional vehicle capabilities corresponding to the vehicle, storing at the mobile device the additional vehicle capabilities received from the data message, transmitting at least a portion of the additional vehicle capabilities in one or more data messages, determining whether to adjust a trust value associated with the sensor based at least in part on the received data message; or any combination thereof.

15. A non-transitory computer readable medium having stored thereon instructions for transmitting data on behalf of a vehicle by a mobile device, wherein the instructions, when executed by one or more processors of the mobile device, cause the one or more processors to: obtaining vehicle capabilities associated with the vehicle, the vehicle capabilities indicating one or more sensors of the vehicle; determining a mobile device capability indicative of a processing resource and / or one or more sensors of the mobile device; Obtaining one or more transmission credentials for vehicle-to-vehicle network transmission from a credential authority based at least in part on the one or more sensors of the vehicle and at least in part on the processing resources and / or the one or more sensors of the mobile device, wherein obtaining the one or more transmission credentials comprises transmitting to the credential authority information indicating the vehicle capability of the one or more sensors of the vehicle, indicating the processing resources of the mobile device and / or the mobile device capability of the one or more sensors, and a public key generated by the mobile device, wherein the transmission credentials are obtained on the condition that the one or more sensors of the vehicle and the processing resources and / or the one or more sensors of the mobile device meet transmission threshold requirements, wherein the transmission credentials comprise the public key generated by the mobile device encrypted with a private key associated with the credential authority; as well as In response to obtaining the one or more transmission credentials for vehicle-to-vehicle transmission, one or more data messages are transmitted on behalf of the vehicle via one or more transceivers of the mobile device using the one or more transmission credentials.

16. The non-transitory computer readable medium of claim 15, wherein: Transmitting the one or more data messages causes the one or more processors to: obtaining data from at least one of a sensor of the mobile device, the vehicle, or a sensor of the vehicle; encrypting the data to generate encrypted data, wherein encrypting the data utilizes a private key associated with a public key generated by the mobile device; as well as A digital signature is generated for the one or more data messages using a private key associated with a public key generated by the mobile device, wherein the one or more data messages, when transmitted, include the encrypted data, the digital signature, and the transmission credential.

17. The non-transitory computer readable medium of claim 15, wherein: The transmission credentials are associated with one or more specific data types for which transmission authorization is granted to the mobile device, and wherein the mobile device is configured to limit transmitted data to the one or more specific types of data.

18. The non-transitory computer readable medium of claim 15, wherein: The one or more processors are further configured to provide at least one transmission credential to a sensor device, wherein providing the at least one transmission credential to the sensor device configures the sensor device to transmit data via a network.

19. The non-transitory computer readable medium of claim 15, wherein the one or more processors are further configured to: Obtaining a receipt certificate from the certificate authority; receiving a data message based at least in part on obtaining the receipt credential; and One or more operations are performed based at least in part on the received data message.

20. The non-transitory computer readable medium of claim 19, wherein: Executing the one or more operations further causes the one or more processors to: generating driver assistance information based at least in part on the received data message, providing the driving assistance information to an output device associated with the mobile device or the vehicle, determining that a data element of the data message includes additional vehicle capabilities corresponding to the vehicle, storing at the mobile device the additional vehicle capabilities received from the data message, transmitting at least a portion of the additional vehicle capabilities in one or more data messages, determining whether to adjust a trust value associated with the sensor based at least in part on the received data message; or any combination thereof.

21. A mobile device, comprising: means for obtaining vehicle capabilities associated with a vehicle, the vehicle capabilities being indicative of one or more sensors of the vehicle; means for determining processing resources and / or one or more sensors of a mobile device indicative of processing resources and / or one or more sensors of the mobile device; A device for obtaining one or more transmission credentials for vehicle-to-vehicle network transmission from a credential authority based at least in part on the one or more sensors of the vehicle and at least in part on the capabilities of the mobile device, wherein obtaining the one or more transmission credentials comprises transmitting to the credential authority an indication of the vehicle capabilities of the one or more sensors of the vehicle, an indication of the processing resources of the mobile device and / or the mobile device capabilities of the one or more sensors, and a public key generated by the mobile device, wherein the transmission credentials are obtained on the condition that the one or more sensors of the vehicle and the processing resources and / or the one or more sensors of the mobile device meet transmission threshold requirements, wherein the transmission credentials comprise the public key generated by the mobile device encrypted with a private key associated with the credential authority; as well as Means for transmitting one or more data messages on behalf of the vehicle to at least one other vehicle utilizing the one or more transmission credentials in response to obtaining the one or more transmission credentials.

22. The mobile device of claim 21, wherein: The means for transmitting the one or more data messages further comprises: means for obtaining data from at least one of a sensor of the mobile device, the vehicle, or a sensor of the vehicle; means for encrypting the data to generate encrypted data, wherein encrypting the data utilizes a private key associated with a public key generated by the mobile device; and Means for generating a digital signature for the one or more data messages using a private key associated with a public key generated by the mobile device, wherein the one or more data messages when transmitted include the encrypted data, the digital signature, and the transmission credential.

23. The mobile device of claim 21, wherein: The transmission credentials are associated with one or more specific data types for which transmission authorization is granted to the mobile device, and wherein the mobile device is configured to limit transmitted data to the one or more specific types of data.

24. The mobile device of claim 21, further comprising: Means for providing at least one transmission credential to a sensor device, wherein providing the at least one transmission credential to the sensor device configures the sensor device to transmit data via a network.

25. The mobile device of claim 21, further comprising: means for obtaining a receipt certificate from said certificate authority; means for receiving a data message based at least in part on obtaining the receipt credential; as well as Means for performing one or more operations based at least in part on the received data message.

26. The mobile device of claim 21, wherein: The means for performing one or more operations further comprises: means for generating driver assistance information based at least in part on the received data message, means for providing the driving assistance information to an output device associated with the mobile device or the vehicle, means for determining that the data elements of the data message include additional vehicle capabilities corresponding to the vehicle, means for storing at said mobile device said additional vehicle capabilities received from said data message, means for transmitting at least a portion of said additional vehicle capabilities in one or more data messages, means for determining whether to adjust a trust value associated with a sensor based at least in part on the received data message; or any combination thereof.

Images