System and a method for increasing network efficiency in a 5G-V2X network

Provided is a method and system for controlling data transmission in a 5G-V2X network. The 5G-V2X network has at least one defined geographical area including a plurality of traffic sensing devices (TSDs). Each of the TSDs is configured to provide data over one or more 5G channels to a V2X processing system via an edge gateway module (EGW) of the defined geographical area. The EGW includes a transmission controller (TC). The method comprises the TC dynamically adjusting a data transmission frequency of at least one TSD of the plurality of TSDs in accordance with a transmission control policy.

FIELD OF THE INVENTION

The invention relates to a system and a method for increasing network efficiency in a 5G-V2X network and, particularly, but not exclusively, to a system and method for improving road safety and/or management in a 5G-V2X network.

BACKGROUND OF THE INVENTION

Vehicle-to-Everything (V2X) is a vehicular communication system configured to deliver information from a vehicle to any entity that may affect the vehicle, and vice versa. The system incorporates other more specific types of communications including, but not limited to, Vehicle-to-Infrastructure (V2I), Vehicle-to-Vehicle (V2V), Vehicle-to-Pedestrian (V2P), Vehicle-to-Device (V2D), and Vehicle-to-Grid (V2G).

In a V2X system with smart mobility roadside infrastructure comprising roadside units (RSUs) including traffic sensing devices (TSDs) such as, for example, lidar, radar, camera, etc., the RSUs and TSDs send their collected data through one or more 5G channels to a 5G-V2X central data processing platform or an edge V2X processing platform such as an edge gateway module (EGW). The roadside infrastructure collects all sensor data, i.e., traffic data, for processing at the EGW to discover, determine and/or calculate useful information to send through the V2X network to the road users; more particularly, but not exclusively to vehicle users. Such useful information may include traffic alerts, possible dangerous traffic situation warnings, suggestions for road users to make better and/or safer decisions, etc. The deployed RSUs and TSDs will typically collect and/or generate large amounts of data which may consume a significant portion of the 5G-V2X communication channel resources potentially resulting in one or more of network congestion, data transmission delays, slow provision of services in the 5G-V2X network. In some cases, it is impossible, or at least impracticable, to transmit all RSU and/or TSD data through the one or more 5G channels of the 5G-V2X network.

US20210099976A1 discloses an edge network infrastructure (e.g., an RSU, a RAN node or a collocated MEC server/host) for determining a required amount of spectrum (such as Long-Term Evolution Cellular V2X (LTE-CV2X), Dedicated Short-Range Communications (DSRC)/Intelligent Transport Systems-G5 (ITS-G5)) for each vehicular communication system based on detecting the number of vehicle User Equipments (vUEs) using each type of vehicular communication technology during a service period. It discloses dynamically assigning a preferred channel allocation and forwarding the allocation to neighboring infrastructure (e.g., one or more RSUs) to reconfigure themselves to provide the related services for the vUEs.

CN112822656A discloses a vehicle-mounted V2X intelligent terminal supporting 5G communication which consists of a 5G/V2X on-board unit (OBU) and a vehicle-mounted sensing system. The vehicle-mounted terminal is designed to provide longer communication distance and higher reliability compared with the DSRC, and to have a lower time delay and larger data transmission capacity in the V2X cloud network compared with the LTE-V2X communication system.

CN112055330A discloses a 5G-based V2X vehicle networking safety communication system which comprises a cloud end, a vehicle end, a roadside end and a pedestrian end. It provides password service function and secure storage function based on a safety module for the communication among each end.

U.S. Pat. No. 10,873,876B2 discloses a communication assurance system that guarantees that valuable information in each V2X wireless message is reliably delivered, even in scenarios where the V2X communication channels are congested. It calculates a series of per-attribute value scores for the piece of information based on the factor data of the piece of information and the context data of the receiver and integrates them to an aggregate value score as the value of the piece of information with respect to the endpoint.

CN109314841A discloses improved quality of service (QoS) support for sending vehicle data via a sidelinks (SL) interface. The application layer generates the vehicle data. The vehicle data are forwarded together with priority indication data and one or more QoS parameters via the SL interface to the transport layer. The transport layer sends the vehicle data based on the received priority indication data and the one or more of QoS parameters to one or more receiving devices via the SL interface according to Autonomous Radio resource allocation.

U.S. Pat. No. 10,992,589B2 discloses an apparatus for configuring a UE to assist in mitigating network congestion. It includes a first parameter that indicates an expiration of the data packet and a second parameter that indicates a transmission classification of the data packet. Determining whether a data packet has expired is based on the first parameter and adjusting transmission of the data packet is based on the second parameter, which includes congestion thresholds for determining whether to drop the data packet or to transmit the data packet based on a congestion level.

CN108182817A discloses a trackside end auxiliary system and a vehicle-mounted end auxiliary system to address the problem that environmental information around the vehicle cannot be obtained comprehensively and accurately. The focus here is on the data transmission from RSUs to vehicles.

U.S. Pat. No. 10,212,102B2 discloses an apparatus for storing message and path switching between SL and uplink (UL) for V2X message transmission. It provides a method which includes storing V2X data not transmitted yet on an old path (SL or UL) in a transmission buffer, identifying if data from a SL V2X channel (SVCH) is included in the stored V2X data, re-submitting the stored data to a lower layer of a new path (UL or SL) and transmitting the V2X data based on logical channel prioritization (LCP) procedure to a target of the new path by the path switching layer of the UE which is located right above a packet data convergence protocol (PDCP) layer of the LE.

U.S. Pat. No. 10,992,752B2 discloses sensor deployment mechanisms for road surveillance. The deployment mechanisms minimize the number of required sensors to reduce costs and conserve computing and network resources.

U.S. Pat. No. 10,403,135B2 discloses a reconfigurable roadside network (sensors, CPUs, antennas and communication backbone) that optimizes cooperative automated driving using key performance indicators (KPIs). CPUs will determine the traffic scenario based on measurement data from one or more sensors. The identified traffic scenario may then be used to determine a set of target KPI values. The current KPI values are optimized, and the roadside network is reconfigured based on the identified KPI values.

The related art mostly focuses on safety and efficiency of communication from end-to-end (V2I, V2V, etc.) by physically changing the range of the sensors and communication antennas within a sector or logically changing the mapping of sensors and antennas to CPUs.

To make sure the V2X network's service quality and road safety are not significantly influenced, there is a need to dynamically adjust the transmission frequency of data that are transferred to the V2X system via the one or more 5G channels based on feedback data generated by an edge computing apparatus or system.

OBJECTS OF THE INVENTION

An object of the invention is to mitigate or obviate to some degree one or more problems associated with known systems and methods of improving or increasing network efficiency in a 5G-V2X network.

The above object is met by the combination of features of the main claims; the sub-claims disclose further advantageous embodiments of the invention.

Another object of the invention is to provide a system and method of improving vehicular road safety and/or management of vehicles.

Another object of the invention is to provide a 5G-V2X vehicular communication system based on a defined local geographical area for increasing network efficiency.

Another object of the invention is to provide a multi-tiered system and method for improving road safety and/or management of a vehicle where a local level tier of the multi-tiered system uses edge computing apparatuses or systems to generate feedback data for adjusting the transmission frequency of data of TSDs.

One skilled in the art will derive from the following description other objects of the invention. Therefore, the foregoing statements of object are not exhaustive and serve merely to illustrate some of the many objects of the present invention.

SUMMARY OF THE INVENTION

The present invention relates to traffic data communication in a 5G-V2X network.

The present invention provides an end-to-end V2X network system having a multi-tier system architecture which utilizes information and algorithms performed at a local level tier of the multi-tiered system to generate feedback data for adjusting the transmission frequency of data of at least one TSD.

In particular, the invention proposes a mechanism for dynamically adjusting the transmission frequency of traffic data which is transferred to the 5G-V2X platform via one or more 5G channels based on feedback generated by edge computing nodes such as edge gateway modules (EGW).

The invention concerns a method and system for controlling data transmission in a 5G-V2X network. The 5G-V2X network comprises at least one defined geographical area including a plurality of TSDs. Each of the TSDs is configured to provide data over one or more 5G channels to a V2X processing system comprising a transmission controller (TC) at or through an edge gateway module (EGW) of the defined geographical area. The method comprises the TC dynamically adjusting a data transmission frequency of at least one TSD of said plurality of TSDs in accordance with a transmission control policy. Dynamically adjusting a data transmission frequency of at least one TSD may include restricting the frequency of traffic data transmission by said TSD or increasing the frequency of traffic data transmission by said TSD depending on feedback generated by the TC. The TC may be co-located with the EGW, form part of the EGW, or may comprise a standalone device or apparatus communicatively connected to the ECM by the 5G-V2X network.

