Vehicle-to-Vehicle and Vehicle-to-Network Communications

Abstract

Providing reliable and timely vehicle-to-everything communication between communication stations is challenging but will improve the performance of intelligent transportation systems. To address one or more challenges, aspects described herein relate to various methods, systems, and devices that can be used to determine and disseminate vehicle-to-everything quality-of-service measurements. Additional aspects can relate to enabling or disabling vehicle-to-network message forwarding between two communication stations.

Description

Background Art

[0001] Vehicle-to-everything (V2X) communication can include a vehicle transmitting data to another communication station, such as another vehicle, such that the vehicle and all communication stations can be informed of each other's location, dynamics, and attributes. In addition to other vehicles, communication stations can include any entity configured with communication station equipment capable of communicating with a vehicle. Examples of entities that can be configured with communication station equipment include bicycles, pedestrians, and other roadside units (e.g., road signs, traffic lights, obstacles, and gates). Among other use cases, improvements in road safety can be achieved in particular based on the perception of the location, dynamics, and attributes of communication stations with respect to each other. For example, based on the location, dynamics, and attributes of other communication stations, a vehicle (or one of the other communication stations) can issue a safety warning or alert. Examples of warnings or alerts include emergency vehicle warnings, slow vehicle warnings, wrong-way driving warnings, lane change warnings, and the like. Some additional examples of warnings or alerts can be found in European Telecommunications Standards Institute (ETSI) TR 102 638, which describes the characteristics of intelligent transport systems including vehicle communication. V2X technology continues to evolve and improve. Summary of the Invention

[0002] This summary is provided to introduce some concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the various embodiments, nor is it intended to be used to limit the scope of the claims.

[0003] Providing reliable and timely V2X communication between communication stations is challenging but will improve the performance of intelligent transport systems. To address one or more challenges, the aspects described herein relate to various methods, systems, and devices that can be used to determine and disseminate V2X quality-of-service measurements. For example, one or more V2X quality-of-service measurements can be determined based on vehicle-to-network communication or vehicle-to-vehicle communication of V2X messages. Dissemination of the V2X quality-of-service measurements can include sending various versions of the V2X messages such that communication stations and servers are informed of the measurement.

[0004] For example, a server may receive vehicle-to-everything messages from a first communication station. The server may determine one or more vehicle-to-everything server quality measurements based on the vehicle-to-everything messages. The server may determine a second communication station to forward the vehicle-to-everything messages. The server may generate a forwarded version of the vehicle-to-everything messages. The server may send the forwarded version of the vehicle-to-everything messages to the second communication station. The forwarded version of the vehicle-to-everything messages may provide information about at least one vehicle-to-everything quality of service measurement to the second communication station. The server may generate a returned version of the vehicle-to-everything messages. Additionally, the server may send the returned version of the vehicle-to-everything messages to the first communication station. The returned version of the vehicle-to-everything messages may provide information about at least one vehicle-to-everything quality of service measurement to the first communication station.

[0005] Additional aspects may relate to enabling or disabling vehicle-to-network message forwarding between two communication stations. For example, based on a determination of meeting QoS objectives, the server may store an indication to enable vehicle-to-network message forwarding between the first communication station and the second communication station. Based on enabling vehicle-to-network message forwarding, V2X messages may be sent between the first communication station and the second communication station based on vehicle-to-network communication. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Some example embodiments are illustrated by way of example and are not limited to the drawings, in which like reference numerals indicate like elements and in which:

[0007] Figure 1 An example block diagram of a system for vehicle-to-everything communication is shown.

[0008] Figure 2 An example block diagram showing an example of an unreliable or slow vehicle-to-vehicle communication link and an example of vehicle-to-everything message forwarding using vehicle-to-network communication is shown.

[0009] Figures 3A-3C An example process for determining and propagating vehicle-to-everything quality of service measurements based on vehicle-to-network communication is shown.

[0010] Figure 4 An example method for a server to process vehicle-to-everything messages based on vehicle-to-network communication is shown.

[0011] Figure 5A An example method for a communication station to send one or more vehicle-to-everything messages, the vehicle-to-everything messages including vehicle-to-everything quality of service measurements determined based on vehicle-to-vehicle communication, is shown.

[0012] Figure 5BIllustrates an example method for a communication station to receive and process vehicle - to - everything messages, where the vehicle - to - everything messages include vehicle - to - everything quality - of - service measurements determined based on vehicle - to - vehicle communication.

[0013] Figure 6 Illustrates an example method for a server to receive and process vehicle - to - everything messages, where the vehicle - to - everything messages include vehicle - to - everything quality - of - service measurements determined based on vehicle - to - vehicle communication.

[0014] Figure 7 Illustrates example devices that can be used in the environments described herein or for implementing one or more aspects described herein. Detailed Description

[0015] In the following description of various illustrative embodiments, reference is made to the accompanying drawings, which form a part of the description and in which are shown, by way of illustration, various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the invention.

[0016] Vehicle - to - everything (V2X) technology continues to evolve and improve. For example, ETSI has published documents that define intelligent transport systems for vehicle - to - everything communication. Examples of the documents include TS 102 637 - 1, which includes examples of functional requirements; EN 302 637 - 2, which includes features related to the cooperative awareness basic service; and EN 302 637 - 3, which includes features related to the decentralized environmental notification basic service. The cooperative awareness basic service enables communication stations (e.g., vehicles, bicycles, pedestrians, and roadside infrastructure equipment) to exchange status information with each other in real - time. A communication station can encode its status information (e.g., position, speed, direction) into V2X messages, such as, for example, cooperative awareness messages (CAM) or distributed environmental notification messages (DENM). Standardized CAMs and other V2X message types can be found in ETSI TS 102 894 - 2.

[0017] Due to the nature of moving vehicles and road travel, status information can be situational, dynamic, and unstable. If the status information is transmitted slowly or unreliably, the communication station may operate under expired information, which can have a negative impact on the performance of the intelligent transportation system. For example, two vehicles may be traveling along a road one behind the other. The first leading vehicle may apply brakes in an emergency situation, which causes the first vehicle to decelerate rapidly. Due to a failed communication from the first vehicle, the second trailing vehicle may be operating under the expired status information of the first vehicle. The first vehicle may not be aware that its status information has not been received by the second vehicle. Due to the braking of the first vehicle, the two vehicles may be at an unsafe distance from each other and a warning should be triggered. However, due to the expired status information, the second vehicle may incorrectly determine that the first vehicle is maintaining a safe distance.

[0018] Providing reliable and timely communication of status information or other information included in V2X messages between communication stations is challenging but will improve the performance of the intelligent transportation system (ITS). For example, some ITSs have established communication objectives for status information (e.g., 100 millisecond end-to-end delay for CAM; 20 millisecond end-to-end delay for DENM; 99.95% reliability; 10 -5 packet loss rate), but the ITS may lack the ability to determine whether those objectives are being met. In other words, the ITS may not be able to determine the quality of the V2X communication link and may lack the ability to make the communication stations that process V2X messages aware of the determined quality. The quality of the V2X communication link can be indicated by measurements of latency, packet loss, one-way delay, round-trip time (RTT), and other measurements of timeliness and reliability. Additionally, determining the quality of the V2X communication link can be challenging because no single device may be able to determine the quality across all V2X links (e.g., the first vehicle may not be able to determine the quality of the V2X communication link between the second and third vehicles; without the help of another device, a central server may not be able to monitor the reliability or speed messages sent to vehicles). Also, determining the quality of the V2X communication link can be challenging because each V2X message may have multiple hops and determining the end-to-end delay may be beneficial.

[0019] To address some of the challenges of providing reliable and timely V2X message communication, devices of an ITS can be configured to perform a process of determining V2X quality of service (QoS) information. Examples discussed throughout this disclosure will include examples where V2X QoS information is determined based on vehicle-to-vehicle (V2V) communication and vehicle-to-network (V2N) communication. V2V communication can include the communication of V2X messages (such as CAMs) between two communication stations (such as two vehicles). V2N communication can include transmitting V2X messages to and / or from one or more communication stations via a network node. For example, the network node can include a server communicating with a cellular network. The cellular network can communicate with one or more communication stations. Although V2N and V2V communication are discussed throughout the specification, the examples are not limited to vehicles. A vehicle is a type of communication station, and V2V communication refers to communication between communication stations. V2N communication refers to communication between a communication station and a network device (such as a server). V2V communication can be interchangeably referred to as station-to-station communication. V2N communication can be interchangeably referred to as station-to-network communication. Similarly, V2X messages can be interchangeably referred to as station-to-everything messages.

[0020] Figure 1 An example block diagram of a system for V2X communication is shown. Figure 1 Four example communication stations 110a - 110d are depicted. The example communication stations 110a - 110d include three vehicles (e.g., 110a - 110c) and a roadside unit (e.g., 110d). The roadside unit (RSU) can be a traffic light, a road sign, or some other infrastructure element capable of performing V2X communication. The example communication stations 110a - 110d provide only one example of the type and number of communication stations. Other vehicles, roadside infrastructure equipment, and communication stations (e.g., pedestrians, bicycles, etc.) may be involved in V2X communication. The communication stations 110a - 110d can be interchangeably referred to by their specific type of communication station (e.g., vehicles 110a - 110c are equivalent labels for communication stations 110a - 110c; and RSU 110d is an equivalent label for communication station 110d).