In a first main aspect, the invention provides a method of controlling traffic data transmission in a 5G-V2X network. The method comprises provisioning a plurality of TSDs within at least one defined geographical area of the 5G-V2X network, provisioning an EGW for said at least one defined geographical area to be in communication with said plurality of TSDs over one or more 5G channels of said 5G-V2X network, and provisioning each of said TSDs to provide traffic data over said one or more 5G channels to a TC at or via said EGW. The TC dynamically adjusts a traffic data transmission frequency of at least one TSD in accordance with a transmission control policy.

In a second main aspect, the invention provides a system for controlling traffic data transmission in a 5G-V2X network. The system comprises a plurality of TSDs located within at least one defined geographical area and an EGW in communication with said plurality of TSDs over one or more 5G channels of said 5G-V2X network. Each of the TSDs is configured to provide traffic data over said one or more 5G channels to a TC via said EGW or located at said EGW. The TC is configured to dynamically adjust a traffic data transmission frequency of at least one TSD in accordance with a transmission control policy.

In a third main aspect, the invention provides a TC for controlling traffic data transmission in a 5G-V2X network. The TC comprises an empirical analyzer module for processing historical traffic data received from some or all of a plurality of TSDs located within a defined geographical area of said 5G-V2X network. The empirical analyzer module is configured to process said historical traffic data to determine or predict an initial transmission control policy for said plurality of TSDs. The TC includes a real-time analyzer module configured to process real-time traffic data received from some or all of the plurality of TSDs to adjust the initial transmission control policy to provide a dynamic transmission control policy for the plurality of TSDs. The real-time analyzer module is configured to control transmission restriction modules (TRMs) associated with said plurality of TSDs to apply a respective transmission policy for each of said plurality of TSDs.

The summary of the invention does not necessarily disclose all the features essential for defining the invention; the invention may reside in a sub-combination of the disclosed features.

DESCRIPTION OF PREFERRED EMBODIMENTS

The following description is of preferred embodiments by way of example only and without limitation to the combination of features necessary for carrying the invention into effect.

It should be understood that the elements shown in the FIGS. may be implemented in various forms of hardware, software or combinations thereof. These elements may be implemented in a combination of hardware and software on one or more appropriately programmed general-purpose devices, which may include a processor, memory and input/output interfaces.

The present description illustrates the principles of the present invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope.

Thus, for example, it will be appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of systems and devices embodying the principles of the invention.

In the following description a reference to an “alarm” such be taken as a reference to an “alert” and vice-versa.

Referring toFIG.1, provided is a schematic diagram illustrating one embodiment of a system100in which the AAMS400(FIG.11) may be implemented, although it will be understood that the AAMS400may be implemented in any suitable road management systems including V2X based road management systems. The system100is preferably a communications network-based system100arranged as a plurality of defined local geographical areas110A, B, each defined local geographical area110A, B being managed by and/or in data communication with a respective edge gateway module (EGW)120. Each EGW120communicates with a respective NCE160and each NCE communicates with a central management platform170.

The defined local geographical areas110A, B may overlap as shown in although this is not necessarily the case and it is preferred that any overlaps between adjacent defined local geographical areas110A, B are arranged to be as small as possible. Each EGW120preferably manages and is in communication with a plurality of roadside units (RSUs)130. Each RSU130is preferably arranged alongside, adjacent or near to any one or more of a road, an intersection, a junction, a pedestrian crossing, a set of traffic lights, etc. such that each RSU has a reasonable line of sight to any vehicles located in or passing its near vicinity.

Vehicles140which are configured to operate within the network system100are each provisioned with a vehicle on-board data processing unit—hereinafter referred to as an in-car gateway module (ICGW)150. The ICGW150may be a stand-alone unit configured to be installable into a vehicle140or it may comprise an existing data processing unit of the vehicle140having a memory152storing machine-readable instructions and a processor154for executing said instructions to cause the ICGW150to implement appropriate method steps. The ICGW150may comprise a V2X on-board unit (V2X-OBU). Each EGW120comprises at least a memory122for storing machine-readable instructions and a processor124for executing said instructions to cause the EGW120to implement appropriate method steps. In a similar manner, each RSU130comprises at least a memory132for storing machine-readable instructions and a processor134for executing said instructions to cause the RSU130to implement appropriate method steps.

Among other things, each ICGW150is preferably configured to provide V2X communication system access and information exchange with other ICGWs150and road infrastructure in the defined local geographical area110A, B, to collect data from the vehicle on-board modules such as, for example, the speedometer and satellite positioning system, directly or indirectly exchange vehicle collected data with other local ICGWs150, RSUs130and its respective EGW120, use the vehicle collected data and data received from other local ICGWs150, RSUs130and EGW120to determine threats and generate alarms, etc., and receive and issue V2X alarms (alerts) and notifications as well as receive traffic status information and recommendations.

Each EGW120is preferably configured to at least coordinate multiple RSUs130within its respective defined local geographical area110A, B, monitor traffic in real-time including monitoring traffic congestion and traffic incidents such as accidents, intelligently implement local traffic management, collect data from local infrastructure such as, for example, traffic lights, sensors, cameras, local ICGWs150and RSUs130and its respective NCE160, collect policies from its respective NCE160, and to use collected data to determine threats and generate alarms, etc. Each EGW120may be configured to determine from received and processed data specific data to be transmitted to a specific ICGW150in dependence on data received at said EGW120indicative of one or more parameters related to or associated with a vehicle of said specific ICGW150. For example, a parameter such a street location may be utilized by the EGW120to determine which vehicles within its local geographical area110A, B need to receive a specific alert, alarm, action or indication of threat.

A plurality of EGWs120are preferably managed by and/or in data communication with a respective NCE160and, in turn, a plurality of NCEs160are preferably managed by and/or in data communication with a central management platform module170. The system100may comprise only a single central management platform module170to cover a large geographical region such as, for example a city, a county or a state. Each NCE160comprises at least a memory162for storing machine-readable instructions and a processor164for executing said instructions to cause the NCE160to implement appropriate method steps. Similarly, the central management platform module170comprises at least a memory172for storing machine-readable instructions and a processor174for executing said instructions to cause the central management platform module170to implement appropriate method steps.

Each NCE160is preferably configured to at least intelligently implement regional traffic management, define and provide new and updated traffic policies to the EGWs120, and coordinate multiple EGWs120.

The central management platform module170is preferably configured to at least intelligently implement whole network traffic management, define traffic strategies for the NCEs160and manage and analyze network wide traffic data. The central management platform module170may comprise a cloud-based system and may connect to the NCEs160via an IP network such as the internet (FIG.6) or a virtual private network (VPN).

It will be appreciated that the processing power of the central management platform module170will likely be very considerably greater than the processing power of any of the NCE160, EGW120, RSU130or ICGW150. Despite this, it is envisaged that the central management platform module170will operate on high latency data and/or on long data processing periods to provide information related to, for example, road/traffic strategy and planning rather than time critical generation of alerts, determination of actions and/or determination of threats as will be performed at the local EGW120and RSU130levels.

For enhancing safety alarm generation and/or threat detection accuracy for vehicles, multiple sources of information such as vehicles, pedestrian devices, roadside infrastructure. and communications network(s), etc. are required at low latency signal processing and delivery levels.

The network system100comprises a V2X system which preferably utilizes all local available sources of data including, but not limited to vehicle ICGWs150, pedestrian devices180(FIG.2), road infrastructure systems and devices190(FIG.2) such as traffic lights, traffic cameras, emergency services databases, local authority databases and the like by way of informing EGWs, preferably in real-time, or at least at ultra-low latency, of events, situations or the like which may be relevant to enabling an EGW120, a RSU130and/or a ICGW150to determine a threat to a vehicle140or another road user and/or to generate an alarm to a vehicle user or another road user.

As shown more clearly inFIG.2, each ICGW150may utilize one or more standard. communications interfaces to communicate with other network entities. For example, the ICGW150may utilize V2V to exchange data with other ICGWs150and/or utilize V2P to exchange data with pedestrian devices180and/or utilize V2I to exchange data with local infrastructure including the RSUs130. The RSUs130and EGWs120preferably use V2N to exchange data with each other and higher-level network entities such as the NCEs160and the central management platform170as will be more fully explained hereinafter. Where appropriate, entities in the network system100may also utilize V2D and V2G. As such, as illustrated byFIG.2, an end-to-end V2X network system100having a multi-tier system architecture which utilizes information and algorithms performed at different tiers of the V2X network system to enable low latency generation of vehicle/road safety alarms and/or low latency determination of vehicle/road threats.

In the V2X network system100, the EGWs120and/or RSUs130are configured to process local, real-time and/or low latency data to assist or provide alarms and/or determine threats to road users. The EGWs120and/or RSUs130will operate on data having a latency of 100 ms or less and preferably 50 ms or less. A low latency is regarded as comprising a data processing and delivery time in the range of 10 ms to 100 ms.

By confining processing of local real-time and/or low latency data to respective EGWs120and/or RSUs130on behalf of or in conjunction with ICGWs150and/or user devices180, this enables the system100to provide or enable time-critical alarm generation and/or threat determination at the local level without the delays inherent of processing such data at higher level entities in the network system100. A size of the defined geographical area110A, B is selected such as to enable data from said one or more RSUs130and/or from a respective EGW120to be transmitted to said ICGWs150in real-time or at least at or less than a first, low level of latency.