[0021] Vehicles 110a - 110c may travel along road 120, and RSU 110d may be located at a position along road 120. Based on V2V communication links 125a - 125d, vehicles 110a - 110c and RSU 110d may be able to send V2X messages, such as CAM or DENM, to attempt to communicate with each other and / or with roadside infrastructure equipment 110d. V2V communication links 125a - 125d may be proximity - based (e.g., via short - range broadcast), such that vehicles 110a - 110c and RSU 110d can receive V2X messages via V2V communication links 125a - 125d only when they are within a certain distance from the source of the V2X message (e.g., based on the distance between roadside infrastructure equipment 110d and vehicle 110a, roadside infrastructure equipment 110d may not be able to receive V2X messages from vehicle 110a). V2V communication links 125a - 125d may be based on ITS standards (including, for example, the ITS - G5 / 802.11p standard). V2V communication links 125a - 125d may be based on 3GPP Long - Term Evolution (LTE) sidelink or New Radio (NR) sidelink standards. V2V communication links 125a - 125d provide an example of a V2X link.

[0022] Based on V2N communication links 120a - 120d, vehicles 110a - 110c and RSU 110d may be able to send V2X messages to attempt to communicate with each other. In this way, V2X messages can be sent from a vehicle (e.g., any one of vehicles 110a - 110c) or other communication stations (e.g., RSU 110d) to radio access network (RAN) equipment 130. RAN equipment 130 may be configured to operate as a base transceiver station (BTS) or an access point of the RAN network. RAN equipment 130 may be configured to wirelessly communicate with nearby devices, which include, for example, one or more communication stations (e.g., 110a - 110d) and user equipment (e.g., Figure 1 mobile phones and cellular phones not shown in the figure). The wireless communication with RAN equipment 130 may be carried out according to wireless standards (e.g., third - generation (3G), fourth - generation (4G), or fifth - generation (5G) mobile telecommunication technologies). For simplicity, the examples described throughout this disclosure will be discussed in accordance with 5G mobile telecommunication technology. V2N communication links 120a - 120d provide an example of a V2X link.

[0023] Once received by RAN equipment 130, the V2X message can be sent via network 135 to a network node. As Figure 1As depicted, the network node can be server 140. Network 135 can include one or more networks, including, for example, a RAN network, a core network operated by the provider of the RAN network, the Internet, or some other wide area network. Upon receiving a V2X message, in addition to other processes to be discussed below, server 140 can, in particular, determine which communication station is to receive the V2X message (e.g., based on information stored in database 150, which will be discussed in more detail below), and can forward the V2X message along an appropriate communication path. For example, as part of forwarding along an appropriate communication path, the V2X message can be sent from server 140, routed via network 135, received by RAN equipment 130 (or some other RAN equipment), and sent from RAN equipment 130 to the appropriate communication station via wireless communication (e.g., via links 125a - 125d).

[0024] To permit the transport of V2X messages over V2N communication links 120a - 120d and V2V communication links 125a - 125d, each communication station 110a - 110d can include communication station equipment 111. Computing resources 112 can include physical computing resources such as one or more computer processors and other hardware components. The following discussion Figure 7 provides examples of some components that can form part of computing resources 112. Computing resources 112 can communicate with one or more network interfaces 113, database 114, one or more display and adaptation resources 115, and one or more sensors 117. Computing resources 112 can be configured to, among other operations, in particular, transfer data to / from other components of communication station equipment 111 (e.g., receive data from one or more sensors 117 or database 114; send one or more commands to display and adaptation resources 115; cause data to be stored in database 14); process any data received from other components (e.g., process sensor data received from one or more sensors 117); generate V2X messages (e.g., generate a CAM); generate status information of the communication station (e.g., location, speed, direction); and the like. Based on the discussion of other components of communication station 111 and the examples related to communication stations discussed throughout this disclosure, the configured functions of computing resources 112 will be apparent. As a specific example, computing resources 112 may be able to implement the features and / or methods discussed in conjunction with Figures 3A-3C Sections 4, 5A - 5B, and 6.

[0025] One or more network interfaces 113 may be configured to transmit and receive V2X messages via V2V communication links 125a - 125d and / or via V2N communication links 120a - 120d. For example, for V2V communication links 125a - 125d, one or more network interfaces 113 may include a V2V network interface, such as an ITS - G5 / 802.11p communication interface. The V2V network interface may be configured to communicate with nearby communication stations (e.g., via short - range broadcasts). The V2V network interface may be configured to tune to one or more broadcast frequencies of V2V communication links 125a - 125d. For V2N communication links 120a - 120d, one or more network interfaces may include a V2N interface, such as a cellular vehicle - to - everything (C - V2X) communication interface or a 3rd Generation Partnership Project (3GPP) Uu interface. The V2N interface may be configured to communicate with RAN equipment 130 and may be configured to send and receive data according to wireless standards. If the communication station equipment 111 includes both a V2N network interface and a V2V network interface, the communication station equipment 111 may be configured to send each V2X message through both interfaces. In this way, the V2V interface can be used to send V2X messages, and the V2N interface can be used to send a copy of the V2X message to the server 140. Other communication stations may receive one or both V2X messages. Alternatively, if the communication station equipment 111 includes both a V2N network interface and a V2V network interface, the communication station equipment 111 may be configured to operate selectively in V2V mode and / or V2N mode. In V2V mode, the V2V network interface may be used to transmit V2X messages. In V2V mode, other communication stations may receive V2X messages directly from another communication station. In V2N mode, the V2N network interface may be used to transmit V2X messages. In V2N mode, other communication stations may receive V2X messages indirectly from another communication station and via the server 140.

[0026] One or more sensors 117 may be configured to collect data of the communication station and / or the communication station environment. Examples of sensor types include radar sensors, lidar sensors, cameras, speedometers, global positioning equipment, and the like. The data collected may form the basis of the communication station status information. In addition to other indications of the station status, the status information may particularly include the location of the communication station, the speed of the communication station, and the direction of the communication station.

[0027] The database 114 may store data associated with V2X communication. For example, the database 114 may include data collected from the sensors 117 (interchangeably referred to as sensor data); data generated by the processing of the sensor data (e.g., indications of detected objects, the current speed of the communication station); records of the status information of the communication station (e.g., records indicating the current status information to be sent in subsequent V2X messages); and the history of V2X messages sent and / or received by the communication station. The database 114 may further include records of the V2X Quality of Service (QoS) information for each communication station 110a - 110d. For example, the database 114 of a communication station (e.g., vehicle 110a) may include the V2X QoS information for each communication station 110a - 110d, such as the latency, packet loss, one-way delay, RTT, or other indications of the V2X link quality of the communication stations 110a - 110d. The V2X QoS information may have been extracted from V2X messages received by the communication station (e.g., V2X messages received from the server 140 or another communication station), or may have been determined by the communication station itself. Examples of V2X QoS information that may be determined by a communication station (e.g., 110a - 110d) will be discussed in connection with Figures 5A-5B and 6.

[0028] The display and adaptive resources 115 may include equipment configured to generate warnings or alerts and / or to adapt the operation of the communication station. The display and adaptive resources 115 may be configured to respond to commands received from the computing resources 112. The commands may be generated based on V2X communication sent or received by the communication station. For example, the display and adaptive resources 115 may generate an emergency vehicle warning, a slow vehicle warning, a wrong-way driving warning, and / or a lane change warning based on commands received from the computing resources 112. Other examples of warnings or alerts can be found in ETSI TR 102 638. The display and adaptive resources 115 may, based on commands received from the computing resources 112, activate and control the vehicle (e.g., 110a - 110c) in a specific manner for an autonomous driving function or an Advanced Driver Assistance System (ADAS) (e.g., steer the vehicle back into the lane, apply the brakes, or the like).

[0029] As briefly mentioned above, the server 140 may be configured to receive, process, and / or forward or otherwise send V2X messages. The server 140 may also be configured to perform one or more processes that enable the determination of the V2X communication quality. These functions of the server 140 may be based on the information stored in the database 150. As Figure 1 depicted, the database 150 may include communication station status information, V2N message forwarding information, and V2X QoS information.

[0030] The communication station status information may include a record associating a communication station identifier with the status information of the communication station. In this way, the server 140 may be able to determine the status information of the communication station based on the communication station identifier. The communication station identifier and the status information may be extracted from the V2X messages received by the server 140.

[0031] The V2X QoS information may include a record associating a communication station identifier with V2X QoS measurements for one or more V2X links associated with the communication station identifier. For example, for vehicle 110a, the V2X QoS information may include a record associating the communication station identifier of vehicle 110a with V2X links 120a, 125a, and 125b. The record may indicate the V2X link based on the identifier of the destination (e.g., for vehicle 110a, the record may indicate V2X link 125a by the communication station identifier of vehicle 110c). For vehicle 110a, the record may further associate each of the V2X links 120a, 125a, and 125b with the V2X QoS measurements of the V2X link. In this way, based on the communication station identifier, the server 140 may be able to determine which links are associated with the communication station and the V2X QoS measurements of the associated V2X links. The V2X QoS measurements may already be included in the V2X messages received by the server 140 (e.g., the V2X messages may include the V2X QoS measurements determined at the communication station), or may have been determined by the server 140 based on the received V2X messages. Examples of V2X QoS information that may be determined by the server 140 will be discussed in conjunction with Figures 3A-3C and 4. Again, the V2X QoS information may include measurements including latency, packet loss, one-way delay, RTT, or other indications of the link quality to the communication station.