In one embodiment, the V2X network system100provides a communications channel for at least providing additional data to ICGWs150to use in addition to on-vehicle data to generate alarms, to determine threats and/or to determine control actions for the vehicle to be implemented manually or autonomously. The V2X channel provided by the network system100is an efficient method of getting time-critical data to ICGWs150from local external sources that may affect the vehicle and vice versa.

The multi-tiered arrangement of the network system100is more clearly seen fromFIG.3. A first tier can be considered as comprising any vehicles140with their associated ICGWs150within a geographical area of an EGW120, any other road users such as pedestrians and their associated devices180(FIG.2), street level infrastructure such as smart traffic lights, camera systems, etc. and the RSUs130. A second tier of the network system100comprises the EGWs120. The first-tier entities are linked to the second-tier entities by what can be considered as a local V2X network102where data communications are exchanged using V2I, V2P and V2V. A third tier of the network system100can be considered as comprising the NCEs160and these are linked to the second-tier entities by what can be considered as a regional V2X network103operating over V2I. A fourth tier comprises the central management platform170which communicates using V2I over a city-wide, county-wide or state-wide V2X network104.

The first and second tier entities preferably operate at signal latencies of 100 ms or less and preferably at signal latencies of 50 ms or less. The third-tier entities preferably operate at signal latencies of 1000 ms or less whereas the fourth-tier entity operates at latencies of greater than 1000 ms and nearer to several seconds to minutes and even longer time periods. Consequently, the system100generally relates to a multi-tier V2X network architecture or software system to enable low latency road safety V2X alarm detection/threat determination at a local level whilst using information and algorithms performed at different higher-level tiers of the system operating at different, higher latency levels.

FIG.4illustrates the structure of an EGW120and its connections to other system entities and some of its information/data inputs. The EGW120comprises a database or data pool121, an area analysis engine module (AAE)122, an artificial intelligence (AI) planning engine module123, a policy gateway module124and an RSU and vehicle management module125. Data connectors may include a data connector126to one or more RSUs130, a data connector127to an NCE160and optional data connectors128,129to the central management platform170and an external service provider. Data inputs to the AAE122may include map data, real-time incident handling data, real-time road status analysis data, dangerous location identification data, and vehicle speed-up opportunity data.

The AI and planning engine module123is a software module within the EGW120configured to aggregate all data generated in the defined geographical area110A, B of the EGW120and process said data using machine learning. The AAE122is a software module within the EGW120configured to process data generated in the defined geographical area110A, B to determine any one or more of: real-time status of all roads in the defined geographical area; real-time status of all resources in the defined geographical area; real-time status of all RSUs130in the defined geographical area; real-time status of all ICGWs150in the defined geographical area; and real-time status of all incidents in the defined geographical area. The policy gateway module124is a software module within the EGW120configured to receive and configure rules and policies from the NCE160or from the central management platform170, and to receive policy information from a local service using open standard Application Programming Interface (API). For example, local shops could send current retail and promotion information to broadcast to vehicles as low priority promotional information. The RSU and vehicle management module125is a software module within the EGW120configured to communicate data to the RSUs130and ICGWs150including real-time status information as described above and to configure at least the RSUs130in accordance with any policies received by the EGW120.

FIG.5illustrates the structure of an NCE160and its connections to other system entities and some of its information/data inputs. The NCE160comprises a database or data pool161, a cooperation engine module162, an artificial intelligence (AI) planning engine module163, a large area policy gateway module164and an EGW and area statistics management module165. Data connectors may include a data connector166to one or more EGWs120, a data connector167to the central management platform170and optional data connector168to a large area external service provider. Data inputs may include EGW relationship data which describes the relationship such as relative positions of one EGW to another, cross ECM trajectory correction data, cross area event handling data, traffic balancing data, reduce unexpected event influence data, and large area road status analysis data.

Each EGW120managed by the NCE160is configured to communicate its local data for aggregation and extraction by the NCE160where the NCE160processes the aggregated and extracted data to provide one or more of: road management policy for the EGW defined geographical areas; regional traffic management for the EGW defined geographical areas; and coordinate and manage said plurality of EGWs. The cooperation engine module162is a software module within the NCE160configured to receive the data inputs and to process the EGW relationship data, the cross EGW trajectory correction data, the cross-area event handling data, traffic balancing data, and the reduce unexpected event influence data. It may also process the large area road status analysis data. The artificial intelligence (AI) planning engine module163is a software module within the NCE160configured to take all data uploaded from the EGWs120into the data pool161and to apply machine learning to such data. The machine learning may comprise supervised learning and may be done off-line. One output of the artificial intelligence (AI) planning engine module163includes policies, formulas and rules for the cooperation engine module162to apply. The artificial intelligence (AI) planning engine module163may also be configured to try and determine any relationships between any of the EGWs120to assist the cooperation engine module162to determine an area or region influenced or affected by, for example, a traffic incident. It will be understood that traffic congestion, for example, in one defined geographical area110A, B will likely have greater influence or effect on an adjacent local area110A, B than it would have on a more remote area. The large area policy gateway module164is a software module within the NCE160configured to receive configuration/rules/policies data from the V2X central management platform170and may also be configured to receive policy data from a large area service provider through an open standard API. The EGW and area statistics management module165is a software module within the NCE160configured to receive data from the cooperation engine module162and transmit such data to respective EGWs120.

FIG.6illustrates the structure of the central management platform170and its connections to other system entities and some of its information/data inputs. The central management platform module170is in direct communication with a plurality of NCEs160and indirectly in communication with a plurality of EGWs120. The central management platform module170comprises a planning/strategy configuration module171, a wide area V2X data analysis module172and a report system module173. The modules171,172and173comprise software modules within the central management platform module170. The central management platform module170aggregates and extracts data from the NCEs160and the EGWs120and processes the aggregated and extracted data to provide one or more of: road management policy for the defined geographical areas110A, B of the EGWs120; regional traffic management across NCB160for the defined geographical areas110A, B of the EGWs120; directly coordinate said plurality of NCEs160and indirectly coordinate said plurality of EGWs120; provide centralized management of the NCEs160, EGWs120and RSUs130; provide centralized management of the plurality of data sources located within each defined geographical area110A, B; provide centralized vehicle to everything (V2X) network management; provide traffic analysis for the defined geographical areas110A, B; and provide regional traffic analysis for the NCEs160.

Referring toFIG.7, provided is a flow diagram of the information flows and processes performed by an EGW120. At201, statistical data from the ICGWs150of all vehicles140located within the geographical area110A, B of the EGW120together with, at202, any incident report data from such ICGWs150are transmitted by V2I through a respective RSU130to the RSU data connector126of the EGW120. At203, data collected by a respective RSU130from associated data sources within the geographical area110A, B are transmitted to the data connector126of the EGW120together with, at204, any incident data detected by sensors of the RSU130. At205, data received at the data connector126is aggregated and stored in the data pool121. Some or all of the aggregated data are passed to the AAE122which performs a few functions including, at206, updating the real-time statuses of all in-area entities. If, at207, the updating step206identifies or detects an emergency incident, data describing the incident are forwarded to208to determine, for example, if there is a need to generate an alarm. In the event that it is determined at208that there is a need to generate an alarm, a further determination may be made at209as to whether or not it is necessary for the alarm to be considered a high priority alarm. In either case, alarm data are communicated via respective RSUs130to target vehicles140. It will be understood that this is done in real-time or at least with very low latency of less than 100 ms. Furthermore, if at208it is determined that there is a need to generate an alarm, the method may include at210determining whether or not to generate guidance data or even action data for vehicles140. This may include at211determining guidance data or action data for specific vehicles140in the geographical area110A, B. Such guidance data or action data are communicated via respective RSUs130to target vehicles140. Action data may comprise data which causes a target vehicle140to autonomously act without human involvement. For example, action data may cause a target vehicle to autonomously slow prior to reaching a pedestrian crossing if pedestrians have been sensed as being on or near the crossing and, more particularly, where pedestrians have been sensed as being on or near the crossing in vulnerable positions.

In addition to determining or detecting at207an emergency incident, the AAE122may be configured to calculate at212useful statistics such as traffic statistics and may include determining at213useful statistics to be transmitted to one or more NCEs160. The statistical data generated at212may in turn be used at214to calculate a traffic pass time for each road in the geographical area110A, B, at215to calculate potential congestion times, and at216calculate other meaningful statistics or parameters for the traffic situation in the geographical area110A, B. The data generated at each or any of214,215and216may also be used generate alarms and/or guidance/actions for targeted vehicles140. Guidance data and/or action data may also be communicated target vehicles140via other vehicles using V2V.

Referring toFIG.8, provided is a flow diagram of the information flows and processes performed by an NCE160. At301, each EGW reports statistical data including, but not limited to, status report data, incident report data and congestion report data and transmits said data to its NCE data connector/interface127(NCE EGW data connector166). At302, said data is aggregated and stored in the NCE data pool161. Some or all of said aggregated data are forwarded to the cooperation engine module162, although, in an optional step at303, said data may be filtered and corrected. Furthermore, map data may be input at304. At305optional data inputs to the cooperation engine module162may include AI suggested inputs from any one of the EGW artificial intelligence (AI) planning engine module123, the NCE artificial intelligence (AI) planning engine module163, the central management platform planning/strategy configuration module171, the wide area V2X data analysis module172or the report system module173. At306, optional data inputs to the cooperation engine module162may include manually defined relationship data such as, for example, the spatial relationships between EGWs120and their respective geographical areas110A, B.

At307, the cooperation engine module162receives multi-EGW status data from the EGW data pools121. Based on this data and optionally on EGW relationship data received at308, the cooperation engine module162may determine at309if any emergency incident has been detected and, if so, to define at310the area or areas and corresponding EGWs120affected by the incident and to define actions and/or alarms to trigger for each affected EGW120. The actions and/or alarms may comprise, although are not limited to:312“send an alarm”;313“generate guide to reduce congestion”;314“reduce unexpected incident's influence”; and315“other commands to vehicles”. Once the actions and/or alarms are determined, these are issued to affected EGWs120via the EGW data connector/interface166.

The cooperation engine module162may also use the multi-EGW status data and optionally the EGW relationship data to estimate any one or more of316each EGW area's pass time,317each EGW area's estimated potential congestion, and318other meaningful statistical data. The EGW area's pass time and EGW area's estimated potential congestion can be used at319to determine if congestion is detected and to use this data to define at310the area or areas and corresponding EGWs120affected by the incident and to define actions and/or alarms to trigger for each affected EGW120. The other meaningful statistical data can be used at320to determine any other detected incident and to also use this data to define at310the area or areas and corresponding EGWs120affected by the incident and to define actions and/or alarms to trigger for each affected EGW120.

In the following description, the AAMS400will be described as being implemented in the system100ofFIGS.1to8and like numerals will be used to denote like parts. However, it will be understood that the AAMS400may be implemented in any suitable road management system.

Referring toFIG.9, shown is an intersection330of a first carriageway (road)335with a second carriageway338. However, in this example, the two carriageways335,338do not physically intersect and form a junction because the first carriageway335is elevated and crosses over the second passageway338such that traffic on the first carriageway335does not directly impede traffic on the second carriageway338or vice-versa. In contrast, in a scenario where the first and second carriageways335,338do physically intersect to form a junction (not shown), it would be necessary to have traffic control devices such as traffic lights at the junction of the two carriageways335,338to control traffic flows.

In the example scenario ofFIG.9, a first vehicle336in box A on the first carriageway335may detect the presence of another vehicle339in box13on the second carriageway338and issue an alert to the driver of the first vehicle336to be aware of the near proximity of the second vehicle339. However, it will be understood that such an alert would be redundant as the detected proximity of the first and second vehicles336,339is not relevant from a traffic management/safety point of view as there is no possibility of the first and second vehicles336,339colliding, for example. The alert would therefore constitute a false alert to the driver of the first vehicle336. A probability of such a false alert being issued may be higher in the case where the first vehicle336has entered the defined geographical area containing the cross-over intersection330of the first and second carriageways335,338for the first time and particularly if the first vehicle336does not have or has not yet received updated map data and/or static environmental data and/or sensor data for the defined geographical area or at least the area surrounding the cross-over intersection330. In this example scenario, the first vehicle336has limited data by which to process the detected near proximity of the second vehicle339and to determine if an alert needs to be issued to the driver. Furthermore, in this example scenario, other vehicles (not shown) not having relevant map data and/or static environmental data and/or sensor data may also issue intersection alerts not only to their respective drivers but to the system100entities such as the RSUs130and EGWs120. The generation by vehicles of such false alerts is undesirable for many reasons.

In the example scenario ofFIG.10, a first vehicle350is travelling around a curved part of a carriageway352or around a roundabout and, as it does so, it detects near proximity of a roadside object or obstacle354in one of the vehicle's blind spots and falsely identifies the object or obstacle354as another vehicle and issues, in this example scenario, a left-side blind spot alert to the vehicle driver. Once again, in this example scenario, it can be seen that the issued alert is a false alert, issuance of which could have been prevented or at least at a reduced occurrence of such false alerts if vehicles had received relevant map data and/or static environmental data and/or sensor data indicating the presence of the object or obstacle354.

The AAMS400is configured to receive vehicle generated alerts and to use any of relevant map data and/or static environmental data and/or sensor data to determine if a vehicle generated alert is a false alert and to then communicate data about or related to the false alert to other vehicles140and user devices180via RSU130in the system100so as to reduce or even prevent similar such false alerts being issued thereafter.

Referring now toFIG.11, shown is a block diagram of the AAMS400and its connections to some of the other entities130,190in the system100. The black box surrounding the AAMS400can be considered as defining the defined geographical area110containing the at least one RSU130but it will be understood that the diagram is not to scale and that the defined geographical area110could be much larger than shown and containing within it a plurality of RSUs130, a plurality of roadside sensors190such as road infrastructure systems and devices and at least one EGW (not shown).

The AAMS400comprises a map data unit405comprising map data for the defined geographical area110or at least the area surrounding the at least one RSU130. The AAMS400is shown connected to the at least one RSU130, although it will be understood that the AAMS400may comprise a part of the EGW120and may be implemented through machine code stored in the memory122and executable by the processor124of the EGW120. In other embodiments, the AAMS400may comprise a stand-alone apparatus communicatively connected to the RSU130via, for example, the V2X network102,103,104and communicatively connected to one or more of the roadside sensors190. Preferably therefore the AAMS400has a communication unit410for managing communications between the AAMS400and the system entities such as the RSUs130and roadside sensors190. The AAMS400also has an alert analysis unit415configured to receive vehicle generated alerts. The AAMS400preferably includes a static environment data unit420comprising static environmental data for the defined geographical area110or at least the area surrounding the at least one RSU130.

It will be understood that all or any of the units comprising the AAMS400can be implemented by machine code stored in a memory device and executable by a processor.

In a first method, the alert analysis unit415, upon receiving a vehicle generated alert, processes the received vehicle generated alert to determine if the alert is a false alert. The alert analysis unit415is configured to use a location associated with the vehicle generated alert to obtain map data from the map data unit for a defined area surrounding the vehicle generated alert location and/or use a location associated with the vehicle generated alert to obtain static environmental data for the defined area surrounding the vehicle generated alert location and/or retrieve sensor data for the defined area surrounding the vehicle generated alert location based on the location and time of the vehicle generated alert. The defined area surrounding the vehicle generated alert location may be of a predetermined size much smaller than the size of the defined geographical area110or may have a dynamically determined small size dependent on the relative locations/positions of system entities such as RSUs130and/or roadside sensors190which are deemed relevant to the generation by a vehicle of the received alert. There are a number of ways in which the size of the area surrounding the vehicle generated alert location is determined either statically or dynamically and this could include taking into account locations and/or clusters of previously determined false alerts.

In any event, the alert analysis unit415determines if the received vehicle generated alert is consistent with the obtained and/or retrieved data for the defined area surrounding the vehicle generated alert location. In the example scenario ofFIG.9, the alert analysis system415might determine a lack of consistency with relevant map data for a received vehicle generated intersection alert because the first carriageway335crosses over the second carriageway338, i.e., they do not, in fact, intersect each other at a junction. Or, in the example scenario ofFIG.10, the alert analysis system415might determine a lack of consistency with relevant static environmental data for a received vehicle generated blind spot alert because the static environmental data includes data defining the position and possibly also the type of roadside object or obstacle354. The alert analysis unit415records that the received vehicle generated alert is a false alert when it is determined that the received vehicle generated alert lacks consistency with the relevant obtained and/or retrieved data for the defined area surrounding the vehicle generated alert location. The alert analysis unit415may also employ roadside sensor data for the defined area surrounding the vehicle generated alert location either by itself or in any combination with the relevant map data and the relevant static environmental data. An example scenario may be where the received vehicle generated alert has detected a pedestrian at a road crossing or a cyclist riding a bicycle along an outside margin of a carriageway but where the relevant roadside sensor data show that the detection is in error or that the cause of the detection is no longer present, e.g., the pedestrian has exited the road crossing onto the pavement and the generated alert is a false alert.

Referring toFIG.12, illustrated are some of the data paths between the AAMS400and other system entities in the road management system100. It can be seen that the AAMS400preferably receives vehicle generated alerts via the at least one RSU130. This has at least the advantage of enabling the RSU130to process the alerts in the manner described with respect to the system100ofFIGS.1to8as well as enabling the RAMS400to process said received vehicle generated alerts to determine whether or not any of such received alerts present as false alerts. The received alerts may comprise alerts of different types denoted, by way of example, as “A”, “B” or “T” inFIG.12.FIG.12also illustrates that the roadside sensors190may communicate data to update the static environmental data managed by the static environment unit420. Furthermore, real-time sensor data or stored sensor data can be communicated to a “time-space” or a “time-location” database425which stores roadside sensor data by location and time when generated and possibly also by other parameters such as event type, etc.