[0032] V2N message forwarding information may include a record associating a communication station identifier with an indication as to whether a V2X message is to be forwarded via V2N communication to other communication stations. For example, for vehicle 110a, the V2N message forwarding information may include a record associating the communication station identifier of vehicle 110a with V2X links 120a, 125a, and 125b. The record may indicate the V2X link based on the identifier of the link destination (e.g., for vehicle 110a, the record may indicate V2X link 125a by the communication station identifier of vehicle 110c). For vehicle 110, the record may further associate each of the V2X links 120a, 125a, and 125b with an indication as to whether a V2X message is to be forwarded via V2N communication to the destination of the V2X link. The indication as to whether to forward the V2X message may be determined based on V2X QoS information. As an example for V2X link 125a, if the V2X QoS measurement value of V2X link 125a is below a threshold or an acceptable level, the V2X message may be forwarded via V2N communication; alternatively, if the V2X QoS measurement value is above the threshold or acceptable level, the V2X message may not be forwarded via V2N communication.

[0033] One reason for determining V2X QoS information and message forwarding information is to allow V2N communication when V2V communication is considered unreliable or slow. V2V communication may be unreliable or slow based on factors related to the propagation characteristics of the V2V communication link. For example, the propagation characteristics of a V2X message sent via a V2V communication link (e.g., V2X link 125a) depend on the distance between communication stations (e.g., the distance between vehicle 110a and vehicle 110c), line-of-sight obstacles, the V2V communication load (determined by the communication station density), and any radio interference.

[0034] Figure 2 An example block diagram shows examples of an unreliable or slow V2V communication link and V2X message forwarding using V2N communication. Figure 2 Depicts in connection with Figure 1 a similar example and includes communication stations 110a - 110d, RAN equipment 130, network 135, server 140, and database 150. Instead of showing V2X links 120a - 120d and 125a - 125d, Figure 2 the example of Figure 1 depicts vehicle 110a attempting to send a V2X message via V2V communications 205 and 206. Vehicle 110c successfully receives V2V communication 206. However, due to an unreliable and / or slow V2X link (e.g., Figure 2The example also depicts the vehicle 110a transmitting V2X messages via multi-hop V2N communication, which begins at communication 210 between the vehicle 110b and the RAN equipment 130. For multi-hop V2N communication, based on communications 215 and 220, the V2X message travels via the network 135 to the server 140. The server 140 may determine to forward the V2X message to the vehicle 110b. This determination may be made based on information stored in the database 150 (e.g., V2N message forwarding information and / or V2X QoS information). Based on communications 225 and 230, the V2X message may be forwarded from the server 140 and via the network 135 to the RAN equipment 130. The RAN equipment 130 may send the V2X message to the vehicle 110b based on communication 235. In this way, even when there is an unreliable or slow link between the vehicles 110a and 110b, the vehicle 110b can receive the V2X message. One way to achieve this is to always send V2X messages using both V2V communication and V2N communication. Alternatively, V2N message forwarding may be used based on a selective mode. Additionally, the communication stations 110a - 110d and the server 140 may determine and propagate V2X QoS measurements among them based on Figure 2 the various V2V and V2N communications described therein. Further details regarding the manner in which V2N message forwarding may be implemented and the manner in which V2X QoS measurements may be determined and propagated are provided in the examples below.

[0035] Some of the challenges involved in providing reliable V2X communication include how to determine V2X QoS measurements and how to propagate V2X QoS measurements to each of the communication stations 110a - 110d and the server 140. Examples of how to determine and propagate V2X QoS measurements are provided in Figures 3A-3C , 4, 5A - 5B, and 6. Figures 3A-3C and 4 mainly relate to determination and propagation techniques based on V2N communication. Figures 5A-5B and 6 mainly relate to determination and propagation techniques based on V2V communication between communication stations.

[0036] Figures 3A-3C shows an example process for determining and propagating V2X QoS information based on V2N communication. In particular, Figures 3A-3C shows an example process in which a V2X message is sent from the vehicle V1 and, based on V2N communication, is propagated to one or more other vehicles (e.g., V2). For example, the vehicle V1 may be Figure 1 and 2 's vehicle 110a. For example, the vehicle V2 may be Figure 1 and 2Vehicle 110b. The dissemination of V2X messages can also allow various communication stations and server S1 to determine and disseminate V2X QoS information. Server S1 can be Figure 1 and 2 Server 140. If different vehicles or communication stations (e.g., vehicle 110c) send V2X messages based on their own V2N communication, a similar process will be implemented.

[0037] In Figure 3A and 3B The examples discussed in the example process include the determination of various V2X QoS measurement values, including, for example, latency, round-trip time, and loss. Which specific types of V2X QoS measurement values can be determined may depend on the implementation details of the ITS. For example, determining the latency between vehicle V1 and server S1 may require server S1 and vehicle V1 to be time synchronized. If they are not time synchronized, the latency between vehicle V1 and server S1 may not be determinable. Other measurement values (such as round-trip time and loss) may not be conditional on the time synchronization of vehicle V1 and server S1. Therefore, measurement values such as round-trip time and loss can be determined whether vehicle V1 and server S1 are time synchronized or not.

[0038] Throughout Figures 3A-3C The V2X messages generated and sent in the example process can include various information, including, among other things, the status information of the communication station, the communication station identifier, the timestamp value, the sequence number, and the V2X QoS measurement value. Figure 3A The V2X message is depicted in a simplified form and various abbreviations are used for the various types of information that may be included. The V2X message may include some or all of the information in the following table.

[0039] Table 1: Examples of Information Included in V2X Messages

[0040] Information type Associated with V2X QoS information #timg# In Figures 3A-3C the example process of, the abbreviation #timg# Sequence number of the V2X message Yes, it can be used to determine one or more V2X QoS measurements (e.g., loss). X_Seq_Y, where X indicates the source of the sequence number and Y indicates the value of the sequence number (e.g., V1_Seq_1 indicates the sequence number determined by vehicle V1 and is the first in the sequence). Each link between the server and the communication station may have its own sequence number. Timestamp Yes, it can be used to determine one or more V2X QoS measurements (e.g., delay and round-trip time). TX, where X indicates the value of the timestamp, and a higher value of X is later in time (e.g., T2 is later in time than T1). Timestamp echo Yes, it can be used to determine one or more V2X QoS measurements (e.g., round-trip time). Echo_TX, where X indicates the value of the echo timestamp (e.g., if timestamp T1 is echoed in the V2X message, its abbreviation is ECHO_T1). Server processing time Yes, it can be used to determine one or more V2X QoS measurements (e.g., round-trip time). SProc_TX-TY, where TX and TY indicate the times that form the basis for determining the time taken by the server to process the V2X message (e.g., Sproc_T4-T3 will indicate that the server's processing time is determined based on subtracting T3 from T4). Uplink delay from the communication station to the server Yes, this indicates a V2X QoS measurement (e.g., delay). DelayUL_X, where X indicates the uplink delay value between the server and the communication station. Downlink delay from the server to the communication station Yes, this indicates a V2X QoS measurement (e.g., delay). DelayDL_X, where X indicates the downlink delay value between the server and the communication station. Round-trip time Yes, this indicates a V2X QoS measurement (e.g., round-trip time). RTT_X, where X indicates the value of the round-trip time. Downlink loss from the server to the communication station Yes, this indicates an X QoS measurement (e.g., loss). LossDL_X_Y, where X indicates the communication station associated with the downlink loss, and Y indicates the multiple instances of V2X message loss on the downlink to the communication station (e.g., LossDL_V1_1 indicates that this is the first instance of downlink loss from server S1 to vehicle V1). Uplink loss from the communication station to the server Yes, this indicates a V2X QoS measurement (e.g., loss). LossUL_X_Y, where X indicates the communication station associated with the uplink loss, and Y indicates multiple instances of V2X message loss on the uplink to the communication station (e.g., LossUL_V1_2 indicates that this is the second instance of uplink loss from vehicle V1 to server S1). Communication station identifier No StationID_VX, where X indicates the source station of the identifier (e.g., StationID_V1 is the communication station identifier of vehicle V1). Server identifier No StationID_SX, where X indicates the source server of the identifier (e.g., ServerID_S1 is the identifier of server S1). Status information of the communication station No Not depicted in the example process.

[0041] At 301, vehicle V1 can attempt (e.g., based on V2N communication) to send a first V2X message to server S1. The first V2X message can include the communication station identifier of vehicle V1 (e.g., StationID_V1); a timestamp value indicating the time (T1) when the first V2X message was generated based on the clock of vehicle V1; and the sequence number of the first V2X message (e.g., V1_Seq_1). However, due to an unreliable or slow link or communication hop between vehicle V1 and server S1, the first V2X message may be lost.

[0042] At 303, vehicle V1 may send a second V2X message to server S1. The second V2X message may include the communication station identifier of vehicle V1 (e.g., StationID_V1); a timestamp value indicating the time (T2) when the second V2X message is generated based on the clock of vehicle V1; and a sequence number of the second V2X message (e.g., V1_Seq_2). The second V2X message may travel between vehicle 110a and server 140 along a path similar to that depicted in Figure 2 (e.g., communications 210, 215, and 220).

[0043] At 305, server S1 may determine one or more V2X QoS measurement values based on the second V2X message. For example, server S1 may determine that a loss has occurred on the uplink from vehicle V1 to server S1 based on the sequence number of the second V2X message. The loss may be determined because the second V2X message does not have the expected sequence number (e.g., V1_Seq_1 is expected, but V1_Seq_2 is received). An indication of the uplink loss between vehicle V1 and server S1 may be stored in a database as part of the V2X QoS information (e.g., stored in database 150).

[0044] Additionally, server S1 may determine the time when the second V2X message is received (e.g., T3). This time may be used to determine the server processing time and latency of the second V2X message (e.g., the uplink latency between vehicle V1 and server S1). The uplink latency between vehicle V1 and server S1 may be determined based on subtracting T3 (as determined by server S1) from T2 (as found within the second V2X message). An indication of the uplink latency between vehicle V1 and server S1 may be stored in the database as part of the V2X QoS information. The server processing time will be discussed below in connection with 311.

[0045] At 307, server S1 may determine which communication stations are to forward the second V2X message. This determination may be based on the V2N message forwarding information stored in a database (e.g., database 150). In the example process of Figure 3A , server S1 may determine to forward the second V2X message to vehicle V2.

[0046] At 309, the server S1 can send a forwarded version of the second V2X message to the vehicle V2 based on determining which communication stations to forward to. The forwarded version of the second V2X message can include some or all of the information of the second V2X message and additional information added by the server S1. For example, the server S1 can generate a forwarded version of the second V2X message to include the communication station identifier of vehicle V1 (e.g., StationID_V1); the server identifier (e.g., ServerID_S1); and the sequence number of the V2X message sent from the server S1 to the vehicle V2 (e.g., S1_Seq_1). The server S1 can also generate a forwarded version to include one or more V2X QoS measurements, such as an indication of uplink loss between vehicle V1 and the server S1 (e.g., LossUL_V1_1), and an indication of uplink delay between vehicle V1 and the server S1 (e.g., DelayUL_1). The forwarded version of the second V2X message can travel between the server 140 and the vehicle 110b along a path similar to that depicted in Figure 2 (e.g., communications 225, 230, and 235). Although Figure 3A is not shown, if the server S1 determines to forward the second V2X message to other communication stations, the server S1 will also forward the second V2X message to those stations before proceeding to 311.

[0047] At 310, the vehicle V2 can process the forwarded version of the second V2X message. Processing the forwarded version of the second V2X message can include storing one or more V2X QoS measurements in a local database of the vehicle V2 (e.g., database 114 of vehicle V2). In this way, the vehicle V2 can be informed of the uplink loss between vehicle V1 and the server S1 (e.g., LossUL_V1_1) and the uplink delay between vehicle V1 and the server S1 (DelayUL_1). Processing the forwarded version can also include determining one or more V2X QoS measurements based on the forwarded version. The types of V2X QoS measurements that the vehicle V2 can determine are similar to those discussed below in connection with vehicle V1.

[0048] At 311, the server S1 may send a return version of the second V2X message to the vehicle V1. The return version of the second V2X message may include some or all of the information of the second V2X message and additional information added by the server S1. For example, the server S1 may generate a return version of the second V2X message to include the communication station identifier of the vehicle V1 (e.g., StationID_V1); the server identifier (e.g., ServerID_S1); the sequence number of the V2X message sent from the server S1 to the vehicle V1 (e.g., S1_Seq_1); an echo of the timestamp from the second V2X message (e.g., Echo_T1); and a timestamp indicating the time when the server S1 generated the return version (e.g., T4). The server S1 may also generate a return version to include one or more V2X QoS measurements, such as an indication of uplink loss between the vehicle V1 and the server S1 (e.g., LossUL_V1_1); an indication of uplink delay between the vehicle V1 and the server S1 (e.g., DelayUL_1); and an indication of the processing time of the server S1 for the second V2X message (e.g., Sproc_T4 - T3). The processing time of the server S1 may be determined based on subtracting the time when the return version was generated (e.g., T4) and the time when the server S1 received the second V2X message (e.g., T3).

[0049] At 313, the vehicle V1 may process the return version of the second V2X message. Processing the return version of the second V2X message may include storing one or more V2X QoS measurements in a local database of the vehicle V1 (e.g., database 114 of the vehicle V1). In this way, the vehicle V1 may be informed of the uplink loss between the vehicle V1 and the server S1 (e.g., LossUL_V1_1) and the uplink delay between the vehicle V1 and the server S1 (DelayUL_1).

[0050] The processed return version may also include determining one or more V2X QoS measurement values based on the return version. For example, vehicle V1 may determine the time (e.g., T5) at which the return version of the second V2X message is received. This time may be used to determine the latency (e.g., the downlink latency between vehicle V1 and server S1) and the round-trip time. The downlink latency between vehicle V1 and server S1 may be determined based on subtracting T5 (as determined by vehicle V1) from T4 (as found within the return version of the second V2X message). An indication of the downlink latency between vehicle V1 and server S1 may be stored in the local database of vehicle V1. The round-trip time may be determined based on the timestamp echo of the return version (e.g., Echo_T2), the time at which vehicle V1 receives the return version (e.g., T5), and the processing time of the second V2X message by server S1 (e.g., Sproc_T4 - T3). For example, the round-trip time may be determined by first subtracting T5 from Echo_T2, and then subtracting Sproc_T4 - T3 from the result of the subtraction based on T5 (e.g., the result of T5 - Echo_T2). In other words, the round-trip time may be determined based on (T5 – Echo_T2) – Sproc_T4 - T3. The round-trip time may be stored in the local database of vehicle V1.

[0051] Continue Figure 3B , at 315, vehicle V1 may send a third V2X message to server S1. The third V2X message may include the communication station identifier of vehicle V1 (e.g., StationID_V1); a timestamp value indicating the time (T6) at which the third V2X message is generated based on the clock of vehicle V1; and the sequence number of the second V2X message (e.g., V1_Seq_3). Vehicle V1 may also generate the third V2X message to include one or more V2X QoS measurement values, including for example the round-trip time (RTT_1) between vehicle V1 and server S1 and an indication of the downlink latency between vehicle V1 and server S1 (e.g., DelayDL_1).

[0052] At 317, server S1 may determine one or more V2X QoS measurement values based on the third V2X message. This may be similar to Figure 3A It is implemented according to step 305. For example, server S1 may determine the time when the third V2X message is received (e.g., T7). This time can be used to determine the server processing time and latency of the third V2X message (e.g., the uplink latency between vehicle V1 and server S1). The uplink latency between vehicle V1 and server S1 can be determined based on subtracting T7 (determined by server S1) from T6 (found within the third V2X message). An indication of the uplink latency between vehicle V1 and server S1 can be stored in the database as part of the V2X QoS information. The server processing time will be discussed below in conjunction with 323.

[0053] Determining one or more V2X QoS measurements may include retrieving one or more V2X QoS measurements from the third V2X message and storing any retrieved V2X QoS measurements. For example, server S1 may retrieve the round-trip time and downlink latency from the third V2X message and store those V2X QoS measurements in the database as part of the V2X QoS information. In this way, server S1 can be informed of the round-trip time (RTT_1) between vehicle V1 and server S1 and an indication of the downlink latency between vehicle V1 and server S1 (e.g., DelayDL_1).

[0054] At 319, server S1 may determine which communication stations are to forward the third V2X message. This determination may be based on the V2N message forwarding information stored in the database (e.g., database 150). In Figure 3B the example process, server S1 may determine to forward the third V2X message to vehicle V2.

[0055] At 321, server S1 may send a forwarded version of the third V2X message to vehicle V2 based on the determination of which communication stations are to forward. The forwarded version of the third V2X message may include some or all of the information of the third V2X message and additional information added by server S1. For example, server S1 may generate a forwarded version of the third V2X message to include the communication station identifier of vehicle V1 (e.g., StationID_V1); the server identifier (e.g., ServerID_S1); and the sequence number of the V2X message sent from server S1 to vehicle V2 (e.g., S1_Seq_2). Server S1 may also generate the forwarded version to include one or more V2X QoS measurements, such as an indication of the round-trip time between vehicle V1 and server S1 (e.g., RTT_1), and an indication of the downlink latency between vehicle V1 and server S1 (e.g., DelayDL_1).

[0056] At 322, vehicle V2 may process a forwarded version of the third V2X message. Processing the forwarded version of the third V2X message may include storing one or more V2X QoS measurements in a local database of vehicle V2 (e.g., database 114 of vehicle V2). In this way, vehicle V2 may be informed of the round-trip time between vehicle V1 and server S1 (e.g., RTT_1) and the downlink delay between vehicle V1 and server S1 (e.g., DelayDL_1). Processing the forwarded version may also include determining one or more V2X QoS measurements based on the forwarded version. The types of V2X QoS measurements that vehicle V2 may determine are similar to those discussed below in connection with vehicle V1.

[0057] At 323, server S1 may attempt to send a returned version of the third V2X message to vehicle V1. The returned version of the second V2X message may include some or all of the information of the third V2X message and additional information added by server S1. For example, server S1 may generate a returned version of the third V2X message to include the communication station identifier of vehicle V1 (e.g., StationID_V1); the server identifier (e.g., ServerID_S1); the sequence number of the V2X message sent from server S1 to vehicle V1 (e.g., S1_Seq_2); an echo of the timestamp from the third V2X message (e.g., Echo_T6); and a timestamp indicating the time when server S1 generated the returned version (e.g., T8). Server S1 may also generate the returned version to include one or more V2X QoS measurements, such as an indication of the processing time of server S1 for the third V2X message (e.g., Sproc_T8-T7). The processing time of server S1 may be determined based on subtracting the time when the returned version was generated (e.g., T8) and the time when server S1 received the third V2X message (e.g., T7). However, due to an unreliable or slow link or communication hop between vehicle V1 and server S1, the returned version of the third V2X message may be lost.

[0058] At 325, vehicle V1 may send a fourth V2X message to server S1. The fourth V2X message may include the communication station identifier of vehicle V1 (e.g., StationID_V1); a timestamp value indicating the time when the third V2X message was generated based on the clock of vehicle V1 (T9); and the sequence number of the second V2X message (e.g., V1_Seq_4).

[0059] At 327, server S1 may perform V2X server processing based on the fourth V2X message. The V2X server processing may include similar to that in Figure 3A and 3BThe steps discussed at 305, 307, 309, 317, and 319. In other words, based on the fourth V2X message, the server S1 can determine one or more V2X QoS measurement values (e.g., Sproc_T11-T10), determine which communication stations are to forward the fourth V2X message, and send a forwarded version of the fourth V2X message to one or more communication stations (e.g., vehicle V2).

[0060] Continue Figure 3C , at 329, the server S1 can send a returned version of the fourth V2X message. The returned version of the fourth V2X message can include some or all of the information of the fourth V2X message and additional information added by the server S1. For example, the server S1 can generate a returned version of the fourth V2X message to include the communication station identifier of vehicle V1 (e.g., StationID_V1); the server identifier (e.g., ServerID_S1); the sequence number of the V2X message sent from the server S1 to vehicle V1 (e.g., S1_Seq_3); an echo of the timestamp from the fourth V2X message (e.g., Echo_T9); and a timestamp indicating the time when the server S1 generated the returned version (e.g., T11). The server S1 can also generate a returned version to include one or more V2X QoS measurement values, such as an indication of the processing time of the server S1 for the third V2X message (e.g., Sproc_T11-T10). The processing time of the server S1 can be determined based on subtracting the time when the returned version was generated (e.g., T11) and the time when the server S1 received the third V2X message (e.g., T10).

[0061] At 331, vehicle V1 can process the returned version of the fourth V2X message. Processing the returned version of the fourth V2X message can include storing one or more V2X QoS measurement values in a local database of vehicle V1 (e.g., database 114 of vehicle V1). In this way, vehicle V1 can be informed of the uplink loss (e.g., LossUL_V1_1) between vehicle V1 and the server S1 and the uplink delay (DelayUL_1) between vehicle V1 and the server S1.

[0062] Processing the returned version can also include determining one or more V2X QoS measurement values based on the returned version. For example, vehicle V1 can determine that there is a loss on the downlink from vehicle V1 to the server S1 based on the sequence number of the returned version. The loss can be determined because the returned version does not have the expected sequence number (e.g., S1_Seq_2 is expected, but S1_Seq_3 is received). An indication of the downlink loss between vehicle V1 and the server S1 can be stored in the local database of vehicle V1.

[0063] Additionally, vehicle V1 can determine the time (e.g., T12) at which it receives the returned version of the fourth V2X message. This time can be used to determine the latency (e.g., the downlink latency between vehicle V1 and server S1) and the round-trip time. The downlink latency between vehicle V1 and server S1 can be determined based on subtracting T12 (as determined by vehicle V1) from T11 (as found within the returned version of the fourth V2X message). An indication of the downlink latency between vehicle V1 and server S1 can be stored in the local database of vehicle V1. The round-trip time can be determined based on the timestamp echo of the returned version (e.g., Echo_T9), the time at which vehicle V1 receives the returned version (e.g., T12), and the processing time of the second V2X message at server S1 (e.g., Sproc_T11 - T10). For example, the round-trip time can be determined based on (T12 - Echo_T9) - Sproc_T11 - T10. The round-trip time can be stored in the local database of vehicle V1.

[0064] At 333, vehicle V1 can send a fifth V2X message to server S1. The fifth V2X message can include the communication station identifier of vehicle V1 (e.g., StationID_V1); a timestamp value indicating the time (T13) at which the fifth V2X message is generated based on the clock of vehicle V1; the sequence number of the second V2X message (e.g., V1_Seq_5). Vehicle V1 can also generate the fifth V2X message to include one or more V2X QoS measurements, including for example the round-trip time between vehicle V1 and server S1 (e.g., RTT_2) and an indication of the downlink latency between vehicle V1 and server S1 (e.g., DelayDL_2); and an indication of the downlink loss between vehicle V1 and server S1 (e.g., LossDL_V1_1).

[0065] At 335, server S1 can determine one or more V2X QoS measurements based on the fifth V2X message. This can be performed similar to Figure 3A step 305. For example, server S1 can determine the time (e.g., T14) at which it receives the fifth V2X message. This time can be used to determine the server processing time and latency of the fifth V2X message (e.g., the uplink latency between vehicle V1 and server S1). The uplink latency between vehicle V1 and server S1 can be determined based on subtracting T13 (as found within the fifth V2X message) from T14 (as determined by server S1). An indication of the uplink latency between vehicle V1 and server S1 can be stored in the database as part of the V2X QoS information.

[0066] Determining one or more V2X QoS measurements can include retrieving one or more V2X QoS measurements from a third V2X message and storing any retrieved V2X QoS measurements. For example, server S1 can retrieve a round-trip time, an indication of downlink latency, and an indication of downlink loss from a fifth V2X message and store those V2X QoS measurements in a database as part of the V2X QoS information. In this way, server S1 can be informed of the round-trip time between vehicle V1 and server S1 (e.g., RTT_2), the indication of downlink latency between vehicle V1 and server S1 (e.g., DelayDL_2); and the indication of downlink loss between vehicle V1 and server S1 (e.g., LossDL_V1_1).

[0067] At 337, server S1 can determine which communication stations are to forward the fifth V2X message. This determination can be based on the V2N message forwarding information stored in a database (e.g., database 150). In Figure 3C the example flow, server S1 can determine to forward the fifth V2X message to vehicle V2.

[0068] At 339, server S1 can send a forwarded version of the fifth V2X message to vehicle V2 based on the determination of which communication stations are to forward. The forwarded version of the fifth V2X message can include some or all of the information of the fifth V2X message and additional information added by server S1. For example, server S1 can generate a forwarded version of the fifth V2X message to include the communication station identifier of vehicle V1 (e.g., StationID_V1); the server identifier (e.g., ServerID_S1); and the sequence number of the V2X message sent from server S1 to vehicle V2 (e.g., S1_Seq_3). Server S1 can also generate the forwarded version to include one or more V2X QoS measurements, such as the round-trip time between vehicle V1 and server S1 (e.g., RTT_2) and the indication of downlink latency between vehicle V1 and server S1 (e.g., DelayDL_2); and the indication of downlink loss between vehicle V1 and server S1 (e.g., LossDL_V1_1).

[0069] At 341, vehicle V2 may process a forwarded version of the fifth V2X message. Processing the forwarded version of the fifth V2X message may include storing one or more V2X QoS measurements in a database local to vehicle V2 (e.g., database 114 of vehicle V2). In this way, vehicle V2 may be informed of the round-trip time between vehicle V1 and server S1 (e.g., RTT_2) and an indication of the downlink delay between vehicle V1 and server S1 (e.g., DelayDL_2); and an indication of the downlink loss between vehicle V1 and server S1 (e.g., LossDL_V1_1). Processing the forwarded version may also include determining one or more V2X QoS measurements based on the forwarded version.

[0070] Additionally, vehicles and other communication stations may be able to take actions based on the V2X QoS measurements. These actions may be performed as part of or based on the vehicle's processing of received V2X messages (e.g., Figure 3A - 3C steps 310, 313, 332, 331, 341). For example, vehicle V2 may display a warning or send a command to the vehicle's adaptive resources based on the V2X QoS measurements (e.g., similar to Figure 1 the discussion of the display and adaptive resources 115). As some specific examples, based on an indication of the downlink loss between vehicle V1 and server S1, vehicle V2 may cause the display of a safety distance warning that indicates that vehicle V1 is at an unsafe distance from vehicle V2. In this way, the driver may apply the brakes to provide additional distance between themselves and vehicle V1. Based on an indication of the uplink loss between vehicle V1 and server S1, vehicle V2 may send a command to the ADAS of vehicle V2. The command may cause the application of the brakes of vehicle V2 to increase the distance between vehicle V1 and vehicle V2. These examples illustrate ways to improve the safety between vehicle V1 and V2 by taking actions based on potentially unreliable communication with vehicle V1.

[0071] Figure 3A - 3C The above example processes of Figure 3A - 3C The above example flow also provides multiple examples of how it propagates V2X QoS measurements to communication stations (e.g., vehicles V1 and V2) and a server (e.g., server S1). Based on the example flow, the server may perform similar steps upon receiving each V2X message. For example, for each V2X message, the server may determine one or more V2X QoS measurements, determine which communication stations are to forward the V2X message; send one or more forwarded versions of the V2X message to one or more communication stations; and send a return version of the V2X message to the source of the V2X message. Figure 4 An example method of V2X message processing that can be performed by a server is shown. For example, the example method can be performed each time the server receives a V2X message based on V2N communication. Figure 3A - 3C An example process, Figure 4 An example method may be performed by server S1 for combining Figure 3A - 3C Each of the first to fifth V2X messages described in the example flow is performed. Figure 4 For purposes of the example methods, a server will be referred to as a computing device.

[0072] At 401, a computing device (eg, Figure 3A - 3C Server S1; Figure 1 or 2) can receive the V2X message. The V2X message may have been received from a communication station (e.g., Figure 3A - 3C Vehicle V1; or Figure 1 and 2 The V2X message may have been based on a multi-hop V2N communication path (e.g., Figure 2 The V2X message may include some or all of the information included in Table 1. For example, the V2X message may be in Figure 3A - 3C Any V2X message described in the example process (e.g., the first to fifth V2X messages).

[0073] At 403, the computing device may determine one or more V2X QoS measurements based on the V2X message. This determination may be similar to Figure 3A - 3C For example, the computing device may determine V2X QoS measurements such as round trip time, server processing time for V2X messages, uplink latency, downlink latency, uplink loss, and downlink loss. In practice, the computing device may determine the V2X QoS measurements throughout the communication. Figure 3A - 3C Any V2X QoS measurement discussed in the example process (e.g., LossUL_V1_1; LossDL_V1_1; DelayUL_1; DelayUL_2; DelayDL_1; RTT_1; RTT_2; Sproc_T4-T3; SprocT8-T7; Sproc_T11-T10). Some V2X QoS measurements can be determined based on the generation of the return version of the V2X message (e.g., the server processing time of the V2X message). Some V2X QoS measurements (e.g., downlink delay, round-trip time, and downlink loss) can be retrieved from the V2X message, and other V2X QoS measurements (e.g., server processing time, uplink delay, and uplink loss) can be determined by the computing device. Each of one or more V2X QoS measurements can be stored in a database (e.g., Figure 1 and 2 database 150) of

[0074] At 405, the computing device can determine one or more communication stations to forward the V2X message. This determination can be performed similarly to Figure 3A - 3C steps 307, 319, and 337 of Figure 1 and 2 As an example of

[0075] At step 407, the computing device can generate and send one or more forwarded versions of the V2X message. This determination can be similar to Figure 3A - 3C performed according to steps 309, 321, and 339 of []. For example, one or more forwarded versions may be sent to each of the one or more communication stations determined at step 405. Each forwarded version of the V2X message may include some or all of the information included in Table 1. Additionally, each forwarded version may include some or all of the information of the V2X message and additional information added by the computing device when generating the forwarded version. For example, the forwarded version of the V2X message may be any of the forwarded versions described in the example flow of Figure 3A - 3C (e.g., the forwarded versions sent at Figure 3A - 3C steps 309, 321, and 339 of []).

[0076] At step 409, the computing device may generate and send a return version of the V2X message. This determination may be performed similarly to Figure 3A - 3C steps 311, 323, and 329 of []. For example, the return version may be sent to the source of the V2X message (e.g., if the V2X message was sent from vehicle 110a, the return version may be sent from the computing device and to vehicle 110a). The return version of the V2X message may include some or all of the information included in Table 1. Additionally, the return version may include some or all of the information of the V2X message and additional information added by the computing device when generating the return version. For example, the return version of the V2X message may be any of the return versions described in the example flow of Figure 3A - 3C (e.g., the return versions sent at Figure 3A - 3C steps 311, 323, and 329 of []). After sending the return version of the V2X message, the method may end, and the computing device may wait to receive another V2X message, based on which the example method of Figure 4 may be repeated.

[0077] Figure 3A - 3C and Figure 4 The above examples mainly relate to determination and propagation techniques based on V2N communication. There are additional ways to determine V2X QoS measurements and propagate those V2X QoS measurements to communication stations. For example, V2X QoS measurements may be determined based on V2V communication between communication stations. Figure 5A - 5B and 6 mainly relate to determination and propagation techniques based on V2V communication.

[0078] Additional types of V2X QoS measurements may be determined based on V2V communication between communication stations. Table II provides additional examples of V2X QoS measurements that may be determined based on V2V communication and may be included in V2X messages.

[0079] Table II: Examples of Additional Information Included in V2X Messages

[0080] Information type Associated with V2X QoS information #timg# Uplink delay from the first communication station to the second communication station Yes, this indicates a V2X QoS measurement value (e.g., one-way delay between communication stations). Downlink delay from the first communication station to the second communication station Yes, this indicates a V2X QoS measurement value (e.g., one-way delay between communication stations). Downlink loss from the first communication station to the second communication station Yes, this indicates a V2X QoS measurement value (e.g., directional loss between communication stations) Uplink loss from the first communication station to the second communication station Yes, this indicates a V2X QoS measurement value (e.g., directional loss between communication stations)

[0081] In addition, which specific types of V2X QoS measurements can be determined depending on the implementation details of the ITS. For example, determining the one-way latency between two communication stations may require the two communications to be time synchronized. If they are not time synchronized, the one-way latency between the two communication stations may not be determined. Other measurements (such as round-trip time and direction loss) may not be conditional on the communication stations being time synchronized. Therefore, measurements such as round-trip time and direction loss can be determined regardless of whether the two communication stations are time synchronized.

[0082] Figure 5A An example method for a communication station to transmit one or more V2X messages is shown, where the V2X messages include V2X QoS measurements determined based on V2V communication. The example method is described as being performed by a first communication station (e.g., Figure 1 and 2 any one of communication stations 110a - 110d; Figure 3A - 3C vehicle V1).

[0083] At step 501, the first communication station may generate a V2X message to include one or more V2X QoS measurements. The first communication station may determine which V2X QoS measurements to include in the V2X message based on a queuing mechanism or other indication that the first communication station needs to transmit one or more V2X QoS measurements. As described below in connection with Figure 5B step 555, the V2X QoS measurements may be placed in a queue or otherwise indicated that it needs to be transmitted. One or more V2X QoS measurements may have been determined based on previous V2X messages previously received or transmitted by the first communication station. Additionally, the previous V2X messages may have been received or transmitted based on V2V communication with one or more other communication stations. Details on how to determine one or more V2X QoS measurements based on previous V2X messages will be discussed below in connection with Figure 5B step 555.

[0084] At step 503, the first communication may transmit the V2X message to one or more other communication stations based on V2V communication. The V2X message may be transmitted via a V2V network interface and / or based on short-range broadcast. In this way, based on receiving the V2X message, other communication stations can be informed of one or more V2X QoS measurements. The V2X message transmitted based on V2V communication may include information similar to that described in connection with Tables I and II.

[0085] At step 505, the first communication station may determine whether the computing device is configured with a V2N network interface. If the computing device is configured with a V2N network interface, the method may proceed to step 507. Otherwise, the method may end.

[0086] At 507, a first communication station may send a V2X message to a server based on V2N communication. The V2X message may be sent to RAN equipment via a V2N network interface and / or based on wireless communication. Eventually, the server may receive the V2X message and, based on the received V2X message, may be informed of one or more V2X QoS measurements. As described in examples throughout this disclosure, the server may perform multiple processes based on the received V2X message (including, for example, by implementing Figure 4 and Figure 6 one or more of the example methods described and variations thereof). The V2X message sent based on V2N communication may include information similar to that described in connection with Table 1.

[0087] Figure 5B An example method for a communication station to receive and process a V2X message that includes V2X QoS measurements determined based on V2V communication is shown. The example method is described as being performed by a first communication station (e.g., Figure 1 and 2 any one of communication stations 110a - 110d; Figure 3A - 3C vehicle V1).

[0088] At step 551, the first communication station may receive a V2X message from a second communication station based on V2V communication. The V2X message may be received by the first communication station via a V2V network interface or based on a short - range broadcast performed by the second communication station. The V2X message may include information similar to that described in connection with Tables I and II.

[0089] At step 553, the first communication station may determine one or more V2X QoS measurements based on the V2X message. The first communication station may determine various types of V2X QoS measurements based on the V2X message. Figure 5B Three examples are shown. The first example includes the first communication station determining a one - way delay between the first communication station and the second communication station. The second example includes the first communication station determining a direction loss between the first communication station and the second communication station. The third example includes the first communication station determining a round - trip time between the first communication station and the second communication station. Determining the one - way delay, direction loss, and round - trip time between communication stations may be performed similar to the delay, loss, and round - trip time described in connection with Figure 3A - 3C the example flows of Table I. Additionally, examples of determining the one - way delay, direction loss, and round - trip time between communication stations are provided below.

[0090] For example, the one-way latency between the first communication station and the second communication station can be determined based on the time difference between the time when the second communication station generates a V2X message and the time when the first communication station receives the V2X message. The timestamp within the V2X message can indicate the time when the second communication station generates the V2X message. This timestamp can be based on the clock of the second communication station. The first communication station can determine the time when the first communication station receives the V2X message. The determination of time by the first communication station can be performed based on the clock of the first communication station. The one-way latency can be based on the direction (for example, the downlink latency can indicate the latency of a message sent by the first communication station; the uplink latency can indicate the latency of a message sent by the second communication station). Based on the indication of the downlink latency included in the V2X message sent from the second communication station, the first communication station can be informed of the downlink latency.

[0091] The determination of the direction loss between the first communication station and the second communication station can be performed based on the sequence numbers included in the V2X message and a previous V2X message. The previous V2X message may have been previously received by the first communication station and sent by the second communication station. The first communication station may be expecting the sequence numbers to be in order, and if they are not, the first communication station can determine that an uplink loss has occurred between the first communication station and the second communication station. This loss can be based on the direction (for example, the downlink loss of the first communication station can indicate how many V2X messages sent by the first communication station are lost; the downlink loss of the first communication station can indicate how many V2X messages sent by the second communication station are lost). Based on the indication of the downlink loss included in the V2X message sent from the second communication station, the first communication station can be informed of the downlink loss.

[0092] The determination of the round-trip time between the first communication station and the second communication station can be performed based on the time difference between the time when the first communication station generates or sends a previous V2X message to the second communication station and the time when the first communication station receives the V2X message. For example, the first communication station may have sent a previous V2X message to the second communication station. The previous V2X message may have included a timestamp indicating the time when the previous V2X message was generated (for example, T21). The V2X message received at step 551 can include an echo of the timestamp (for example, ECHO_T21). The first communication station can determine the round-trip time based on the time when the V2X message is received at the first communication station (for example, T22) minus the echo of the timestamp. In other words, the round-trip time can be determined based on the following: Round-trip time = T22 – ECHO_T21.

[0093] At step 555, the first communication station can store one or more V2X QoS measurements. For example, one or more V2X QoS measurements can be stored in the local database of the communication station (for example,Figure 1 in the database 114). Each V2X QoS measurement value can be stored in a record that associates the V2X QoS measurement value with an indication of the V2V link (e.g., Figure 1 of 125a - 125c) or with the communication stations that form the V2V link (e.g., throughout Figure 5B the second communication station provided in the example). Additionally, storing one or more V2X QoS measurement values can include queuing or otherwise indicating that one or more V2X QoS measurement values need to be sent by the first communication station. The queuing or indication can be used as a basis for including one or more V2X QoS measurement values within one or more V2X messages that are later sent based on V2N and / or V2V communication (as described in connection with Figure 5A ).

[0094] Additionally, the first communication station may be able to take actions based on one or more V2X QoS measurement values. For example, the first communication station can display a warning or send a command to the adaptive resources of the first communication station based on one or more V2X QoS measurement values (e.g., similar to Figure 1 the discussion of the display and the adaptive resources 115). As some specific examples, based on an indication of the directional delay between the first communication station and the second communication station, the first communication station can cause the display to indicate a safety distance warning that the first communication station is at an unsafe distance from the second communication station. In this way, and if the first communication station is a vehicle, the driver can apply the brakes to provide additional distance between the first communication station and the second communication station. Based on an indication of the directional delay between the first communication station and the second communication station, the first communication station can send a command to the ADAS of the first communication station. The command can cause the application of the brakes to increase the distance between the first communication station and the second communication station. These examples illustrate a method of enhancing safety between communication stations by taking actions based on potentially unreliable communication between the first communication station and the second communication station.

[0095] Figure 6 illustrates an example method for a server to receive and process V2X messages that include V2X QoS measurement values determined based on V2V communication. In particular, the example method includes the step of enabling or disabling V2N network forwarding for a communication station based on the V2X QoS measurement values. For example, based on one or more V2X QoS measurement values determined by the first communication station (e.g., Figure 5B step 553), the server (e.g., Figure 1 and 2 server 140; Figure 4 The server S1) can enable or disable V2N message forwarding between the first communication station and the second communication station. By enabling V2N message forwarding, the server can forward V2X messages between the first communication station and the second communication station to compensate for a potentially unreliable or slow V2V link between the first communication station and the second communication station. By disabling V2N message forwarding, the server can reduce the number of V2X messages sent among the ITSs.

[0096] At step 601, the server can receive a V2X message from the first communication station and based on V2N communication. The V2X message can be received by the server based on V2N communication (e.g., Figure 5A step 507). The V2X message can include information similar to that described in connection with Tables I and II.

[0097] At step 603, the server can extract both the status information of the first communication station and one or more V2X QoS measurements from the V2X message. The one or more V2X QoS measurements can include measurements based on the V2V link between the first communication station and the second communication station (e.g., Table II and Figure 5B step 553). The one or more V2X QoS measurements can include measurements based on the V2N link between the first communication station and the server (e.g., Table I; Figure 3A - 3C ; Figure 4 step 401). After extracting the status information and the one or more V2X QoX measurements from the V2X message, the server can store the status information and the one or more V2X QoS measurements. For example, the server can store the status information as part of the communication station status information of a database (e.g., Figure 1 and 2 database 150). Storing the status information can include generating or updating one or more records of the communication status information. The server can store the one or more V2X QoS measurements as part of the V2X QoS information of the database. Storing the one or more V2X QoS measurements can include generating or updating one or more records of the V2X QoS information.

[0098] At step 605, the server may determine whether one or more QoS objectives are met. The one or more QoS objectives may be for the V2V link. For example, the QoS objective for the V2V link may be a threshold or other value indicating that the V2V link is unreliable or slow. As a specific example, the QoS objective may be a threshold for one-way latency (e.g., a threshold of 100 milliseconds). This threshold may be compared with the measured value of the one-way latency of the V2V link between the first communication station and the second communication station. The measured value may have been extracted from the V2X measurement or retrieved from the V2X QoS information. If the measured value exceeds the threshold for one-way latency, the server may determine that the QoS objective is not met. The process of comparing the measured value with the QoS objective may be repeated for any remaining QoS objectives (e.g., the QoS objective for round-trip time, the QoS objective for packet loss). If at least one of the one or more QoS objectives is not met, the method may proceed to step 607. If each of the one or more QoS objectives is met, the method may proceed to step 609.

[0099] At step 607, the server may store an indication enabling V2N message forwarding between the first communication station and the second communication station. The server may store an indication enabling V2N message forwarding between the first communication station and the second communication station as part of the V2N message forwarding information in the database. Storing the indication may include generating or updating one or more records of the V2N message forwarding information.

[0100] At step 609, the server may store an indication disabling V2N message forwarding between the first communication station and the second communication station. The server may store an indication disabling V2N message forwarding between the first communication station and the second communication station as part of the V2N message forwarding information in the database. Storing the indication may include generating or updating one or more records of the V2N message forwarding information.

[0101] At 611, the server may determine one or more communication stations to forward the V2X message. This determination may be performed similar to Figure 4 step 405. As a further example, this determination may be performed based on the status information of the first communication station (e.g., the location, speed, and direction of the first communication station). The server may have extracted the status information from the V2X message or retrieved the status information from the V2X QoS information. The status information of the first communication station may be compared with the status information of any other communication stations. For example, the status information of the first communication station may be compared with the status information of each communication station stored in the communication station status information in the database. Based on this comparison, the server may determine a set of communication stations close to or near the first communication station. Being close to or near the first communication station may be based on the speed, direction, and location of the communication station. For example, if the first communication station isFigure 1 For vehicle 110a, vehicles 110b and 110c may be part of a set of communication stations, but based on the distance between RSU 110 and vehicle 110a, RSU 110d may not be part of the set.

[0102] The set of communication stations can be compared with V2N message forwarding information to determine which communication stations are enabled for forwarding. For example, the server can first retrieve a record of a first communication station from the V2N message forwarding information. The set of communication stations can be compared with the record to determine, based on the record, which communication stations in the set are associated with an indication of enabled V2N message forwarding information. Based on the comparison, the server can determine one or more communication stations that are enabled for V2N message forwarding. The server can determine to forward the V2X message to the one or more communication stations that are enabled for V2N message forwarding.

[0103] At 613, for each of the one or more communication stations that are enabled for V2N message forwarding, the server can generate and send a forwarded version of the V2X message. The generation and sending of the forwarded version can be, for example, similar to Figure 4 step 407 of

[0104] As seen from the example method described above in Figure 6 the server can perform steps similar to the steps described in connection with Figure 4 If the server is configured to perform additional steps described in connection with Figure 4 the example method of Figure 6 can be extended. For example, the server can also be configured to generate and send a returned version of the V2X message received at step 601. Thus, after step 613, the server can generate and send a returned version of the V2X message. The returned version of the V2X message can be sent to the first communication station. Additional extensions and variations of the example method of Figure 6 can be implemented based on the configuration of the server or other components of the ITS.

[0105] Any method steps, operations, processes, or functions described herein can be implemented using one or more processors and / or one or more memories in combination with machine-executable instructions that cause the processors and other components to perform the various method steps, features described, or other aspects described herein. Figure 7 The example of Figure 1 and 2 shows an example apparatus, particularly computing device 712, that can be used in the example environment of Figure 1 and 2any or all of the functions found in devices, stations, equipment, points, sensors, or the like as shown in FIGS. 3A - 3C. Additionally, computing device 712 can be configured to perform some or all of the steps discussed in connection with Figure 3A - 3C , 4, 5A - 5B, and 6. Computing device 712 can be configured to perform any other processes, features, or aspects discussed in connection with Figure 1 - 6 , or any variations thereof.

[0106] Computing device 712 shows only one example of the various types of hardware components that can be present in a device configured to implement one or more aspects described in this disclosure. Computing device 712 can include a controller 725. Controller 725 can be connected to user interface control 730, display 736, and / or other elements as illustrated. Controller 725 can include circuitry, such as for example one or more processors 728 and one or more memories 734 that store software 740. Software 740 can include, for example, one or more of the following software options: client software 765, user interface software, server software, database software, and the like.

[0107] Device 712 can also include a battery 750 or other power source, a speaker 753, and one or more antennas 754. Device 712 can include user interface circuitry, such as user interface control 730. User interface control 730 can include a controller or adapter and other circuitry that is configured to receive input from or provide output to, for example, a keypad, touch screen, voice interface, via a microphone 756, function keys, joystick, data glove, mouse, and the like. The user interface circuitry and user interface software can be configured to facilitate user control of at least some functions of device 712 by using display 736. Display 736 can be configured to display at least a portion of the user interface of device 712. Additionally, the display can be configured to facilitate user control of at least some functions of the device (e.g., display 736 can be a touch screen).

[0108] Software 740 can be stored within memory 734 to provide instructions to processor 728 such that when the instructions are executed, they cause processor 728, device 712, and / or other components of device 712 to perform various processes or methods, such as those described herein. The software can include machine - executable instructions and data used by processor 728, and other components of computing device 712 can be stored in storage facilities such as memory 734 and / or in hardware logic in integrated circuits, ASICs, etc. The software can include both application and operating system software, and can include code segments, instructions, applets, pre - compiled code, compiled code, computer programs, program modules, engines, program logic, and combinations thereof.

[0109] The memory 734 may include any of a variety of types of tangible machine-readable storage media, including one or more of the following types of storage devices: read-only memory (ROM) modules, random access memory (RAM) modules, magnetic tapes, magnetic disks (e.g., fixed hard disk drives or removable floppy disks), optical disks (e.g., CD-ROM disks, CD-RW disks, DVD disks), flash memory, and EEPROM memory. As used herein (including in the claims), a tangible or non-transitory machine-readable storage medium is a physical structure that can be touched by a human. A signal by itself will not constitute a tangible or non-transitory machine-readable storage medium, although other embodiments may include signals or transient versions of instructions executable by one or more processors to perform one or more of the operations described herein.

[0110] As used herein, the processor 728 (and any other processor or computer described herein) may include any of a variety of types of processors, whether used alone or in combination with executable instructions stored in memory or other computer-readable storage media. A processor should be understood to encompass any of a variety of types of computing structures, including but not limited to one or more microprocessors, dedicated computer chips, field programmable gate arrays (FPGAs), controllers, application specific integrated circuits (ASICs), combinations of hardware / firmware / software, or other dedicated or general purpose processing circuitry.

[0111] As used in this application, the term "circuit" may refer to any of the following: (a) only hardware circuit implementations (such as only in analog and / or digital circuits) and (b) combinations of hardware circuits and software (and / or firmware), such as, as applicable: (i) combinations of (one or more) processors or (ii) (one or more) processors / software (including (one or more) digital signal processors), portions of software, and (one or more) memories that work together to cause a device such as a mobile phone or a server to perform various functions) and (c) hardware circuits, such as (one or more) microprocessors or portions of (one or more) microprocessors, which require software or firmware to operate, even if the software or firmware is not physically present.

[0112] These examples of "circuit" apply to all uses of the term in this application (including in any claims). As an example, as used in this application, the term "circuit" will also cover implementations that are only a processor (or processors) or a portion of a processor and its (or their) accompanying software and / or firmware. The term "circuit" will also cover, for example, a baseband integrated circuit or an application processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or other network device.

[0113] Device 712 may be configured to receive, decode, and process various types of transmissions via one or more specific WLAN transceivers 743, one or more WMAN transceivers 741, including transmissions in a Wi-Fi network according to a wireless local area network (e.g., IEEE 802.11 WLAN standards 802.11n, 802.11ac, etc.) and / or a wireless metropolitan area network (WMAN) standard (e.g., 802.16). Additionally or alternatively, device 712 may be configured to receive, decode, and process transmissions via various other transceivers such as FM / AM radio transceivers 742 and telecommunications transceivers 744 (e.g., cellular network receivers such as CDMA, GSM, 4G LTE, 5G, etc.).

[0114] Device 712 may include one or more additional network interfaces, such as the V2V network interface and the V2N network interface described in conjunction with Figure 1 and 2 Device 712 or its various components may be mobile (e.g., user equipment), or incorporated into a larger mobile device (e.g., a vehicle). Device 712 or its various components may be incorporated into any communication station described throughout this disclosure. For example, device 712 may be incorporated into communication station equipment 111 described in conjunction with Figure 1 (e.g., the controller 725 of device 712 may be configured to operate as computing resource 112 and database 114; the display may be configured to operate as a display resource of the display and adaptive resource 115 described in conjunction with Figure 1 ). Additionally, device 712 may include adaptive resources of any sensor 117 and / or display and adaptive resource 115 described in conjunction with Figure 1 .

[0115] Other devices or systems may include the same or similar components and perform the same or similar functions and methods. For example, a computer connected via a wired network (e.g., Figure 1 and 2 's server 140) may include the components or a subset of the components described above and may be configured to perform the same or similar functions as device 712 and its components. Further access points as described herein may include components, a subset of components, or multiple components (e.g., integrated in one or more servers) configured to perform the steps described herein.

[0116] Although specific examples of practicing the present invention have been described, there are many variations and permutations of the systems and methods described above that are within the spirit and scope of the present invention as set forth in the appended claims.

Claims

1. A method for vehicle-to-everything V2X communication, comprising: Receiving, by a computing device and from a first communication station via vehicle-to-network V2N communication, a V2X message; Determining, by the computing device and based on the V2X message, one or more V2X quality of service QoS measurements, wherein the V2X QoS measurements include measurements based on a vehicle-to-vehicle V2V link; Determining, based on the V2X QoS measurements, whether a QoS target is met for a V2V link between the first communication station and a second communication station; When the QoS target is not met for the V2V link, storing an indication to enable V2N message forwarding between the first communication station and the second communication station; Determining, by the computing device, at least one communication station for forwarding the V2X message based on at least one of V2N message forwarding information or V2X QoS information; Generating a forwarded version of the V2X message, the forwarded version including the one or more V2X QoS measurements; Transmitting, by the computing device and to the at least one communication station via V2N communication, the forwarded version of the V2X message.

2. The method according to claim 1, comprising: Generating a returned version of the V2X message, the returned version including the one or more V2X QoS measurements; And Transmitting, by the computing device and to the first communication station via V2N communication, the returned version of the V2X message.

3. The method according to claim 2, wherein the V2X message includes a first timestamp determined by the first communication station, and wherein the returned version of the V2X message includes a server identifier, a second timestamp determined by the computing device, a timestamp echo indicating the first timestamp, and a server processing time of the V2X message.

4. The method according to claim 1, wherein the one or more V2X QoS measurements include a round-trip time associated with the first communication station, an indication of latency associated with the first communication station, or an indication of V2X message loss associated with the V2X message.

5. The method according to claim 1, further comprising: Storing, by the computing device based on the determination that the QoS target is met, an indication to disable V2N message forwarding between the first communication station and the second communication station.

6. The method according to claim 1, further comprising: Determining, by the first communication station, a one-way latency between the first communication station and the second communication station; Determining, by the first communication station, a direction loss between the first communication station and the second communication station; Determining, by the first communication station, a round-trip time between the first communication station and the second communication station; Transmitting, by the first communication station in one or more V2X messages, an indication of the one-way latency between the first communication station and the second communication station, an indication of the direction loss between the first communication station and the second communication station, and an indication of the round-trip time between the first communication station and the second communication station to one or more other communication stations and / or computing devices.

7. An apparatus for vehicle-to-everything V2X communication, comprising: One or more processors; And A memory storing executable instructions that, when executed by the one or more processors, cause the apparatus to perform at least the following operations: Receive a V2X message via vehicle-to-network V2N communication from a first communication station; Determine one or more V2X quality of service QoS measurement values based on the V2X message, wherein the V2X QoS measurement values include measurements based on a vehicle-to-vehicle V2V link; Determine whether a QoS target is met for a V2V link between a first communication station and a second communication station based on the V2X QoS measurement values; When the QoS target is not met for the V2V link, store an indication to enable V2N message forwarding between the first communication station and the second communication station; Determine at least one communication station for forwarding the V2X message based on at least one of V2N message forwarding information or V2X QoS information; Generate a forwarded version of the V2X message, the forwarded version including the one or more V2X QoS measurement values; Send the forwarded version of the V2X message to the at least one communication station via V2N communication.

8. The apparatus according to claim 7, wherein when executed by the one or more processors, the executable instructions cause the apparatus to perform the following operations: Generate a return version of the V2X message, the return version including the one or more V2X QoS measurement values; and Send the return version of the V2X message to the first communication station via V2N communication.

9. The apparatus according to claim 8, wherein the V2X message includes a first timestamp determined by the first communication station, and wherein the return version of the V2X message includes a server identifier, a second timestamp determined by the apparatus, a timestamp echo indicating the first timestamp, and a server processing time of the V2X message.

10. The apparatus according to claim 7, wherein the one or more V2X QoS measurement values include a round-trip time associated with the first communication station, an indication of latency associated with the first communication station, or an indication of V2X message loss associated with the V2X message.

11. The apparatus according to claim 7, wherein when executed by the one or more processors, the executable instructions cause the apparatus to perform the following operations: Based on the determination that the QoS target is met, store an indication to disable V2N message forwarding between the first communication station and the second communication station.

12. The apparatus according to claim 7, wherein when executed by the one or more processors, the executable instructions cause the apparatus to perform the following operations: Receive an indication of one-way latency between a first communication station and a second communication station from the first communication station; Receive an indication of direction loss between a first communication station and a second communication station from the first communication station; And Receive a round-trip time between a first communication station and a second communication station from the first communication station.

13. One or more computer-readable media, including executable instructions that, when executed, cause an apparatus to perform the following operations: Receive a vehicle-to-everything V2X message from a first communication station via vehicle-to-network V2N communication; Determine one or more V2X quality of service QoS measurement values based on the V2X message, wherein the V2X QoS measurement values include measurements based on a vehicle-to-vehicle V2V link; Determine whether a QoS target is met for a V2V link between a first communication station and a second communication station based on the V2X QoS measurement value; When the QoS target is not met for the V2V link, store an indication to enable V2N message forwarding between the first communication station and the second communication station; Determine at least one communication station for forwarding V2X messages based on at least one of V2N message forwarding information or V2X QoS information; Generate a forwarded version of the V2X message, the forwarded version including the one or more V2X QoS measurement values; Send the forwarded version of the V2X message to the at least one communication station via V2N communication.

Images