Referring toFIG.13, shown is a flow diagram illustrating of another method500of reducing vehicle generated false alerts. In a first step505of the method500, the alert analysis unit415, upon receiving a vehicle generated alert, uses the location associated with the vehicle generated alert to obtain map data from the map data unit405for the defined area surrounding the vehicle generated alert location. The obtained map data may include any of properties and locations of roads, locations and types of intersections, positions and locations of traffic signals, boundaries, and the like. In a second step510, the alert analysis unit415uses the type of the received vehicle generated alert and obtains only map data from the map data unit405for the defined area surrounding the vehicle generated alert location that is related or relevant to the type of the received vehicle generated alert. In any event, in a third step515, the alert analysis unit415then determines if the received vehicle generated alert is consistent with the relevant map data for the defined area surrounding the vehicle generated alert location. If, in the third step515, the alert analysis unit415determines a lack of consistency between the received vehicle generated alert and the relevant map data, it records that the received vehicle generated alert is a false alert and generates a false alert map and/or updates the false alert map data in the map data unit405. The AAMS400may also communicate the false alert and/or the false alert map data to the at least one RSU130and/or to the one or more ICGWs150of vehicles140and/or to the one or more V2X devices180in the defined geographical area110or in the coverage area of the RSU130or in the defined area surrounding the vehicle generated alert location. The updated false alert data may comprise for any false alert any or more of: location such as global positioning system (GPS) location data; type such as, for example, intersection alert; and/or reason such as “not an intersection” for example.

If, in the third step515, the alert analysis unit415does not determine a lack of consistency between the received vehicle generated alert and the relevant map data, the method moves to a fourth step520where the alert analysis unit415obtains static environmental data for the defined area surrounding the vehicle generated alert location from the static environment data unit420. The static environmental data may comprise data defining any feature which is generally non-changing in time such as static objects and obstacles and may include, for example, long standing roadworks and the like. In a fifth step525, the alert analysis unit415uses the type of the received vehicle generated alert and obtains only static environmental data from the static environment data unit420for the defined area surrounding the vehicle generated alert location that is related or relevant to the type of the received vehicle generated alert. In any event, in a sixth step530, the alert analysis unit415then determines if the received vehicle generated alert is consistent with the relevant static environmental data for the defined area surrounding the vehicle generated alert location. If, in the sixth step530, the alert analysis unit415determines a lack of consistency between the received vehicle generated alert and the relevant static environmental data, it records that the received vehicle generated alert is a false alert and generates a false alert map and/or updates the false alert map data in the map data unit405. The AAMS400may also communicate the false alert and/or the false alert map data to the at least one RSU130and/or to the one or more ICGWs150of vehicles140and/or to the one or more user devices180in the defined geographical area110or in the coverage area of the RSU130or in the defined area surrounding the vehicle generated alert location.

If in the sixth step530, the alert analysis unit415does not determine a lack of consistency between the received vehicle generated alert and the relevant static environmental data, the method moves to a seventh step535where the alert analysis unit415retrieves roadside sensor data from one or more of the sensors190for the defined area surrounding the vehicle generated alert location based on the location and time of the vehicle generated alert. The roadside sensor data may be retrieved from the time-space database425. Such data can be processed off-line in the time-space database425and/or in the alert analysis unit415. In an eighth step540, the alert analysis unit415processes the retrieved roadside sensor data to select data relating to any combination of the location, speed, direction and type of objects in the defined area surrounding the vehicle generated alert location. The objects preferably include any other vehicles140located within the defined area surrounding the vehicle generated alert location. In any event, in a ninth step545, the alert analysis unit415then determines if the received vehicle generated alert is consistent with the retrieved sensor data. The ninth step545of the method may be based on the type of the received vehicle generated alert. If, in the ninth step545, the alert analysis unit415determines a lack of consistency between the received vehicle generated alert and the relevant sensor data, it records that the received vehicle generated alert is a false alert and generates a false alert map and/or updates the false alert map data in the map data unit405. The RAMS400may also communicate the false alert and/or the false alert map data to the at least one RSU130and/or to the one or more ICGWs150of vehicles140and/or to the one or more user devices180in the defined geographical area110or in the coverage area of the RSU130or in the defined area surrounding the vehicle generated alert location.

If in the ninth step545, the alert analysis unit415does not determine a lack of consistency between the received vehicle generated alert and the relevant sensor data, the method500outputs that the received vehicle generated alert is not a false alert.

In an enhancement of the described methods as illustrated byFIGS.14to16, it is preferred in a first step605of the enhanced method600(FIG.16) to group false alerts by alert type in respective clusters550(FIG.14) within the defined geographical area110or within another defined area within the defined geographical area110. The another defined area is smaller than the defined geographical area110and may comprise an area the same as or similar to the defined area surrounding a vehicle generated alert location. The enhanced method600may include determining a parameter for each respective cluster550of false alerts.

FIG.14illustrates a method of clustering the false alerts in accordance with the enhanced method600. InFIG.14, the dashed-line circles delimit the sizes of the respective clusters550of false alerts, the “Xes”555represent the locations of the false alerts within each cluster550and the round black spots are indicative of a determined parameter for each the clusters550of false alerts. The parameter preferably comprises a location centroid560for a respective cluster550.

The alert analysis unit415is preferably configured to group false alerts by alert type in the respective clusters550using a density-based spatial clustering of applications with noise (DBSCAN) algorithm using as input data one of more of: false alert location latitude data; false alert location longitude data; speed of vehicle associated with the false alert; direction of vehicle associated with the false alert; or road lane data of vehicle associated with the false alert. Other false alert data inputs may be included.

The alert analysis unit415is preferably configured to determine the centroid560for each respective cluster550using a K-means algorithm.

In a second step610of the enhanced method600, the alert analysis unit415is configured to determine a confidence level C for each respective cluster550of false alerts based on a correlation of geographical information R for the false alerts in each respective cluster550and a correlation of influence factors I for the false alerts in each respective cluster550.

The correlation of geographical information R for the false alerts in each respective cluster550is preferably obtained from:
R=1−Avg(L1,L2,L3, . . . LN)/Max(L1,L2,L3, . . . LN)

where N is the number of false alerts in the cluster550;

LNis the deviation or distance of each false alert from the centroid560of the cluster550; and
0<R<1.

The closer R is to 1, the higher the confidence level C. Multiple false alert locations which are close together will result in a higher value of R in the range from 0 to 1. Multiple false alert locations at a connected area with a same property such as a same carriageway lane will also result in a higher value of R in the range from 0 to 1.

InFIG.15, N=6, i.e., L1, L2, L3, L4, L5and L6comprise the respective deviations or distances of the six false alert locations respectively denoted as “X” from the centroid560of the cluster550.

The correlation of influence factors I for the false alerts in each respective cluster550is preferably obtained from:

where M is the number of the influence factors;

where N is the number of false alerts in the cluster550;

Sjis an influence factor;

The closer I is to 1, the higher the confidence level C. The greater the similarity of the influence factors S for the false alerts in each respective cluster550, the higher the value of I.

It will be understood, however, that there is no limit on the number of influence factors S which may be utilized as, the greater the number of influence factors S, the more accurate the result obtained.

For example, inFIG.15, where N=6, considering speed S1and direction S2as the only two influence factors, where S1avgis the average of the speeds (S11, S12, S13, . . . . . . , S1N) of the vehicles for the fake alerts in the cluster and S2avgis the average of the directions (S21, S22, S23, . . . . . . , S1N) of the vehicles for the false alerts in the cluster, so the correlation of influence factors I formula:

The confidence level C of each cluster550is preferably determined from C=R×Iand the alert analysis unit415is configured in a third step615of the enhanced method600to compare the confidence level C of each cluster550to a predetermined, calculated or selected threshold H such that where C>H the AAMS400will then communicate false alert related data of the respective cluster550to the at least one RSU130and/or to one or more ICGWs150of vehicles140in the defined geographical area110or in the coverage area of the RSU130or in the defined area surrounding the vehicle generated alert location to the one or more vehicle on-board data processing units of the respective cluster. In one embodiment, where C>H for a cluster550, the AAMS400will communicate false alert related data of the respective cluster550to the at least one RSU130which then broadcasts said data to the ICGWs150of vehicles140and/or to the user devices180in the defined geographical area110. Equipped with the broadcast information, the ICGWs150of the vehicles140and/or the user devices180can locally make a decision in a manner which reduces or may even prevent the occurrences of false alerts. Consequently, each ICGW150and/or the user devices180can make a decision based not only on its local awareness of the environment but also taking into account data relating to false alerts previously generated by other ICGWs and/or user devices180thereby enabling the occurrences of such false alerts to be at least reduced.

The road management system100including the AAMS400may comprise a Vehicle-to-Everything (V2X) software system. The road management system100including the AAMS400may comprise a road safety management system.

One significant advantage of the system100of the AAMS400is that, by reducing or preventing the issuance of false alerts, it considerably reduces communication bandwidth between entities within the system100and reduces the computational load on entities such as RSUs130and EGWs120.

In the following description, a system for controlling traffic data transmission in a 5G-V2X network will be described as being implemented in the embodiments of the system100ofFIGS.1to16and like numerals will be used to denote like parts. However, it will be understood that the system ofFIGS.1to16may be implemented in any suitable road management system.

Referring toFIG.17, the system700for controlling traffic data transmission in a 5G-V2X network comprises a transmission controller (TC)710. The TC710is preferably located in an edge node such as an EGW120of a defined geographical area104of the network system100, but, in some embodiments, may comprise a stand-alone device communicatively connected to the EGW120via one or more channels of the 5G-V2X network. The TC710comprises an empirical analyzer module715for processing historical traffic data to generate a transmission control policy and a real-time analyzer module720for processing real-time traffic data to adjust the transmission control policy. The TC710preferably also comprises a database725for storing traffic and associated data including historical data. Connected to the TC710are: a network monitor730which monitors, measures and/or determines operating parameters of the 5G-V2X network including measuring network delay d values; a map server735or database which provides map data to the TC710describing locations of any of RSUs130, TSDs740(referred to as “other devices” or “devices” inFIG.17), and any other roadside sensors745; and a device information interface750which inputs traffic data received over one or more 5G channels from at least the TSDs740to at least the empirical analyzer module715.

A data processor755is also preferably provided in communication with the TC710. The data processor755may form part of the EGW120or may comprise a stand-alone device. The data processor755is configured to receive raw data from a plurality of roadside based transmission control modules (TRMs)760of the defined geographical area104and to process said raw data to provide structured traffic data to the TC710. The raw data may be transmitted as point clouds and/or images which requires more bandwidth to transmit and more computational capacity to process compared to processed structured data. The structured traffic data may include any one or more of: speed of moving traffic objects detected by each of the plurality of TSDs; location of each detected moving traffic object; timestamp for each detected moving traffic object; number of detected traffic alerts; location of each detected traffic alert; timestamp for each detected traffic alert; number of detected traffic accidents; location of each detected traffic accident; and timestamp for each detected traffic accident. One advantage of this arrangement is that more efficient use is made of the system's computational capacity in that the raw data is processed by the data processor755rather than by processors provided at, for example, RSUs130. Processing raw data such as point clouds and/or images requires considerable computational capacity. Distributing such computational capacity to RSUs130or the like would be wasteful of such resources particularly with respect to periods of low traffic data flows and may not be capable of processing the raw data in periods of high traffic data flows such as traffic rush hours.

The TRMs760collect traffic data from the TSDs740in accordance with the transmission control policy generated by the TC710. The TRMs760communicate the received traffic data from the TSDs740as raw data via one or more 5G channels to the EGW120incorporating the TC710also in accordance with the transmission control policy. The TRMs760communicate the received traffic data to the data processor755, if present, or directly to the TC710in the EGW120if no dedicated traffic data processor755is present.

The TC710functions to dynamically adjust a traffic data transmission frequency of one or more of said TSDs740in accordance with the transmission control policy by communication said transmission control policy to the TRMs760. The transmission control policy generated by the TC710comprises a transmission policy for each respective TSD760by which means the TRMs760dynamically adjust the traffic data transmission frequency of each TSD740in accordance with each TSD's respective transmission policy. The TC710may communicate the transmission control policy to the TRMs760by way of policy commands.

As illustrated inFIG.18, a TRM760A may be configured to apply the transmission control policy to a single associated TSD740A. The TRM760A may be located near to or in combination with the TSD740A and apply to said TSD740A the respective transmission policy for that TSD740A provided by the transmission control policy generated by the TC710. In some embodiments where a plurality of TSDs740B (inFIG.18) are arranged within the defined geographical area104in close proximity to one another such as all being at or near, for example, a traffic junction, the TSDs740B may be formed as a group and serviced by a single TRM760B. The single TRM760B is configured to apply to each TSD740B of the grouped TSDs740B its respective transmission policy provided by the transmission control policy generated by the TC710. In a similar manner, the grouped TSDs740C ofFIG.18are also served by a single TRM760C, but the group of TSDs740C in this example is fewer in number than the group of TSDs740B. Grouping TSDs740in this manner reduces the number of TRMs760required for the defined geographical area104.

FIG.19illustrates comparative complexities of local areas, denoted respectively by dashed line circles800A and800B, within the defined geographical area104surveilled by respective TSDs740′,740″.

In the case of local area800A, denoted as “Area 1”, it can be seen that the TSD740′ is monitoring a junction between a first carriageway805and a second carriageway806. In this example, a first vehicle8104, denoted as “Car1”, is approaching the junction along the first carriageway805and a second vehicle810B, denoted as “Car2”, is approaching the junction along the second carriageway806. It will be understood that a junction between carriageways is a much more likely location for traffic problems including accidents than, for example, a straight section of carriageway. There is a greater likelihood for the first and second vehicles810A, B to cause interference to each other at the junction thereby possibly giving rise to the issuance of one or more traffic alerts than would be the case if such vehicles810A, B were travelling towards each other on, for example, opposing lanes of the straight section of carriageway. There is also the likelihood at the junction of the carriageways805,806of the first and second vehicles810A, B encountering pedestrians attempting to cross the carriageways805,806which could give rise to other traffic alerts or the like.

By way of comparison, in the case of local area800B, denoted as “Area 2”, it can be seen that the TSD740″ is monitoring a straight section of the first carriageway805. In this example, only a single vehicle810C is travelling along one lane of the straight section of carriageway805away from the junction. There is a much lower likelihood in this scenario of events leading to a need to issue a traffic alert.

It will be appreciated from the comparison of scenarios inFIG.19that much more traffic data from TSD740′ for “Area 1” may be required or desired to enable useful information to be generated for the users of the first and second vehicles810A, B and any other vehicles travelling within Area 1 than is required for generating useful information to the user of vehicle810C in “Area 2”.

The system and method of the invention provide novel methods for adjusting the respective frequency of traffic data transmission of TSDs such as TSDs740′,740″.

FIG.20is a flow diagram of a method900performed by the TRM760to update the transmission frequency of one or more of its associated TSDs740when the TRM760receives a new transmission policy for said TSD740from the TC710.

In a first step905of the method900, the TRM760receives an updated transmission control policy from the TC710. The updated transmission control policy comprises or contains a new transmission policy for one or more TSDs740associated with the TRM760. In this example of the method900, it will be assumed, for ease of description, that the TRM760services a single TSD740, but the method is equally applicable to a TRM760that services a group of TSDs740.

In normal operation, the TRM760receives traffic data from the TDS740for transmission by the TRM760over a 5G channel to the data processor755or directly to the TC710. The received traffic data is received by the TRM760for transmission according to the transmission frequency f defined by the transmission policy generated for the TSD740, i.e., the traffic data received at the TRM760from the TSD740is received and transmitted after a time period defined by the transmission frequency f of the TSD's transmission policy has expired. This may be achieved by the TRM760sampling data from the TSD740, or an RSU130associated with the TSD740, on expiry of the time period defined by the transmission frequency f of the TSD's transmission policy and then immediately transmitting said data thereby ensuring said data is up to date data for real-time applications. Once a subsequent time period defined by the transmission frequency f expires, the process is repeated. In the case where there is no change to the TDS's transmission policy then the time periods being counted down have the same value, i.e., same transmission frequency.

In the updating method900where, in the first step905, the TRM760receives an updated transmission policy for the TSD740, then, in a second step910, the TRM760updates the transmission frequency f for the TSD740in accordance with the updated transmission policy. In a third step915of the method900, the TRM760immediately updates a waiting time for a next transmission of sampled traffic data received from the TSD740. As a consequence of updating the waiting time in the third step915, the TRM760applies the updated transmission policy to the TSD740. In a fourth step of method900, at decision box920, the TRM760determines if the updated waiting time has expired. If it has not expired then, in a fifth step925, the TRM760continues the countdown of the updated waiting time. Once it is determined at decision box920that the updated waiting time has expired, the TRM760transmits the sampled traffic data. This involves, in the sixth step930, receiving the sampled traffic data on expiry of the counted-down time period from the TSD740and, in the seventh step935, sending said traffic data to the data processor755or directly to the TC710.

The transmission control policy generated by the TC710is preferably initially based on processing of historical traffic data by the Empirical Analyzer Module715. In effect, the Empirical Analyzer Module715predicts or suggests a general, stable transmission control policy derived from the historical traffic data. In some embodiments, it is possible that only this transmission control policy is required for stable operation of the network system100. The historical traffic data may comprise traffic data received at the TC710via the device information interface750from some or all of the TSDs740and possibly also data received from some of all of the RS-Us130and some or all of the other traffic sensors745.

The Empirical Analyzer Module715preferably continues to process historical traffic data and any new traffic data received at the TC710and stored in the database725to update the general transmission control policy. The general transmission control policy includes a general frequency of transmission of traffic data value fgwhich is continuously or periodically updated. A respective general frequency of transmission of traffic data value fgis initially applied to all of the TSDs740to, in effect, apply a stable transmission of real-time traffic data from TSDs740in the network system100. The general frequency of transmission of traffic data value fgmay be the same for each of the TSDs740, but is likely to vary amongst TSDs740due to the respective circumstances of the various TSDs740. However, events may occur that require the transmission frequency of at least some TSDs740to be dynamically adjusted.

In one embodiment, one method of determining or calculating the general frequency of transmission of traffic data value fgis based on historical traffic data relating to vehicle speed with respect to a selected period of time and a number of traffic alerts and/or traffic accidents.

Assume that the speed of a moving traffic object, such as a vehicle, is v, and a safe distance between vehicles is set to Ds(e.g. empirical maximum braking distance/2), then a safe traffic data transmission frequency for tracking the vehicle will be: fs=v/Ds, where fsis the safe transmission frequency. Splitting 24 hours of a day into T periods, in each period t, the average speed of moving traffic objects detected by the TSDs740in a related local area of the defined geographical area104isvt, the number of accidents atand the number of alerts bt. Consequently, the risk level r is given by:
rt=C1/(1+e−at)+C2/(1+e−bt)

C are weighting factors.

The Empirical Analyzer Module715calculates the general frequency of transmission of traffic data value fgof each time period t from: fgt=(vt/Ds)×(0.5+rt). In a short time period such as half an hour, the speed of objects will not usually fluctuate very much, sovtis used to calculate fgfor most cases. If, however, the speed fluctuates considerably, then using a proportion of the maximum speed vtmaxwill be better for detecting moving traffic objects with high speed. If the speed fluctuates by a small amount, then using a proportion of minimum speed vtmincan help to save network resources. In general, if we consider the traffic condition of i days, then the general traffic data transmission frequency will be:
fgt=Σifgt/i.

The generated transmission control policy may then be dynamically adjusted based on subsequent processing of real-time traffic data by the Real-time Analyzer Module720, the real-time traffic data being preferably received at the TC710via the TRMs760. The Real-time Analyzer Module720preferably continuously monitors the most recent (real-time) traffic data to adjust the transmission frequencies of selected TSDs740based on, for example, issued traffic alerts or the like and the proximity of any such TSDs740to the location of such traffic alerts. In this instance, traffic alerts may include traffic emergencies.

It is envisaged that dynamic adjustment of the transmission frequencies of TSDs740may be limited to only TSDs740in one or more small local areas800within the defined geographical area104dependent on traffic events such as alerts and emergencies, etc.

The TC710is preferably located in the EGW120as the EGW120typically has substantially more computational capabilities than the distributed devices such as the TRMs760and/or the RSUs130, etc.

Referring toFIG.21, there is provided a schematic block diagram of the Real-time Analyzer Module720for the network system100which implements three main processes of: (1) updating the transmission frequency of a selected or source TSD740in response to real-time data describing parameters of detected moving traffic objects; (2) updating the transmission frequencies of target TSDs740in response to real-time data describing parameters of detected moving traffic objects; and (3) updating the transmission frequencies of selected or target TSDs740in response to one or measured network parameters. The Real-time Analyzer Module720includes a policy change checker module765. The policy change checker module765checks whether the transmission policies of the TSDs740need to be changed. Preferably, updating the transmission frequencies of selected or target TSDs740occurs only after the policy change checker module765has implemented its check.

When receiving the real-time traffic data from TSDs740describing detected moving traffic objects, the Real-time Analyzer Module720analyzes current traffic status and calculates a respective new data traffic transmission frequency for each device as appropriate as will be described more fully with respect toFIG.22. In the event that a dangerous moving traffic object such as a speeding vehicle is detected, it is desirable that the Real-time Analyzer Module720informs related or target TSDs740and/or determine new respective transmission policies for said related or target TSDs740as will be described more fully with respect toFIG.23. The network monitor750measures parameters of the 5G-V2X network including the transmission delay d between the TRMs760and the EGW120. In the event that the transmission delay d is longer than a predefined or predetermined value, the Real-time Analyzer Module720calculates new respective transmission policies for selected or target TSDs740as will be described more fully with respect toFIG.24.

Referring toFIG.22, a first method (method 1 inFIG.21)1000performed by the Real-time Analyzer Module720starts with step1005where the data processor755sends structured traffic data describing moving traffic objects to the Real-time Analyzer Module720. The structured traffic data provided by the data processor755is generated from raw traffic data received by the TRMs760from their associated TSDs740. The structured traffic data describes at least the speed of the moving traffic objects and the locations of said objects. Other data inputs to the Real-time Analyzer Module720include the general data traffic transmission frequency fgcalculated in step1010by the Empirical Analyzer Module720and map data provided in step1015by the map server735. In step1020, the Real-time Analyzer Module720calculates a safe traffic data transmission frequency fsfor a selected or source TSD740. The safe traffic data transmission frequency fsfor the selected or source TSD740may be based on the previously described safe traffic data transmission frequency fs=v/Ds, where the selected or source TSD740is tracking only one vehicle. In some embodiments where the selected or source TSD740is tracking multiple vehicles, it is preferred to use the maximum speed of the tracked vehicles such that the safe traffic data transmission frequency for the selected or source TSD740is given by fs=vmax/Dswhere vmaxis a maximum speed of the detected moving traffic objects (e.g., vehicles) within one timestamp period of the selected or source TSD740. If in decision box1025, it is determined for said selected or source TSD740that fsis not greater than the value of fg, for said selected or source TSD740, then a new traffic data transmission frequency f for the selected or source TSD740is set in step1030as f=fg. If, however, at decision box1025, it is determined that fsis greater than fg, then the new traffic data transmission frequency f for the selected or source TSD740is changed in step1035to f=fs. Consequently, the new traffic data transmission frequency f for the selected or source TSD740is assigned a value of either fsor fg. The value of the general traffic data transmission frequency fgis calculated by the Empirical Analyzer Module715as a balance between system performance and power saving. This allows the TSDs740to operate at a relatively low traffic data transmission frequency for most periods of time, but the method provides the ability to make sure each TSD740can track and detect new moving traffic objects and to dynamically adjust the traffic data transmission frequency (fsor fg) according to the speed of the detected moving traffic objects.

In decision box1040, fcurrentis the current traffic data transmission frequency f for the TSDs740maintained by the policy change checker Module765of the Real-time Analyzer module720. If, in decision box1040, it is determined that the new value of f from either of steps1030or1035is not equal to the selected or source TSD's current value of fcurrentthen the Real-time Analyzer Module720generates a new transmission policy for the selected or source TSD740, otherwise the value of f for the selected or source TSD740is maintained at f=fcurrent. At step1045, Real-time Analyzer Module720sends the new transmission policy for the selected or source TSD740to that TSD's associated TRM760. Where, in the first method1000, it is determined that fsis greater than fgfor the selected or source TSD740, then, at decision box1050, a determination is made of whether or not the detected moving traffic object is a dangerous object, i.e., that it presents a threat to other vehicle users. If at decision box1050it is determined that the detected moving traffic object presents a threat to other vehicle users then, at step1055, the Real-time Analyzer Module720is triggered to implement a second method1100(method 2 inFIG.21). The determination that a detected moving traffic object presents a threat to other vehicle users may be based on a predetermined, selected or calculated speed limit vlimitfor a local area800of the defined geographical area104. The local area800may encompass several TSDs740. The speed limit vlimitfor said local area800may be obtained from the map server735. If the speed v of the detected moving traffic object in the local area800is greater than speed limit vlimitand/or greater than a multiple of the average speedvof moving traffic objects in said local area800then the detected moving object is determined to be a dangerous object. It is preferred than the multiple level of the average speedvof moving traffic objects is twice said average speedv.

Referring toFIG.23, a second method (method 2 inFIG.21)1100performed by the Real-time Analyzer Module720starts with step1105of receiving (from method 1) an indication that the detected moving traffic object is a dangerous moving traffic object. The second method1100is focused on selected or target TSDs740. The selected or target TSDs740are determined from the map data provided by the map server735to be TSDs740which are in the vicinity of the detected dangerous moving traffic object, i.e., TSDs740which are in the vicinity of the source TSD740which first detected the dangerous moving traffic object and which will likely soon detect the dangerous moving traffic object.

Reference is made here toFIG.25which shows a vehicle810A denoted as “car1” travelling through a junction of first and second carriageways805,806in a first local area800A serviced by a TSD740A. The vehicle810A is denoted as a “normal car” meaning that it is travelling within a speed limit. The vehicle810A is travelling along the first carriageway805towards a junction with a second carriageway806and onwards towards a second local area800B serviced by a second TSD740B and a third local area800C serviced by a third TSD740C. In this scenario, the vehicle810A does not pose a danger to other vehicle users. In this scenario, it is not necessary to implement the second method in the Real-time Analyzer Module720.

By way of contrast, reference is made toFIG.26in which the vehicle810A is travelling towards a junction of a third carriageway807with the first carriageway805in the second local area800B. The second TSD740B has detected that the vehicle810A is speeding and thus it is determined that vehicle810A comprises a dangerous moving traffic object. Consequently, it is necessary to implement the second method in the Real-time Analyzer Module720. However, the second TSD740B cannot yet determine which route vehicle810A will take. As shown inFIG.26, the vehicle810A may choose to take one of two possible routes once it reaches the junction. Consequently, while the second TSD740B can be treated as comprising the source TSD, the second method treats the first and third TSDs740A, C as selected or target TSDs despite that fact that only one of the first and third TSDs740A, C will subsequently detect the vehicle810A dependent on the route chosen at the junction. Each of the first and third TSDs740A, C will be notified in advance of the detection of the speeding vehicle810A by the source TSD740B. It will be appreciated that there might be more than two possible routes a detected vehicle may take, but the foregoing is sufficient to illustrate the concept of source TSDs and target TSDs.

It will be understood that, whilst each of the first, second and third local areas800A, B, C are shown as comprising only one TSD740A, B, C, the local areas810A, B, C may be larger than suggested and may comprise a plurality of TSDs740.

Referring again toFIG.23, in a next step1110of the second method1100, the Real-time Analyzer Module720determines from map data provided at step1115which TSD740comprises the source TSD and which TSDs740are to be treated as selected or target TSDs740, i.e., the TSDs740which may likely detect the dangerous moving traffic object detected by the source TSD740. Following steps1110and1115, the data processor755transmits, in step1120, structured traffic data describing the dangerous moving traffic object and any other moving traffic objects detected by the source and selected or target TSDs740which is received, in step1125, at the Real-time Analyzer Module720. In a similar manner as in the first method1000, the structured traffic data provided by the data processor755is generated from raw traffic data received by the respective TRMs760of the source and target TSDs740.

At decision box1130of the second method1100, a determination is made of whether or not the detected dangerous moving traffic object has left the local area or coverage area of the source TSD740. Once it is determined that the detected dangerous moving traffic object has left the local area or coverage area of the source TSD740, a next step1135of the second method1100calculates a waiting time wsfor each selected or target TSD740. The waiting wstime for each selected or target TSD740is dependent on a respective length of a path LDevicefrom the current detected location of the dangerous moving traffic object to each of said selected or target TSDs740. The respective lengths of the paths LDevicefrom the current detected location of the dangerous moving traffic object to each of said selected or target TSDs740can be determined from the map data received at step1115and the real-time traffic data provided at step1120. Assuming the maximum speed of the dangerous moving traffic object is Vmax, where Vmaxmay be dependent on a type of the dangerous moving traffic object, the shortest respective waiting time for each of the selected or target TSDs740is wsdevice=LDevice/Vmax. Preferably, step1135also determines a respective longest waiting time wlfor each selected or target TSDs740. The longest waiting time wlfor each of the selected or target TSDs740is wldevice=LDevice/(vlimit/2 orv)*(0.5+r).

In a next step1140of the second method1100, the Real-time Analyzer Module720counts down the shortest waiting time wsfor each of the selected or target TSDs740. When the shortest waiting time wsfor one of said selected or target TSDs740expires, it indicates that the dangerous moving traffic object may have reached the coverage area of said one of said selected or target TSDs740. In step1145, the Real-time Analyzer Module720calculates a temporary traffic data transmission frequency ftbased on the general traffic data transmission frequency fgprovided by the Empirical Analyzer Module720where ft=fg*vdanger/vlimitor, ft=fg*vdanger/(2*v) if vlimitis not obtained from the map data. Then, fgis set equal to ft. The former value of fgcan be considered as fg_oldand the new value of fgcan be considered as fg_new. The value of vdangermay be determined based on the speed of the speeding vehicle.

If, at decision box1150, it is determined that ftis greater than fcurrentfor the one of the selected or target TSDs740then, at step1155, the Real-time Analyzer Module720generates a new transmission policy for said one of the selected or target TSDs740and transmits said new transmission policy to the TRM760associated with said one of the selected or target TSDs740. However, if, at decision box1150, it is determined that ftis not greater than fcurrentfor the one of the selected or target TSDs740then the Real-time Analyzer Module720maintains the current transmission policy for said one of the selected or target TSDs740.

Steps1140through to1155are performed respectively for each of the selected or target TSDs740.

Once, at decision box/step1160, one of said selected or target TSDs740detects the dangerous moving traffic object the Real-time Analyzer Module720has counted down the longest waiting time wlfor said one of the selected or target TSDs740indicating that the speed of the dangerous moving traffic object is now deemed safe, the Real-time Analyzer Module720at step1165resets the current respective general traffic data transmission frequency fgfor each of the selected or target TSDs740based on current traffic data and, at step1170returns to the first method1000. After either of steps1145or1165, the Real-time Analyzer Module720sends, at step1175, the recalculated or reset general traffic data transmission frequency fgto the Empirical Analyzer Module720for use in calculating an updated general traffic data transmission frequency fg.

Referring toFIG.24, a third method (method 3 inFIG.21)1200performed by the Real-time Analyzer Module720starts with step1205of receiving a new value of the network delay d between the TRMs760and the EGW120from the network monitor750. In some embodiments where the 5G-V2X network is integrated with a Time Sensitive Network (TSN), the network delay value d can be obtained directly from the TSN, otherwise the network delay value d must be determined by the network monitor750. The maximum delay value can be derived from dmax=1/fcurrent, where fcurrentis the current traffic data transmission frequency f for the TSDs740maintained by the policy change checker module765of the Real-time Analyzer Module720. If, in decision box1210, the Real-time Analyzer Module720determines that one or more TSDs740have a network delay value d>dmaxthen the Real-time Analyzer Module720uses, in step1215, map data from the map data server to identify nearby related TSDs740.

At decision box1220, it is determined that none of the identified related devices740comprises a non-real-time data sending device, then, at step1225, the general traffic data transmission frequency fgfor the related devices740is decreased.

If it is determined at decision box1220that some of such devices740do send non-real-time data then, at decision box1230, it is determined if the transmission frequency of the non-real-time data sending devices740is greater than zero. If so, a percentage of the transmission frequency of the non-real-time data sending devices will be decreased by: (d/dmax)−1 at step1235and the new value off for the non-real-time data sending devices740will be sent to the respective TRMs760at step1240.

Once the general traffic data transmission frequency fgfor the related devices740has been decreased at step1225and/or the data transmission frequency f for the non-real-time related devices740has been decreased at step1235, the method1200obtains a new network delay value d and repeats the steps of the third method1200and repeats the decreases in one or both of the general traffic data transmission frequency fgfor the related devices740and the data transmission frequency f for the non-real-time related devices740until d is less than dmax. The method1200may include decreasing the transmission frequency of the non-real-time data sending devices740to zero. However; the general traffic data transmission frequency fgfor the related real-time data sending devices740cannot be decreased to zero in order to protect the safety of the network system100. Consequently, the methods performed by the Real-time Analyzer Module720include a limit to the amount by which the general traffic data transmission frequency fgfor the related real-time data sending devices740can be decreased.

In the third method1200, after the general traffic data transmission frequency fgfor the related devices740has been decreased at step1225, then, at step1245, the new value of fgfor the related devices740is sent to the Empirical Analyzer Module720. In one embodiment, fgcannot be decreased below fg/2.

The policy change checker module765preferably checks whether the transmission policies of the TSDs740need to be changed in any of decision box1040ofFIG.22, decision box1150ofFIG.23, and decision box1230ofFIG.24.

Where the 5G-V2X network is not integrated with a TSN, the network monitor750may calculate the network delay value d by any suitable method. One method is illustrated by the timing diagram ofFIG.27.

The method comprises:1. The TRM760sends a “start request” message to the EGW120together with a timestamp T1;2. After the EGW120receives the “start request” with timestamp “T1” at timestamp T2, it sends a delay request to TRM at T3;3. After the TRM760receives the “delay request” at T4, it sends “T4” as a “delay response” to the EGW120;4. After the EGW120receives T4 from the TRM760, it will send a signal to the TRM760to finish the delay estimation; and5. The network delay d can be calculated by the network monitor750from d=(T4−T1−T3+T2)/2.

The methods hereinbefore described with respect toFIGS.17to27may be implemented at each EGW120of the network system100.

The apparatuses described above may be implemented at least in part in software. Those skilled in the art will appreciate that the apparatuses described above may be implemented at least in part using general purpose computer equipment or using bespoke equipment.