System and method for improving network efficiency in 5G-V2X networks

Abstract

The present invention discloses a method and system for controlling data transmission in a 5G-V2X network. The 5G-V2X network includes at least one defined geographic area, which includes multiple traffic sensing devices (TSDs). Each TSD is configured to provide data to a V2X processing system including a transmission controller (TC) via one or more 5G channels through an edge gateway module (EGW) in the defined geographic area. The method includes dynamically adjusting the data transmission frequency of at least one of the multiple TSDs according to a transmission control policy.

Description

Technical Field

[0001] The present invention relates to a system and method for improving 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 Art

[0002] Vehicle-to-Everything (V2X) is a vehicle communication system configured to pass information from a vehicle to any entity that may affect the vehicle, and vice versa. This system encompasses other more specific communication types, 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).

[0003] In a V2X system with intelligent mobile roadside infrastructure, roadside units (RSUs) are included, each of which includes traffic sensing devices (TSDs), such as lidars, radars, and cameras. The RSUs and TSDs transmit their collected data via 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, namely traffic data, for processing by the EGW to discover, determine, and / or calculate useful information, which is then transmitted via the V2X network to road users, particularly but not limited to vehicles. This useful information can include traffic alerts, warnings of potentially hazardous traffic conditions, and recommendations for road users to make better and / or safer decisions. Deployed RSUs and TSDs typically collect and / or generate large amounts of data, which can consume significant 5G-V2X communication channel resources, leading to one or more issues within the 5G-V2X network, such as network congestion, data transmission delays, and slow service provision. In some cases, it may not be possible, or at least impractical, to transmit all RSU and / or TSD data over one or more 5G channels of a 5G-V2X network.

[0004] US20210099976A1 discloses an edge network infrastructure (e.g., RSU, RAN node, or co-located MEC server / host) that determines the amount of spectrum required for each vehicle communication system (e.g., Long Term Evolution Cellular V2X (LTE-CV2X), Dedicated Short Range Communication (DSRC) / Intelligent Transportation System-G5 (ITS-G5)) based on detecting the number of vehicle user equipment (vUE) using each vehicle communication technology during service. It discloses dynamically allocating preferred channel allocations and forwarding the allocations to neighboring infrastructure (e.g., one or more RSUs) to reconfigure themselves to provide relevant services to the vUEs.

[0005] CN112822656A discloses a 5G-enabled vehicle-to-everything (V2X) intelligent terminal. The terminal consists of a 5G / V2X onboard unit (OBU) and an onboard sensor system. Compared to DSRC, the OBU offers a longer communication range and higher reliability. Compared to LTE-V2X communication systems, the OBU also offers lower latency and greater data transmission capacity within the V2X cloud network.

[0006] CN112055330A discloses a 5G-based V2X vehicle-to-everything (V2X) secure communication system, which includes a cloud, vehicle, roadside, and pedestrian terminals. It provides cryptographic services and secure storage based on a security module for communication between these terminals.

[0007] US10873876B2 discloses a communication assurance system that ensures the valuable information in each V2X wireless message is reliably delivered, even in congested V2X communication channels. This system calculates a value score for each of a series of attributes of a message based on its factor data and the recipient's contextual data, and combines these scores into a total value score that represents the value of the message to the terminal.

[0008] CN109314841A discloses improved quality of service (QoS) support for sending vehicle data via a sidelink (SL) interface. The application layer generates the vehicle data. The vehicle data, along with priority indication data and one or more QoS parameters, is forwarded to the transport layer via the SL interface. Based on the received priority indication data and one or more QoS parameters, the transport layer transmits the vehicle data to one or more receiving devices via the SL interface in accordance with autonomous radio resource allocation.

[0009] US10992589B2 discloses an apparatus for configuring a UE to help alleviate network congestion. The apparatus includes a first parameter indicating packet expiration and a second parameter indicating the packet's transmission classification. The first parameter determines whether a packet is expiration, while the second parameter adjusts packet transmission. The second parameter includes a congestion threshold, which determines whether to discard or transmit a packet based on the level of congestion.

[0010] CN108182817A discloses a roadside assistance system and a vehicle-mounted assistance system to solve the problem of not being able to fully and accurately obtain information about the vehicle's surrounding environment. The focus here is on data transmission from the RSU to the vehicle.

[0011] US10212102B2 discloses an apparatus for storing messages and performing path switching between the SL and uplink (UL) for V2X message transmission. The apparatus provides a method, including storing V2X data that has not yet been transmitted on an old path (SL or UL) in a transmission buffer, identifying whether data from an SLV2X channel (SVCH) is included in the stored V2X data, resubmitting the stored data to a lower layer of a new path (UL or SL), and transmitting the V2X data based on a logical channel prioritization (LCP) procedure to a target of the new path via a path switching layer of a UE, the path switching layer of the UE being located directly above the packet data convergence protocol (PDCP) layer of the UE.

[0012] US10992752B2 discloses a sensor deployment mechanism for road monitoring, which minimizes the number of required sensors to reduce costs and save computing and network resources.

[0013] US10403135B2 discloses a reconfigurable roadside network (sensors, CPU, antennas, and a communication backbone) that optimizes cooperative autonomous driving using key performance indicators (KPIs). The CPU determines a traffic scenario based on measurement data from one or more sensors. The determined traffic scenario is then used to determine a set of target KPI values. The current KPI values are optimized, and the roadside network is reconfigured based on the determined KPI values.

[0014] Most related technologies focus on achieving the security and efficiency of end-to-end (V2I, V2V, etc.) communications by physically changing the range of sensors and communication antennas within a sector or logically changing the mapping of sensors and antennas to CPUs.

[0015] In order to ensure that the service quality and road safety of the V2X network are not significantly affected, it is necessary to dynamically adjust the transmission frequency of data transmitted to the V2X system through one or more 5G channels based on the feedback data generated by the edge computing device or system.

[0016] Purpose of the Invention

[0017] It is an object of the present invention to alleviate or circumvent to some extent one or more problems associated with known systems and methods for improving or enhancing network efficiency in 5G-V2X networks.

[0018] The above objects are achieved by the feature combination of the main claim; the dependent claims disclose further advantageous embodiments of the invention.

[0019] Another object of the present invention is to provide a system and method for improving vehicle road safety and / or vehicle management.

[0020] Another object of the present invention is to provide a 5G-V2X vehicle-to-vehicle communication system based on a determined local geographic area to improve network efficiency.

[0021] Another object of the present invention is to provide a multi-layer system and method for improving road safety and / or vehicle management, wherein the local layer of the multi-layer system uses an edge computing device or system to generate feedback data to adjust the data transmission frequency of the TSD.

[0022] Those skilled in the art will derive other objects of the present invention from the following description. Therefore, the above object statements are not exhaustive and are only used to illustrate some of the multiple objects of the present invention. Summary of the Invention

[0023] The present invention relates to traffic data communication in 5G-V2X networks.

[0024] The present invention provides an end-to-end V2X network system with a multi-layer system architecture, which utilizes information and algorithms executed in the local layer of the multi-layer system to generate feedback data to adjust the data transmission frequency of at least one TSD.

[0025] In particular, the present invention proposes a mechanism for dynamically adjusting the transmission frequency of traffic data transmitted to a 5G-V2X platform via one or more 5G channels based on feedback generated by edge computing nodes such as an edge gateway module (EGW).

[0026] The present invention relates to a method and system for controlling data transmission in a 5G-V2X network. The 5G-V2X network includes at least one determined geographical area, which includes multiple TSDs. Each TSD is configured to provide data to a V2X processing system through one or more 5G channels, and the V2X processing system includes a transmission controller (TC) located at or through an edge gateway module (EGW) in the determined geographical area. The method includes: the TC dynamically adjusts the data transmission frequency of at least one TSD among the multiple TSDs according to a transmission control strategy. Dynamically adjusting the data transmission frequency of at least one TSD may include: limiting the traffic data transmission frequency of the TSD or increasing the traffic data transmission frequency of the TSD according to feedback generated by the TC. The TC can coexist with the EGW and form a part of the EGW, or it can be an independent device or apparatus connected to the EGW through 5G-V2X network communication.

[0027] In a first main aspect, the present invention provides a method for controlling traffic data transmission in a 5G-V2X network. The method comprises configuring a plurality of transport service devices (TSDs) within at least one defined geographic area of the 5G-V2X network, configuring an electronic gateway (EGW) for the at least one defined geographic area to communicate with the plurality of TSDs via one or more 5G channels of the 5G-V2X network, and configuring each of the TSDs to provide traffic data to a traffic controller (TC) located at the EGW or to provide traffic data to the TC via the EGW via the one or more 5G channels. The TC dynamically adjusts the frequency of traffic data transmission from at least one TSD based on a transmission control policy.

[0028] In its second main aspect, the present invention provides a system for controlling traffic data transmission in a 5G-V2X network. The system includes a plurality of transport-based devices (TSDs) located within at least one defined geographic area and an electronic gateway (EGW) communicating with the plurality of TSDs via one or more 5G channels of the 5G-V2X network. Each TSD is configured to provide traffic data to a traffic controller (TC) located at the EGW via the one or more 5G channels, or to provide traffic data to the TC via the EGW. The TC is configured to dynamically adjust the frequency of traffic data transmission from at least one TSD based on a transmission control policy.

[0029] In a third main aspect, the present invention provides a TC for controlling the transmission of traffic data in a 5G-V2X network. The TC includes an experience analyzer module for processing historical traffic data received from some or all of a plurality of TSDs within a determined geographical area of the 5G-V2X network. The experience analyzer module is configured to process the historical traffic data to determine or predict an initial transmission control strategy for the plurality of TSDs. The TC includes a real-time analysis module configured to process real-time traffic data received from some or all of the plurality of TSDs to adjust the initial transmission control strategy, thereby providing a dynamic transmission control strategy for the plurality of TSDs. The real-time analysis module is configured to control a transmission restriction module (TRM) associated with the plurality of TSDs to apply a corresponding transmission strategy to each of the plurality of TSDs.

[0030] This summary does not necessarily disclose all features necessary to define the invention; the invention may lie in a sub-combination of the disclosed features. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The above and further features of the present invention will be apparent from the following description of preferred embodiments, which are provided by way of example only with reference to the accompanying drawings, in which:

[0032] Figure 1 A schematic diagram showing one embodiment of a road management system;

[0033] Figure 2 yes Figure 1 A system diagram showing that the system includes an end-to-end V2X network;

[0034] Figure 3 yes Figure 1 A system diagram showing the hierarchical structure of the system more clearly;

[0035] Figure 4 show Figure 1 A block diagram of the system's edge gateway module, showing its connections to other entities and some of its information / data inputs;

[0036] Figure 5 show Figure 1 A block diagram of the system's network cooperation engine (NCE) module, showing its connections to other entities and some of its information / data inputs;

[0037] Figure 6 show Figure 1A block diagram of the system's central management platform module, showing its connections with other entities;

[0038] Figure 7 show Figure 1 Flowchart of information flows and processes performed by the system's edge gateway module;

[0039] Figure 8 show Figure 1 Flowchart of information flows and processes performed by the system's NCE modules;

[0040] Figure 9 An example showing how a vehicle generating a false alarm may occur;

[0041] Figure 10 Another example showing how a vehicle can generate a false alarm;

[0042] Figure 11 Shows the block diagram of the area alert management system (AAMS), which can be deployed in Figures 1 to 8 in the road management system;

[0043] Figure 12 Shows some data paths between AAMS and other system entities in the road management system;

[0044] Figure 13 A flow chart showing a method of determining whether an alarm generated by a vehicle is a false alarm;

[0045] Figure 14 Shows a way to group false alarms;

[0046] Figure 15 Shows a method for correlating impact factors for grouped false alarms;

[0047] Figure 16 A schematic diagram showing a method for determining the confidence level of a false alarm;

[0048] Figure 17 A schematic block diagram showing a system for controlling traffic data transmission in a 5G-V2X network;

[0049] Figure 18 yes Figure 17 A schematic block diagram of the arrangement of a transmission restriction module (TRM) and a traffic sensing device (TSD) in a system;

[0050] Figure 19 Shows the comparative complexity of the local area monitored by each TSD;

[0051] Figure 20A flow chart showing a method of updating a TSD's transmission frequency when a new transmission policy of the TSD is received;

[0052] Figure 21 yes Figure 17 A schematic block diagram of a real-time analysis module of a transmission controller (TC) in a system;

[0053] Figure 22 A flow chart showing a method for updating the transmission frequency of a TSD based on real-time data describing parameters of detected moving traffic objects;

[0054] Figure 23 A flow chart illustrating a method for updating a transmission frequency of a target TSD based on real-time data describing parameters of detected moving traffic objects;

[0055] Figure 24 A flow chart showing a method for updating the transmission frequency of a target TSD based on measured network delay;

[0056] Figure 25 An example showing TSD monitoring normal traffic conditions;

[0057] Figure 26 An example showing TSD monitoring abnormal traffic conditions;

[0058] Figure 27 A timing diagram showing the network delay calculation. DETAILED DESCRIPTION

[0059] The following description is intended to describe preferred embodiments by way of example only and does not limit the combination of features necessary to implement the invention.

[0060] References in this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic associated with that embodiment is included in at least one embodiment of the present invention. The phrase "in one embodiment" appearing throughout this specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive of other embodiments. Furthermore, various features may be described in some embodiments and not in others. Similarly, various requirements may be described in some embodiments and not in others.

[0061] It should be understood that the elements shown in the figures can be implemented in various forms of hardware, software or a combination thereof. These elements can 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 interface.

[0062] This specification illustrates the principles of the invention. It will therefore 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.

[0063] In addition, the principles, aspects and embodiments of the present invention and specific examples thereof are described herein and are intended to cover structural and functional equivalents thereof. In addition, such equivalents also include currently known equivalents and equivalents developed in the future, i.e., any elements developed, performing the same function, regardless of their structure.

[0064] 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.

[0065] The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in conjunction with appropriate software. When provided by a processor, these functions may be provided by a single dedicated processor, a single shared processor, or multiple separate processors, some of which may be shared. In addition, the explicit use of the term "processor" or "controller" should not be interpreted as referring only to hardware capable of executing software, but may implicitly include, but not be limited to, digital signal processor ("DSP") hardware, read-only memory ("ROM") for storing software, random access memory ("RAM"), and non-volatile memory.

[0066] In the claims, any element represented as a means for performing a particular function is intended to encompass any means of performing that function, including, for example, a) a combination of circuit elements that perform that function or b) any form of software, thus including firmware, microcode, etc., in combination with appropriate circuitry for executing that software to perform the function. The invention defined by these claims resides in the functionalities provided by the various recited means combined and brought together in the manner required by the claims. Any means for providing those functionalities is therefore considered equivalent to the means shown herein.

[0067] In the following description, references to "alarm" are considered to be references to "alarm" and vice versa.

[0068] refer to Figure 1 , Figure 1 is a schematic diagram of one embodiment of the system 100, AAMS 400 ( Figure 11) may be implemented therein, although it should be understood that the AAMS 400 may be implemented in any suitable road management system, including a V2X-based road management system. The system 100 is preferably a communication network-based system 100, arranged into a plurality of defined local geographic areas 110A, B, each of which is managed and / or communicates data with a corresponding edge gateway module (EGW) 120. Each EGW 120 communicates with a corresponding NCE 160, and each NCE communicates with a central management platform 170.

[0069] like Figure 1 As shown, the defined local geographic areas 110A, B may overlap, although this is not necessarily the case, and preferably, any overlap between adjacent defined local geographic areas 110A, B is minimized. Each EGW 120 preferably manages and communicates with a plurality of roadside units (RSUs) 130. Each RSU 130 is preferably arranged beside, adjacent to, or near any one or more roads, intersections, crossroads, crosswalks, a set of traffic lights, etc., so that each RSU has a reasonable line of sight to any vehicle located or passing near it.

[0070] Each vehicle 140 configured to operate within the network system 100 is equipped with an onboard data processing unit, hereinafter referred to as an in-car gateway module (ICGW) 150. The ICGW 150 can be a standalone unit configured to be installed in the vehicle 140, or it can include an existing data processing unit of the vehicle 140, which has a memory 152 storing machine-readable instructions and a processor 154 for executing the instructions to cause the ICGW 150 to perform appropriate method steps. The ICGW 150 can include a V2X on-board unit (V2X-OBU). Each EGW 120 includes at least a memory 122 storing machine-readable instructions and a processor 124 executing the instructions to cause the EGW 120 to perform appropriate method steps. Similarly, each RSU 130 includes at least a memory 132 storing machine-readable instructions and a processor 134 executing the instructions to cause the RSU 130 to perform appropriate method steps.

[0071] Among them, each ICGW 150 is preferably configured to provide V2X communication system access to other ICGWs 150 and road infrastructure in the determined local geographical area 110A, B, exchange information therewith, collect data from vehicle-mounted modules (such as speedometers and satellite positioning systems), exchange vehicle-collected data directly or indirectly with other local ICGWs 150, RSUs 130 and their corresponding EGWs 120, use vehicle-collected data and data received from other local ICGWs 150, RSUs 130 and EGWs 120 to determine threats and generate alarms, etc., and receive and issue V2X alarms (alerts) and notifications, as well as receive traffic status information and suggestions.

[0072] Each EGW 120 is preferably configured to coordinate at least a plurality of RSUs 130 within its respective defined local geographic area 110A, B, monitor traffic in real time, including monitoring traffic congestion and traffic events such as accidents, intelligently implement local traffic management, collect data from local infrastructure such as traffic lights, sensors, cameras, local ICGWs 150 and RSUs 130, and respective NCEs 160, collect policies from its respective NCEs 160, and use the collected data to identify threats and generate alerts. Each EGW 120 can be configured to determine, from the received and processed data, specific data to send to a particular ICGW 150 based on data received at the EGW 120 indicating one or more parameters related to or associated with vehicles of the particular ICGW 150. For example, an EGW 120 can use parameters such as street location to determine which vehicles within its local geographic area 110A, B need to receive a particular alert, alarm, action, or threat indication.

[0073] Multiple EGWs 120 are preferably managed and / or communicate with corresponding NCEs 160. Furthermore, multiple NCEs 160 are preferably managed and / or communicate with each other via a central management platform module 170. System 100 may include only one central management platform module 170 to cover a large geographic area, such as a city, county, or state. Each NCE 160 includes at least a memory 162 for storing machine-readable instructions and a processor 164 for executing the instructions to cause the NCE 160 to perform appropriate method steps. Similarly, the central management platform module 170 includes at least a memory 172 for storing machine-readable instructions and a processor 174 for executing the instructions to cause the central management platform module 170 to perform appropriate method steps.

[0074] Each NCE 160 is preferably configured to at least intelligently implement regional traffic management, determine and provide new and updated traffic policies to the EGWs 120 , and coordinate multiple EGWs 120 .

[0075] The central management platform module 170 is preferably configured to at least intelligently implement network-wide traffic management, determine traffic strategies for the NCE 160, and manage and analyze network-wide traffic data. The central management platform module 170 may include a cloud-based system that can be connected to the NCE 160 via an IP network, such as the Internet ( Figure 6 ) or a virtual private network (VPN).

[0076] It should be understood that the processing capabilities of the central management platform module 170 may be significantly greater than the processing capabilities of any of the NCE 160, EGW 120, RSU 130, or ICGW 150. Nevertheless, it is envisioned that the central management platform module 170 will operate on high-latency data and / or long data processing cycles to provide information related to, for example, road / traffic strategy and planning, rather than generating alerts, determining actions, and / or identifying threats at critical times, as would be performed at the local EGW 120 and RSU 130 level.

[0077] To improve the accuracy of vehicle safety alert generation and / or threat detection, multiple information sources, such as vehicles, pedestrian devices, roadside infrastructure, and communication networks, need to be processed and delivered at a low-latency signal level.

[0078] The network system 100 includes a V2X system that preferably utilizes all locally available data sources, including but not limited to vehicle ICGW 150, pedestrian devices 180 ( Figure 2 ), road infrastructure systems and equipment 190( Figure 2 ), such as traffic lights, traffic cameras, emergency service databases, local authority databases, etc., in a manner that notifies the EGW 120, RSU 130 and / or ICGW 150 of events, circumstances, etc. that may be relevant to enable the EGW 120, RSU 130 and / or ICGW 150 to determine a threat to the vehicle 140 or another road user and / or to generate an alert to the vehicle user or another road user, preferably in real time, or at least with ultra-low latency.

[0079] like Figure 2As more clearly shown in FIG, each ICGW 150 can communicate with other network entities using one or more standard communication interfaces. For example, the ICGW 150 can exchange data with other ICGWs 150 using V2V and / or exchange data with pedestrian devices 180 using V2P and / or exchange data with local infrastructure including RSU 130 using V2I. The RSU 130 and EGW 120 preferably use V2N to exchange data with each other and higher-level network entities such as NCE 160 and central management platform 170, which will be explained more fully below. Where appropriate, entities in the network system 100 may also utilize V2D and V2G. Therefore, as shown in FIG. Figure 2 As shown, an end-to-end V2X network system 100 having a multi-layer system architecture is provided, which utilizes information and algorithms executed at different layers of the V2X network system to achieve low-latency generation of vehicle / road safety alerts and / or low-latency determination of vehicle / road threats.

[0080] In the V2X network system 100, the EGW 120 and / or RSU 130 are configured to process local, real-time, and / or low-latency data to assist or provide warnings and / or identify threats to road users. The EGW 120 and / or RSU 130 will operate with data having a latency of 100ms or less, preferably 50ms or less. Low latency is considered to include data processing and delivery times in the range of 10ms to 100ms.

[0081] By limiting the processing of local real-time and / or low-latency data to individual EGWs 120 and / or RSUs 130 (on behalf of, or in conjunction with, the ICGWs 150 and / or user devices 180), the system 100 is able to provide or enable local-level critical time alert generation and / or threat determination without the inherent latency of processing such data by higher-level entities in the network system 100. The size of the geographic areas 110A, B is selected so that data from the one or more RSUs 130 and / or from the respective EGWs 120 can be transmitted to the ICGW 150 in real-time, or at least at a latency equal to or less than a first low level.

[0082] In one embodiment, the V2X network system 100 provides a communication channel for providing at least additional data to the ICGW 150, in addition to the vehicle's onboard data, for use in generating alerts, identifying threats, and / or determining vehicle control actions, either manually or autonomously. The V2X channel provided by the network system 100 is an efficient method for obtaining time-critical data from local external sources that may affect the vehicle and providing it to the ICGW 150, and vice versa.

[0083] from Figure 3The multi-layer arrangement of the network system 100 can be seen more clearly. The first layer can be considered to include any vehicle 140 and its associated ICGW 150 within the geographical area of the EGW 120, any other road users such as pedestrians and their associated equipment 180 ( Figure 2 ), street-level infrastructure such as smart traffic lights, camera systems, and RSUs 130. The second layer of network system 100 includes EGW 120. First-layer entities are linked to second-layer entities via local V2X networks 102, where data communications are exchanged using V2I, V2P, and V2V. The third layer of network system 100 can be considered to include NCEs 160, which are linked to second-layer entities via regional V2X networks 103 using V2I. The fourth layer includes a central management platform 170, which communicates using V2I via city-wide, county-wide, or state-wide V2X networks 104.

[0084] The first and second layer entities preferably operate with a signal latency of 100ms or less, and more preferably 50ms or less. The third layer entities preferably operate with a signal latency of 1000ms or less, while the fourth layer entities operate with a latency greater than 1000ms, approaching a time period of several seconds to minutes or even longer. Thus, the system 100 generally involves a multi-layered V2X network architecture or software system to achieve low-latency road safety V2X alert detection / threat determination at a local level while utilizing information and algorithms implemented by different, higher layers of the system (which have different, higher latency levels).

[0085] Figure 4 The structure of the EGW 120, its connections to other system entities, and some of its information / data inputs are shown. The EGW 120 includes a database or data pool 121, an area analysis engine module (AAE) 122, an artificial intelligence (AI) planning engine module 123, a policy gateway module 124, and an RSU and vehicle management module 125. Data connectors may include a data connector 126 to one or more RSUs 130, a data connector 127 to the NCE 160, and optional data connectors 128 and 129 to the central management platform 170 and external service providers. The data input to the AAE 122 may include map data, real-time event processing data, real-time road status analysis data, dangerous location identification data, and vehicle acceleration opportunity data.

[0086] The AI and Planning Engine module 123 is a software module within the EGW 120 that is configured to aggregate all data generated within the defined geographic area 110A, B of the EGW 120 and process the data using machine learning. The AAE 122 is a software module within the EGW 120 that is configured to process data generated within the defined geographic area 110A, B to determine any one or more of the following: determining the real-time status of all roads within the geographic area; determining the real-time status of all resources within the geographic area; determining the real-time status of all RSUs 130 within the geographic area; determining the real-time status of all ICGWs 150 within the geographic area; and determining the real-time status of all events within the geographic area. The Policy Gateway module 124 is a software module within the EGW 120 that is configured to receive and configure rules and policies from the NCE 160 or from the central management platform 170, and to receive policy information from local services using open standard application programming interfaces (APIs). For example, a local store can broadcast current retail and promotional information to vehicles as low-priority promotional information. The RSU and vehicle management module 125 is a software module within the EGW 120 that is configured to transmit data to the RSU 130 and ICGW 150 , including the real-time status information described above, and to configure at least the RSU 130 according to any policies received by the EGW 120 .

[0087] Figure 5 The diagram shows the structure of NCE 160, its connections to other system entities, and some of its information / data inputs. NCE 160 includes a database or data pool 161, a collaboration engine module 162, an artificial intelligence (AI) planning engine module 163, a large-region policy gateway module 164, and an EGW and regional statistics management module 165. Data connectors may include a data connector 166 to one or more EGWs 120, a data connector 167 to a central management platform 170, and an optional data connector 168 to external service providers in the large region. Data inputs may include EGW relationship data describing relationships, such as the relative position of one EGW to another, cross-EGW trajectory correction data, cross-region event processing data, traffic balance data, accident impact reduction data, and large-region road status analysis data.

[0088] Each EGW 120 managed by NCE 160 is configured to transmit its local data for aggregation and extraction by NCE 160, where NCE 160 processes the aggregated and extracted data to provide one or more of the following: EGW determination of road management strategies for a geographic area; EGW determination of regional traffic management for a geographic area; and coordination and management of the multiple EGWs. The collaboration engine module 162 is a software module within NCE 160 configured to receive data input and process EGW relationship data, cross-EGW trajectory correction data, cross-regional event processing data, traffic balance data, and accident impact reduction data. It can also process large-area road condition analysis data. The artificial intelligence (AI) planning engine module 163 is a software module within NCE 160 configured to receive all data uploaded from EGWs 120 to the data pool 161 and apply machine learning to this data. Machine learning can include supervised learning and can be performed offline. One output of the artificial intelligence (AI) planning engine module 163 includes strategies, formulas, and rules for application by the collaboration engine module 162. The artificial intelligence (AI) planning engine module 163 can also be configured to attempt to determine any relationships between any of the EGWs 120 to assist the cooperation engine module 162 in determining areas or regions affected by, for example, traffic events. It should be understood that, for example, traffic congestion in one defined geographic area 110A, B is likely to have a greater impact or effect on adjacent local areas 110A, B than on more remote areas. The large-area policy gateway module 164 is a software module within the NCE 160 that is configured to receive configuration / rule / policy data from the V2X central management platform 170 and may also be configured to receive policy data from large-area service providers via open standard APIs. The EGW and regional statistics management module 165 is a software module within the NCE 160 that is configured to receive data from the cooperation engine module 162 and send this data to each of the EGWs 120.

[0089] Figure 6This figure shows the structure of the central management platform 170, its connections to other system entities, and some of its information / data inputs. The central management platform module 170 communicates directly with multiple NCEs 160 and indirectly with multiple EGWs 120. Central management platform module 170 includes a planning / policy configuration module 171, a wide-area V2X data analysis module 172, and a reporting system module 173. Modules 171, 172, and 173 comprise software modules within the central management platform module 170. The central management platform module 170 aggregates and extracts data from the NCE 160 and the EGW 120, and processes the aggregated and extracted data to provide one or more of the following: providing road management strategies for the determined geographic areas 110A, B of the EGW 120; providing regional traffic management across the NCE 160 for the determined geographic areas 110A, B of the EGW 120; directly coordinating the multiple NCEs 160 and indirectly coordinating the multiple EGWs 120; providing centralized management of the NCE 160, EGW 120, and RSU 130; providing centralized management of multiple data sources located within each determined geographic area 110A, B; providing centralized vehicle-to-everything (V2X) network management; providing traffic analysis for the determined geographic areas 110A, B; and providing regional traffic analysis for the NCE 160.

[0090] Figure 7A flowchart is provided of the information flows and processes performed by the EGW 120. At 201, statistics from the ICGW 150 for all vehicles 140 located within the geographic area 110A, B of the EGW 120, along with any event report data from the ICGW 150 at 202, are transmitted by V2I via the corresponding RSU 130 to the RSU data connector 126 of the EGW 120. At 203, data collected by the corresponding RSU 130 from relevant data sources within the geographic area 110A, B, along with any event data detected by the RSU 130 sensors at 204, is transmitted to the data connector 126 of the EGW 120. At 205, the data received at the data connector 126 is aggregated and stored in the data pool 121. Some or all of the aggregated data is passed to the AAE 122, which performs several functions, including updating the real-time status of all entities within the area at 206. At 207, if the update step 206 identifies or detects an emergency event, data describing the event is forwarded to 208 to determine, for example, whether an alarm should be generated. If it is determined at 208 that an alarm should be generated, a further determination can be made at 209 whether the alarm should be considered a high-priority alarm. In either case, the alarm data is transmitted to the target vehicle 140 via the corresponding RSU 130. It should be understood that this is done in real time, or at least with very low latency, less than 100ms. Furthermore, if it is determined at 208 that an alarm should be generated, the method can include determining at 210 whether guidance data or even action data should be generated for the vehicle 140. This can include determining at 211 guidance data or action data for a specific vehicle 140 in the geographic area 110A, B. Such guidance data or action data is transmitted to the target vehicle 140 via the corresponding RSU 130. Action data can include data that enables the target vehicle 140 to act autonomously without human intervention. For example, if a pedestrian is sensed at or near a crosswalk, particularly if the pedestrian is sensed to be in a vulnerable position at or near the crosswalk, the action data may enable the target vehicle to autonomously slow down before reaching the crosswalk.

[0091] In addition to determining or detecting an emergency event at 207, the AAE 122 can be configured to calculate useful statistics, such as traffic statistics, at 212, and can include determining the useful statistics to be sent to one or more NCEs 160 at 213. The statistics generated at 212 can, in turn, be used to calculate traffic travel times for each road in the geographic areas 110A and 110B at 214, calculate potential congestion times at 215, and calculate other meaningful statistics or parameters of traffic conditions in the geographic areas 110A and 110B at 216. The data generated at each or any of 214, 215, and 216 can also be used to generate alerts and / or guidance / actions for the target vehicle 140. Guidance data and / or action data can also be transmitted to the target vehicle 140 by other vehicles using V2V.

[0092] Figure 8 A flow chart of the information flows and processes performed by the NCE 160 is provided. At 301, each EGW reports statistical data, including but not limited to status report data, event report data, and congestion report data, and transmits the data to its NCE data connector / interface 127 (NCE EGW data connector 166). At 302, the data is aggregated and stored in the NCE data pool 161. Some or all of the aggregated data is forwarded to the collaboration engine module 162, although in an optional step of 303, the data may be filtered and corrected. In addition, map data may be input at 304. At 305, optional data inputs to the collaboration engine module 162 may include AI recommendation inputs from any of the EGW artificial intelligence (AI) planning engine module 123, the NCE artificial intelligence (AI) planning engine module 163, the central management platform planning / policy configuration module 171, the wide area V2X data analysis module 172, or the reporting system module 173. At 306 , optional data input to the collaboration engine module 162 may include manually defined relationship data, such as spatial relationships between the EGWs 120 and their respective geographic regions 110A,B.

[0093] At 307 , the collaboration engine module 162 receives multi-EGW status data from the EGW data pool 121 . Based on this data and, optionally, on the EGW relationship data received at 308 , the collaboration engine module 162 may determine at 309 whether any emergency events have been detected. If so, at 310 , it may determine one or more areas and corresponding EGWs 120 affected by the event, and determine actions and / or alerts to trigger for each affected EGW 120 . These actions and / or alerts may include, but are not limited to, "send alert" at 312 , "generate congestion reduction guidance" at 313 , "reduce the impact of the emergency" at 314 , and "other commands to vehicles" at 315 . Once the actions and / or alerts are determined, they are issued to the affected EGWs 120 via the EGW data connector / interface 166 .

[0094] The cooperation engine module 162 may also use the multi-EGW state data and optional EGW relationship data to estimate 316 the travel time for each EGW area, 317 the estimated potential congestion for each EGW area, and any one or more other meaningful statistics 318. The travel time for the EGW area and the estimated potential congestion for the EGW area may be used 319 to determine whether congestion is detected, and this data may be used to determine one or more areas and corresponding EGWs 120 affected by the event at 310, and to determine actions and / or alarms to be triggered for each affected EGW 120. Other meaningful statistics may be used to determine any other detected events at 320, and this data may also be used to determine one or more areas and corresponding EGWs 120 affected by the event at 310, and to determine actions and / or alarms to be triggered for each affected EGW 120.

[0095] In the following description, AAMS 400 will be described as Figures 1 to 8 Like numbers are used to represent like parts. However, it should be understood that the AAMS 400 can be implemented in any suitable road management system.

[0096] Figure 9 An intersection 330 is shown where a first lane (road) 335 intersects a second lane 338. However, in this example, the two lanes 335 and 338 do not physically intersect to form an intersection because the first lane 335 is elevated, crossing over the second lane 338. Thus, traffic on the first lane 335 does not directly impede traffic on the second lane 338, and vice versa. In contrast, if the first and second lanes 335 and 338 did physically intersect to form an intersection (not shown), a traffic control device, such as a traffic light, would be necessary at the intersection of the two lanes 335 and 338 to control traffic flow.

[0097] exist Figure 9 In the example scenario, first vehicle 336 in box A on first lane 335 may detect the presence of another vehicle 339 in box B on second lane 338 and issue an alert to the driver of first vehicle 336, alerting them to the approaching second vehicle 339. However, it should be understood that such an alert is redundant because, from a traffic management / safety perspective, the detected proximity of first and second vehicles 336, 339 is irrelevant, for example, since a collision between first and second vehicles 336, 339 is unlikely. Therefore, such an alert would constitute a false alarm for the driver of first vehicle 336. The probability of issuing such a false alarm may be higher if first vehicle 336 first enters the defined geographic area of intersection 330 encompassing first and second lanes 335, 338, particularly if first vehicle 336 does not or has not yet received up-to-date map data, static environmental data, and / or sensor data for the defined geographic area, or at least the area surrounding intersection 330. In this example scenario, first vehicle 336 has limited data with which to process the detected proximity of second vehicle 339 and determine whether to issue an alert to the driver. Furthermore, in this example scenario, other vehicles (not shown) that do not have relevant map data and / or static environment data and / or sensor data may also issue intersection alerts not only to their respective drivers but also to system 100 entities (e.g., RSU 130 and EGW 120). For a number of reasons, it is undesirable for a vehicle to generate such false alerts.

[0098] exist Figure 10 In an example scenario, a first vehicle 350 is traveling around a curve in a lane 352 or around a roundabout. As it does so, it detects a roadside object or obstacle 354 in one of the vehicle's blind spots and mistakenly identifies the object or obstacle 354 as another vehicle, thereby issuing a left blind spot alert to the vehicle driver in this example scenario. Once again, in this example scenario, it can be seen that the alert issued is a false alert. If the vehicle had received relevant map data and / or static environment data and / or sensor data indicating the presence of the object or obstacle 354, issuing such an alert could have been avoided, or at least the occurrence of such false alerts could have been reduced.

[0099] The AAMS 400 is configured to receive a vehicle-generated alert and, using any relevant map data and / or static environmental data and / or sensor data, determine whether the vehicle-generated alert is a false alert, and then transmit data regarding or associated with the false alert to other vehicles 140 and user devices 180 via the RSUs 130 in the system 100 in order to reduce or even prevent similar such false alerts from being issued in the future.

[0100] Figure 11 A block diagram is shown of the AAMS 400 and its connections to some of the other entities 130, 190 in the system 100. The black box surrounding the AAMS 400 can be considered to define a defined geographic area 110 containing at least one RSU 130, but it should be understood that the diagram is not drawn to scale and that the defined geographic area 110 may be much larger than shown and contain multiple RSUs 130, multiple roadside sensors 190, such as road infrastructure systems and equipment, and at least one EGW (not shown).

[0101] AAMS 400 includes a map data unit 405 that includes map data defining a geographic area 110, or at least an area surrounding at least one RSU 130. AAMS 400 is shown connected to at least one RSU 130, however, it is understood that AAMS 400 may be part of EGW 120 and implemented via machine code stored in memory 122 and executable by processor 124 of EGW 120. In other embodiments, AAMS 400 may be a standalone device that is communicatively connected to RSU 130 and to one or more roadside sensors 190 via V2X networks 102, 103, 104. Therefore, AAMS 400 preferably includes a communication unit 410 for managing communications between AAMS 400 and system entities such as RSU 130 and roadside sensors 190. AAMS 400 also includes an alert analysis unit 415 configured to receive alerts generated by vehicles. The AAMS 400 preferably includes a static environment data unit 420 that includes static environment data defining the geographic area 110 or at least an area surrounding at least one RSU 130 .

[0102] It should be understood that all or any units constituting the AAMS 400 may be implemented by machine codes stored in a memory device and executed by a processor.

[0103] In a first approach, upon receiving a vehicle-generated alert, alert analysis unit 415 processes the received vehicle-generated alert to determine whether the alert is a false alarm. Alert analysis unit 415 is configured to use the location associated with the vehicle-generated alert to obtain map data for a defined area surrounding the location of the vehicle-generated alert from a map data unit, and / or use the location associated with the vehicle-generated alert to obtain static environmental data for the defined area surrounding the location of the vehicle-generated alert, and / or retrieve sensor data for the defined area surrounding the location of the vehicle-generated alert based on the location and time of the vehicle-generated alert. The predetermined size of the defined area surrounding the location of the vehicle-generated alert can be significantly smaller than the defined geographic area 110, or can have a dynamically determined smaller size depending on the relative locations of system entities, such as RSU 130 and / or roadside sensors 190, that are considered relevant to the vehicle-generated received alert. There are various methods for statically or dynamically determining the size of the area surrounding the location of the vehicle-generated alert, which may include taking into account the locations and / or groups of previously determined false alarms.

[0104] In any case, the alert analysis unit 415 determines whether the received vehicle generated alert is consistent with the acquired and / or retrieved data for the determined area around the location of the vehicle generating the alert. Figure 9 In the example scenario of , the alert analysis system 415 may determine that the received intersection alert generated by the vehicle lacks consistency with the relevant map data because the first lane 335 crosses over the second lane 338, i.e., they do not actually cross each other at an intersection. Figure 10 In an example scenario, the alert analysis system 415 may determine that a received vehicle-generated blind spot alert lacks consistency with the associated static environmental data, as the static environmental data includes data identifying the location and, possibly, the type of roadside object or obstacle 354. Upon determining that the received vehicle-generated alert lacks consistency with the associated acquired and / or retrieved data for the identified area surrounding the vehicle-generated alert location, the alert analysis system 415 records the received vehicle-generated alert as a false alarm. The alert analysis system 415 may also utilize roadside sensor data for the identified area surrounding the vehicle-generated alert location, alone or in any combination with associated map data and associated static environmental data. An example scenario involves a received vehicle-generated alert that detected a pedestrian at an intersection or a cyclist along the outside edge of a lane, but the associated roadside sensor data indicates that the detection was erroneous or the reason for the detection no longer exists (e.g., the pedestrian has left the intersection and is on the sidewalk), resulting in the generated alert being a false alarm.

[0105] Figure 12Some data paths between the AAMS 400 and other system entities in the road management system 100 are shown. As can be seen, the AAMS 400 preferably receives vehicle-generated alerts via at least one RSU 130. This has at least one advantage: it enables the RSU 130 to Figures 1 to 8 The system 100 processes alerts in the manner described, and enables the AAMS 400 to process the received vehicle generated alerts to determine whether any such received alerts are false alerts. The received alerts may include different types of alerts, such as Figure 12 Indicated as "A", "B" or "T". Figure 12 It is also illustrated that roadside sensors 190 can transmit data to update static environment data managed by static environment unit 420. In addition, real-time sensor data or stored sensor data can be transmitted to a "time-space" or "time-position" database 425, which stores roadside sensor data generated by location and time, and may also have roadside sensor data generated by other parameters such as event type.

[0106] Figure 13A flowchart shows another method 500 for reducing false vehicle-generated alerts. In the first step 505 of method 500, upon receiving a vehicle-generated alert, alert analysis unit 415 uses the location associated with the vehicle-generated alert to retrieve map data for a defined area surrounding the location of the vehicle-generated alert from map data unit 405. The retrieved map data may include road attributes and locations, intersection locations and types, traffic signal locations and locations, boundaries, and the like. In the second step 510, alert analysis unit 415 uses the type of vehicle-generated alert received to retrieve map data for a defined area surrounding the location of the vehicle-generated alert, which is associated with or related to the type of vehicle-generated alert. In any case, in the third step 515, alert analysis unit 415 then determines whether the received vehicle-generated alert is consistent with the associated map data for the defined area surrounding the location of the vehicle-generated alert. If, in the third step 515, alert analysis unit 415 determines that there is a lack of consistency between the received vehicle-generated alert and the associated map data, it records the received vehicle-generated alert as a false alert and generates a false alert map and / or updates the false alert map data in map data unit 405. The AAMS 400 may also transmit the false alarm and / or false alarm map data to at least one RSU 130, and / or one or more ICGWs 150 of the vehicle 140, and / or one or more V2X devices 180 in the determined geographic area 110, or in the coverage area of the RSU 130, or in a determined area around the location where the vehicle generated the alarm. For any false alarm, the updated false alarm data may include any one or more of the following: location, such as global positioning system (GPS) location data; type, such as intersection alert; and / or reason, such as "not an intersection."

[0107] If, in third step 515, alert analysis unit 415 does not determine a lack of consistency between the received vehicle-generated alert and the associated map data, the method proceeds to fourth step 520, where alert analysis unit 415 obtains static environmental data for a defined area surrounding the location of the vehicle-generated alert from static environmental data unit 420. Static environmental data may include data defining any features that generally do not change over time, such as static objects and obstacles, and may include, for example, long-standing road works. In fifth step 525, alert analysis unit 415 uses the type of received vehicle-generated alert to obtain, from static environmental data unit 420, only static environmental data for the defined area surrounding the location of the vehicle-generated alert that is associated or relevant to the type of received vehicle-generated alert. In any case, in sixth step 530, alert analysis unit 415 then determines whether the received vehicle-generated alert is consistent with the associated static environmental data for the defined area surrounding the location of the vehicle-generated alert. If, in the sixth step 530, the alarm analysis unit 415 determines that there is a lack of consistency between the received vehicle-generated alarm and the relevant static environment data, the received vehicle-generated alarm is recorded as a false alarm and a false alarm map is generated, and / or the false alarm map data in the map data unit 405 is updated. The AAMS 400 may also transmit the false alarm and / or the false alarm map data to at least one RSU 130, and / or one or more ICGWs 150 of the vehicle 140, and / or one or more user devices 180 in the determined geographic area 110, or in the coverage area of the RSU 130, or in a determined area around the location of the vehicle-generated alarm.

[0108] If, in step 630, the alert analysis unit 415 does not determine a lack of consistency between the received vehicle-generated alert and the associated static environmental data, the method proceeds to step 735, where the alert analysis unit 415 retrieves roadside sensor data from one or more sensors 190 for a defined area around the location of the vehicle-generated alert, based on the location and time of the vehicle-generated alert. The roadside sensor data may be retrieved from the temporal-spatial database 425. This data may be processed offline in the temporal-spatial database 425 and / or the alert analysis unit 415. In step 840, the alert analysis unit 415 processes the retrieved roadside sensor data to select data related to any combination of the location, speed, direction, and type of objects within the defined area around the location of the vehicle-generated alert. These objects preferably include any other vehicles 140 located within the defined area around the location of the vehicle-generated alert. In any case, in step 945, the alert analysis unit 415 then determines whether the received vehicle-generated alert is consistent with the retrieved sensor data. Step 945 of the method may be based on the type of vehicle-generated alert received. If, in the ninth step 545, the alarm analysis unit 415 determines that there is a lack of consistency between the received vehicle-generated alarm and the relevant sensor data, the received vehicle-generated alarm is recorded as a false alarm and a false alarm map is generated, and / or the false alarm map data in the map data unit 405 is updated. The AAMS 400 may also transmit the false alarm and / or the false alarm map data to at least one RSU 130, and / or one or more ICGWs 150 of the vehicle 140, and / or one or more user devices 180 in the determined geographic area 110, or in the coverage area of the RSU 130, or in a determined area around the location of the vehicle-generated alarm.

[0109] If, at the ninth step 545 , the alert analysis unit 415 does not determine a lack of consistency between the received vehicle-generated alert and the associated sensor data, the method 500 outputs that the received vehicle-generated alert is not a false alert.

[0110] In such Figures 14 to 16 The enhancement of the method shown is preferably in the enhancement method 600 ( Figure 16 ) in a first step 605, grouping false alarms into corresponding groups 550 (within the determined geographic area 110 or within another determined area within the determined geographic area 110) by alarm type. Figure 14 ). The other determined area is smaller than the determined geographic area 110 and may include an area that is the same as or similar to the determined area around the location where the vehicle generated the alert. The enhanced method 600 may include determining parameters for each respective group 550 of false alerts.

[0111] Figure 14The enhanced method 600 is shown to group false alarms. Figure 14 The dotted circles define the size of each group 550 of false alarms, the "X" 555 represents the location of the false alarms within each group 550, and the circular black dots represent the parameters determined for each group 550 of false alarms. The parameters preferably include the location center 560 of each group 550.

[0112] The alarm analysis unit 415 is preferably configured to group the false alarms by alarm type into clusters 550 using a density-based spatial clustering of applications with noise (DBSCAN) algorithm, which uses one or more of the following as input data: false alarm location latitude data; false alarm location longitude data; vehicle speed associated with the false alarm; vehicle direction associated with the false alarm; or road lane data of the vehicle associated with the false alarm. Other false alarm data inputs may also be included.

[0113] Alarm analysis unit 415 is preferably configured to determine the center 560 of each respective cluster 550 using a K-means algorithm.

[0114] In the second step 610 of the enhancement method 600 , the alarm analysis unit 415 is configured to determine the confidence C of the false alarms of each corresponding group 550 based on the relevance of the geographic information R of the false alarms in each corresponding group 550 and the relevance of the impact factor I of the false alarms in each corresponding group 550 .

[0115] The relevance of the geographical information R of the false alarms in each respective group 550 is preferably obtained from:

[0116] R=1-Avg(L1,L2,L3,……L N ) / Max(L1,L2,L3,……L N )

[0117] Where N is the number of false alarms in group 550;

[0118] L N is the deviation or distance of each false alarm from the center 560 of the cluster 550;

[0119] 0 <R<1。

[0120] The closer R is to 1, the higher the confidence C. Multiple false alarm locations close together will result in a high value for R in the range of 0 to 1. Multiple false alarm locations in connected areas with the same attributes (such as the same lane) will also result in a high value for R in the range of 0 to 1.

[0121] exist Figure 15 , N=6, that is, L1, L2, L3, L4, L5 and L6 are the corresponding deviations or distances of six false alarm locations (respectively represented as “X”) from the center 560 of the group 550.

[0122] The relevance of the impact factor I of the false alarms in each respective group 550 is preferably obtained from:

[0123]

[0124] Where M is the number of impact factors;

[0125] Where N is the number of false alarms in group 550;

[0126] S j is the impact factor;

[0127] in It's S j The average value of

[0128] 0 <C<1。

[0129] The closer I is to 1, the higher the confidence C. The greater the similarity of the influence factors S of the false alarms in each corresponding group 550, the higher the I value.

[0130] However, it is understood that there is no limit to the number of influencing factors S that can be used, as the greater the number of influencing factors S, the more accurate the results obtained.

[0131] For example, in Figure 15 Where N = 6, considering that speed S1 and direction S2 are the only two influencing factors, is the speed of the false alarm vehicles in the group The average value of is the direction of the vehicle with the false alarm in the group The average value of , so the correlation formula of impact factor I is:

[0132]

[0133] The confidence C of each group 550 is preferably given by C= R x IIn the third step 615 of the enhanced method 600, the alarm analysis unit 415 is configured to compare the confidence C of each group 550 with a predetermined, calculated, or selected threshold H, so that if C>H, the AAMS 400 transmits the false alarm-related data of the corresponding group 550 to at least one RSU 130 and / or one or more ICGWs 150 of vehicles 140 in the determined geographic area 110 or in the coverage area of the RSU 130 or in the determined area around the location where the vehicle generated the alarm, for transmission to the one or more onboard data processing units of the corresponding group. In one embodiment, when C>H of the group 550, the AAMS 400 transmits the false alarm-related data of the corresponding group 550 to at least one RSU 130, which then broadcasts the data to the ICGWs 150 of the vehicles 140 and / or the user devices 180 in the determined geographic area 110. With the broadcast information, the ICGW 150 and / or user device 180 of the vehicle 140 can make decisions locally in a manner that reduces or even avoids the occurrence of false alarms. Thus, each ICGW 150 and / or user device 180 can make decisions based not only on its local awareness of the environment, but also taking into account data related to previous false alarms generated by other ICGWs and / or user devices 180, thereby at least reducing the occurrence of such false alarms.

[0134] The road management system 100 including the AAMS 400 may include a vehicle-to-everything (V2X) software system. The road management system 100 including the AAMS 400 may include a road safety management system.

[0135] A significant advantage of the system 100 of the AAMS 400 is that it significantly reduces the communication bandwidth between entities within the system 100 and reduces the computational load on entities such as the RSU 130 and EGW 120 by reducing or avoiding the issuance of false alarms.

[0136] In the following description, a system for controlling traffic data transmission in a 5G-V2X network will be described as follows: Figures 1 to 16 100 is implemented in an embodiment of the system 100. Like numbers will be used to represent like parts. However, it should be understood that Figures 1 to 16 The system may be implemented in any suitable road management system.

[0137] refer to Figure 17, a system 700 for controlling the transmission of traffic data in a 5G-V2X network includes a transmission controller (TC) 710. The TC 710 is preferably located in an edge node, such as the EGW 120 that determines the geographic area 104, but in some embodiments, the TC 710 can be a standalone device that is communicatively connected to the EGW 120 via one or more channels of the 5G-V2X network. The TC 710 includes an experience analyzer module 715 for processing historical traffic data to generate a transmission control strategy and a real-time analysis module 720 for processing real-time traffic data to adjust the transmission control strategy. The TC 710 preferably also includes a database 725 for storing traffic and related data, including historical data. Connected to the TC 710 are: a network monitor 730 that monitors, measures and / or determines operating parameters of the 5G-V2X network, including measuring network delay d values; a map server 735 or database that provides map data to the TC 710, describing any RSU 130, TSD 740 (in Figure 17 and a device information interface 750 that inputs traffic data received from at least the TSD 740 via one or more 5G channels to at least the experience analyzer module 715.

[0138] A data processor 755 is also preferably provided in communication with the TC 710. The data processor 755 can be part of the EGW 120 or can be a standalone device. The data processor 755 is configured to receive raw data from a plurality of roadside-based transport control modules (TRMs) 760 that determine the geographic area 104 and process the raw data to provide structured traffic data to the TC 710. The raw data can be transmitted as a point cloud and / or image, which requires more bandwidth to transmit and more computing power to process than processed structured data. The structured traffic data can include any one or more of the following: the speed of a moving traffic object detected by each of a plurality of TSDs; the location of each detected moving traffic object; the timestamp of each detected moving traffic object; the number of detected traffic alerts; the location of each detected traffic alert; the timestamp of each detected traffic alert; the number of detected traffic incidents; the location of each detected traffic incident; and the timestamp of each detected traffic incident. One advantage of this arrangement is that the system's computing power is more efficiently utilized because the raw data is processed by the data processor 755 rather than by a processor provided by, for example, the RSU 130. Processing raw data such as point clouds and / or images requires considerable computing power. Allocating such computing power to the RSU 130, etc., would be a waste of such resources, particularly during periods of low traffic flow, and might not be able to process the raw data during periods of high traffic flow (e.g., rush hour).

[0139] The TRM 760 collects traffic data from the TSD 740 according to the transmission control policy generated by the TC 710. The TRM 760 also transmits the traffic data received from the TSD 740 as raw data via one or more 5G channels to the EGW 120 including the TC 710 according to the transmission control policy. The TRM 760 transmits the received traffic data to the data processor 755 (if present), or directly to the TC 710 in the EGW 120 (if no dedicated traffic data processor 755 exists).

[0140] TC 710 dynamically adjusts the traffic data transmission frequency of one or more TSDs 740 according to the transmission control policy by transmitting the transmission control policy to TRM 760. The transmission control policy generated by TC 710 includes a transmission policy for each corresponding TSD 740. Based on the transmission policy, TRM 760 dynamically adjusts the traffic data transmission frequency of each TSD 740 according to the corresponding transmission policy of each TSD. TC 710 can transmit the transmission control policy to TRM 760 via a policy command.

[0141] like Figure 18 As shown, TRM 760A can be configured to apply the transmission control policy to a single related TSD 740A. TRM 760A can be located near or in conjunction with TSD 740A and apply the corresponding transmission policy of TSD 740A provided by the transmission control policy generated by TC 710 to the TSD 740A. In some embodiments, multiple TSDs 740B (in Figure 18 ) are arranged in a certain geographical area 104, close to each other, for example, at or near a traffic intersection, the TSDs 740B may form a group and be served by a single TRM 760B. The single TRM 760B is configured to apply the transmission control policy generated by the TC 710 to each TSD 740B in the group of TSDs 740B. In a similar manner, Figure 18 The grouped TSDs 740C are also served by a single TRM 760C, but in this example the grouped TSDs 740C are fewer in number than the grouped TSDs 740B. Grouping the TSDs 740 in this manner reduces the number of TRMs 760 required to determine the geographic area 104.

[0142] Figure 19 The comparative complexity of the local areas represented by dashed circles 800A and 800B, respectively, within the determined geographic area 104 monitored by the respective TSDs 740', 740" is shown.

[0143] In local area 800A, designated "Area 1," TSD 740' can be seen monitoring the intersection between a first lane 805 and a second lane 806. In this example, a first vehicle 810A, designated "Car 1," is approaching the intersection along first lane 805, while a second vehicle 810B, designated "Car 2," is approaching the intersection along second lane 806. It should be understood that intersections between lanes are more likely to present traffic problems, including accidents, than straight-through sections of lanes. Compared to if first vehicle 810A and second vehicle 810B were traveling toward each other in opposite lanes on a straight-through section, vehicles 810A and 810B are more likely to interfere with each other at the intersection, potentially triggering the issuance of one or more traffic alerts. At the intersection of lanes 805 and 806, first and second vehicles 810A and 810B may also encounter pedestrians attempting to cross lanes 805 and 806, which may trigger other traffic alerts, etc.

[0144] By comparison, in the local area 800B designated as "Area 2," it can be seen that the TSD 740" is monitoring the straight segment of the first lane 805. In this example, only one vehicle 810C is traveling along the straight segment of lane 805, away from the intersection. In this case, the likelihood of an event resulting in the need to issue a traffic alert is much lower.

[0145] from Figure 19 It can be understood from the scenario comparison that the first and second vehicles 810A, B and any other vehicles traveling in "Area 1" may need or expect to obtain more traffic data of "Area 1" from TSD 740' compared to the user of vehicle 810C in "Area 2" in order to generate useful information for its users.

[0146] The system and method of the present invention provides a novel method for adjusting the relative frequency of traffic data transmissions of TSDs such as TSDs 740 ′, 740 ″.

[0147] Figure 20 A flow chart is shown of a method 900 performed by a TRM 760 to update the transmission frequency of one or more of its associated TSDs 740 when the TRM 760 receives a new transmission policy for said TSDs 740 from a TC 710 .

[0148] In a first step 905 of the method 900, the TRM 760 receives an updated transmission control policy from the TC 710. The updated transmission control policy includes or comprises a new transmission policy for one or more TSDs 740 associated with the TRM 760. In this example of the method 900, for ease of description, it will be assumed that the TRM 760 serves a single TSD 740, but the method is equally applicable to a TRM 760 serving a group of TSDs 740.

[0149] During normal operation, the TRM 760 receives traffic data from the TSD 740, which is then transmitted by the TRM 760 to the data processor 755 or directly to the TC 710 via a 5G channel. The received traffic data is transmitted by the TRM 760 according to the transmission frequency f defined by the transmission policy generated for the TSD 740. That is, the traffic data received by the TRM 760 from the TSD 740 is received and transmitted after the time period defined by the transmission frequency f of the TSD's transmission policy has expired. This is achieved by the TRM 760 sampling data from the TSD 740 or the RSU 130 associated with the TSD 740 upon the expiration of the time period defined by the transmission frequency f of the TSD's transmission policy, and then immediately transmitting the data, thereby ensuring that the data is up-to-date for real-time applications. This process is repeated upon the expiration of a subsequent time period defined by the transmission frequency f. If the TSD's transmission policy has not changed, the countdown period will have the same value, i.e., the same transmission frequency.

[0150] In update method 900, in a first step 905, TRM 760 receives the updated transmission policy of TSD 740. Then, in a second step 910, TRM 760 updates the transmission frequency f of TSD 740 based on the updated transmission policy. In a third step 915 of method 900, TRM 760 immediately updates the waiting time for the next transmission of sampled traffic data received from TSD 740. As a result of updating the waiting time in third step 915, TRM 760 applies the updated transmission policy to TSD 740. In the fourth step of method 900, in decision step 920, TRM 760 determines whether the updated waiting time has expired. If it has not expired, then in a fifth step 925, TRM 760 continues to count down the updated waiting time. Once it is determined in decision step 920 that the updated waiting time has expired, TRM 760 transmits the sampled traffic data. This involves receiving sampled traffic data from the TSD 740 at the expiration of the countdown period in a sixth step 930 and sending the traffic data to the data processor 755 or directly to the TC 710 in a seventh step 935 .

[0151] The transmission control policy generated by the TC 710 is preferably initially based on processing of historical traffic data by the experience analyzer module 715. In practice, the experience analyzer module 715 predicts or recommends a general, stable transmission control policy derived from the historical traffic data. In some embodiments, only such a network of transmission control policies may be required to achieve stable operation of the system 100. The historical traffic data may include traffic data 740 received at the TC 710 from some or all of the TSDs via the device information interface 750, and may also include data received from some or all of the RSUs 130 or some or all of the other traffic sensors 745.

[0152] The experience analyzer module 715 preferably continues to process the historical traffic data and any new traffic data received at the TC 710 and stored in the database 725 to update the general transmission control strategy. The general transmission control strategy includes the general transmission frequency f of the traffic data. g , which is updated continuously or periodically. The corresponding common transmission frequency value f of traffic data g Initially, it is applied to all TSDs 740 to practically implement the stable transmission of real-time traffic data of the TSDs 740 in the network system 100. For each TSD 740, the universal transmission frequency value f of the traffic data g may be the same, but due to the individual circumstances of each TSD 740, the universal transmission frequency value f g There may be variations between TSDs 740. However, events may occur that require dynamic adjustment of the transmission frequency of at least some TSDs 740.

[0153] In one embodiment, a universal transmission frequency value f of traffic data is determined or calculated. g One method is based on historical traffic data relating to vehicle speeds and the number of traffic warnings and / or traffic accidents for a selected time period.

[0154] Assume that the speed of a moving traffic object such as a vehicle is v, and the safe distance between vehicles is set to D s (e.g., empirical maximum braking distance / 2), then the frequency of safety traffic data transmission for tracking vehicles will be: f s =v / D s , where f s The 24 hours of a day are divided into T time periods. In each time period t, the average speed of the moving traffic objects detected by the TSD 740 in the relevant local area of the determined geographic area 104 is The number of accidents is a t , the number of alarms is b t Therefore, the risk level r is given by:

[0155] r t =C1 / (1+e -at )+C2 / (1+e -bt )

[0156] Where C1+C2==1,r t ∈[0.5,1];

[0157] C is the weighting coefficient.

[0158] The experience analysis module 715 calculates the general transmission frequency value f of traffic data in each time period t according to the following formula: g : In a short period of time like half an hour, the speed of an object usually does not fluctuate greatly, so in most cases, To calculate f g However, if the speed fluctuates greatly, then use the maximum speed v t max A certain proportion of will be more conducive to detecting high-speed moving traffic objects. If the speed fluctuation is small, then use the minimum speed v t min A certain percentage of can help save network resources. Generally speaking, if we consider the traffic conditions of day i, then the general traffic data transmission frequency will be:

[0159] f g t =∑ i f g t / i.

[0160] The generated transmission control policy can then be dynamically adjusted based on the subsequent processing of real-time traffic data by the real-time analysis module 720, which is preferably received at the TC 710 via the TRM 760. The real-time analysis module 720 preferably continuously monitors recent (real-time) traffic data to adjust the transmission frequency of the selected TSD 740 based on, for example, issued traffic alerts and the proximity of any selected TSD 740 to the location of the traffic alert. In this example, the traffic alert may include a traffic emergency.

[0161] It is contemplated that dynamic adjustment of the transmission frequency of the TSD 740 may be limited to the TSD 740 in one or more small localized areas 800 within the determined geographic area 104, depending on traffic events, such as alerts and emergencies.

[0162] The TC 710 is preferably located in the EGW 120 because the EGW 120 generally has more computing power than distributed devices such as the TRM 760 and / or the RSU 130 .

[0163] Figure 21 A schematic block diagram of the real-time analysis module 720 of the network system 100 is shown, which implements the following three main processes: (1) updating the transmission frequency of the selected or source TSD 740 in response to real-time data describing parameters of detected moving traffic objects; (2) updating the transmission frequency of the target TSD 740 in response to real-time data describing parameters of detected moving traffic objects; and (3) updating the transmission frequency of the selected or target TSD 740 in response to one or more measured network parameters. The real-time analysis module 720 includes a policy change check module 765. The policy change check module 765 checks whether the transmission policy of the TSD 740 needs to be changed. Preferably, the transmission frequency of the selected or target TSD 740 is updated only after the policy change check module 765 performs its check.

[0164] When receiving real-time traffic data describing detected moving traffic objects from the TSD 740, the real-time analysis module 720 analyzes the current traffic status and appropriately calculates the corresponding new data traffic transmission frequency for each device, which will be referred to below. Figure 22 In the event of a dangerous situation where a moving traffic object such as a speeding vehicle is detected, it is desirable that the real-time analysis module 720 notify the relevant or target TSD 740 and / or determine a new corresponding transmission strategy for the relevant or target TSD 740, which will be referred to below. Figure 23 The network monitor 750 measures parameters of the 5G-V2X network, including the transmission delay d between the TRM 760 and the EGW 120. In the event that the transmission delay d is longer than a predetermined or preset value, the real-time analysis module 720 calculates a new corresponding transmission strategy for the selected or target TSD 740a, which will be referred to below. Figure 24 Describe more fully.

[0165] refer to Figure 22 , the first method 1000 ( Figure 21 Method 1) in the embodiment of the present invention begins at step 1005, where the data processor 755 sends structured traffic data describing mobile communication objects to the real-time analysis module 720. The structured traffic data provided by the data processor 755 is generated from raw traffic data received by the TRM 760 from its associated TSD 740. The structured traffic data describes at least the speed of the mobile communication object and the location of the object. Other data input to the real-time analysis module 720 includes the general data traffic transmission frequency f calculated by the empirical analysis module 720 at step 1010. gand the map data provided by the map server 735 in step 1015. In step 1020, the real-time analysis module 720 calculates the safety traffic data transmission frequency f for the selected or source TSD 740. s Select or source the safety traffic data transmission frequency f of the TSD 740 s The safety traffic data transmission frequency f described previously can be used s =v / D s , where the selected or source TSD 740 tracks only one vehicle. In some embodiments where the selected or source TSD 740 tracks multiple vehicles, it is preferred to use the maximum speed of the tracked vehicles so that the selected or source TSD 740's safety traffic data transmission frequency is f s =v max / D s , where v max is the maximum speed of a moving traffic object (eg, a vehicle) detected within a time stamp period of the selected or source TSD 740. If, in decision step 1025, f is determined for the selected or source TSD 740, s Not greater than f g , then in step 1030, a new traffic data transmission frequency f=f is set for the selected or source TSD 740. g However, if at decision step 1025, it is determined that f s Greater than f g , then the new traffic data transmission frequency f of the selected or source TSD 740 in step 1035 is changed to f=f s Therefore, the new traffic data transmission frequency f for the selected or source TSD 740 will be assigned as f s or f g The value of general traffic data transmission frequency f g The value of is calculated by the experience analysis module 715 as a balance between system performance and power saving. This allows the TSD 740 to operate at a relatively low traffic data transmission frequency most of the time, but this method provides a way to ensure that each TSD 740 can track and detect new moving traffic objects and dynamically adjust the traffic data transmission frequency (f according to the speed of the detected moving traffic objects). s or f g ) ability.

[0166] In decision step 1040, f current is the current traffic data transmission frequency f of the TSD 740 maintained by the policy change check module 765 of the real-time analysis module 720. If it is determined in decision step 1040 that the new value of f from either step 1030 or 1035 is not equal to the current value f of the selected or source TSD current, the real-time analysis module 720 generates a new transmission strategy for the selected or source TSD 740, otherwise the f value of the selected or source TSD 740 remains at f=f current In step 1045, the real-time analysis module 720 sends the new transmission strategy of the selected or source TSD 740 to the TRM 760 associated with the TSD. s Greater than f g , then at decision step 1050, it is determined whether the detected moving traffic object is a dangerous object, that is, whether it poses a threat to other vehicle users. If it is determined at decision step 1050 that the detected moving traffic object poses a threat to other vehicle users, then at step 1055, the real-time analysis module 720 is triggered to implement the second method 1100 ( Figure 21 Determining that the detected moving traffic object poses a threat to other vehicle users may be based on determining a predetermined, selected, or calculated speed limit v for a local area 800 of the geographic area 104. limit The local area 800 may include several TSDs 740. The speed limit of the local area 800 is limit It can be obtained from the map server 735. If the speed v of the moving traffic object detected in the local area 800 is greater than the speed limit v limit and / or greater than the average speed of moving traffic objects in the local area 800 The detected moving object is determined to be a dangerous object. is a multiple of the average speed twice as much.

[0167] refer to Figure 23 , the second method ( Figure 21 Method 2) 1100 in the second method begins at step 1105 by receiving an indication (from method 1) that the detected mobile traffic object is a dangerous mobile traffic object. The second method 1100 focuses on selecting or targeting a TSD 740. The selected or target TSD 740 is a TSD 740 that is determined to be near the detected dangerous mobile traffic object based on the map data provided by the map server 735, that is, a TSD 740 located near the source TSD 740 that first detected the dangerous mobile traffic object and the target TSD that is likely to detect the dangerous mobile traffic object soon.

[0168] Reference here Figure 25, the figure shows a vehicle 810A, designated "Car 1," traveling at the intersection of first and second lanes 805 and 806 in a first local area 800A served by a TSD 740A. Vehicle 810A is represented as a "normal car," meaning it is traveling within the speed limit. Vehicle 810A travels along first lane 805 toward the intersection with second lane 806, and toward a second local area 800B served by a second TSD 740B and a third local area 800C served by a third TSD 740C. In this case, vehicle 810A does not pose a danger to other vehicle users. In this case, there is no need to implement the second method in the real-time analysis module 720.

[0169] For comparison, refer to Figure 26 , where vehicle 810A is traveling toward the intersection of the third lane 807 and the first lane 805 in the second local area 800B. The second TSD 740B detects that vehicle 810A is speeding and therefore determines that vehicle 810A is a dangerous moving traffic object. Therefore, it is necessary to implement the second method in the real-time analysis module 720. However, the second TSD 740B cannot yet determine which route vehicle 810A will take. Figure 26 As shown, upon arriving at the intersection, vehicle 810A may choose to take one of two possible routes. Therefore, the second TSD 740B can be considered the source TSD, and the second method treats the first and third TSDs 740A, C as the selected or target TSDs, despite the fact that only one of the first and third TSDs 740A, C will subsequently detect vehicle 810A, depending on the route vehicle 810A takes at the intersection. Each of the first and third TSDs 740A, C will be notified before source TSD 740B detects speeding vehicle 810A. It should be understood that there may be more than two possible routes for a detected vehicle, but the above is sufficient to illustrate the concepts of source and target TSDs.

[0170] It will be appreciated that while each of the first, second, and third local regions 800A,B,C are shown as including only one TSD 740A,B,C, the local regions 810A,B,C may be larger than suggested and may include multiple TSDs 740 .

[0171] Reference again Figure 23In the next step 1110 of the second method 1100, the real-time analysis module 720 determines which TSD 740 is the source TSD and which TSD 740 is to be considered the selected or target TSD 740, i.e., the TSD 740 that is likely to have detected the dangerous moving traffic object detected by the source TSD 740, based on the map data provided in step 1115. After steps 1110 and 1115, the data processor 755 transmits structured traffic data describing the dangerous moving traffic object and any other moving traffic objects detected by the source and selected or target TSDs 740 in step 1120, which is received by the real-time analyzer module 720 in step 1125. In a manner similar to the first method 1000, the structured traffic data provided by the data processor 755 is generated from the raw traffic data received from the corresponding TRMs 760 of the source and target TSDs 740.

[0172] At decision step 1130 of the second method 1100, it is determined whether the detected dangerous moving traffic object has left the local area or coverage area of the source TSD 740. Once it is determined that the detected dangerous moving traffic object has left the local area or coverage area of the source TSD 740, the next step 1135 of the second method 1100 is to calculate the waiting time w for each selected or target TSD 740. s The waiting time of each selected or target TSD 740 depends on the respective length L of the path from the current detected position of the dangerous moving traffic object to each of the selected or target TSD 740. Device The respective lengths L of the paths from the currently detected location of the hazardous moving traffic object to each of the selected or target TSDs 740 are: Device It can be determined based on the map data received in step 1115 and the real-time traffic data provided in step 1120. Assume that the maximum speed of the dangerous moving traffic object is V max , where V max The shortest corresponding waiting time for each selected or target TSD 740 may depend on the type of dangerous moving traffic object. s device =L Device / V max Preferably, step 1135 also determines the corresponding maximum wait time w for each selected or target TSD 740. l The maximum waiting time w for each selected or target TSD 740 l yes

[0173] In the next step 1140 of the second method 1100 , the real-time analysis module 720 calculates the shortest waiting time w for each selected or target TSD 740 . sWhen the shortest waiting time w of one of the selected or target TSD 740 is s When the time expires, it indicates that the dangerous moving traffic object may have reached the coverage area of one of the selected or target TSDs 740. In step 1145, the real-time analysis module 720 analyzes the universal traffic data transmission frequency f provided by the experience analysis module 720. g Calculate the temporary traffic data transmission frequency f t ,in If v limit is not obtained from the map data. Then, f g Set equal to f t .f g The previous value of can be considered as f g_old , f g The new value of f can be considered as g_new .v danger The value of can be determined according to the speed of the speeding vehicle.

[0174] If it is determined at decision step 1150 that the f of one of the selected or target TSDs 740 t Greater than f current , then at step 1155, the real-time analysis module 720 generates a new transmission policy for the selected or target one of the TSDs 740 and transmits the new transmission policy to the TRM 760 associated with the selected or target one of the TSDs 740. However, if at decision step 1150, it is determined that the f t Not greater than f current , then the real-time analysis module 720 maintains the current transmission strategy for one of the selected or target TSDs 740.

[0175] Steps 1140 through 1155 are performed for each selected or target TSD 740, respectively.

[0176] Once the selected or target TSD 740 detects a dangerous moving traffic object at decision step 1160, the real-time analysis module 720 has calculated the longest waiting time w of the selected or target TSD 740. l A countdown is performed, indicating that the speed of the dangerous moving traffic object is now considered safe, and the real-time analysis module 720 resets the current respective universal traffic data transmission frequency f for each selected or target TSD 740 based on the current traffic data at step 1165. g , and returns to the first method 1000 at step 1170. After either step 1145 or step 1165, the real-time analysis module 720 transmits the recalculated or reset universal traffic data transmission frequency f at step 1175.g The data is sent to the experience analysis module 720 for calculating the updated general traffic data transmission frequency f g .

[0177] refer to Figure 24 , the third method ( Figure 21 Method 3) 1200 in step 1205 begins with receiving a new value of the network delay d between the TRM 760 and the EGW 120 from the network monitor 750. 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 monitor 750. The maximum delay value can be obtained from d max =1 / f current It is concluded that f current is the current traffic data transmission frequency f of the TSD 740 maintained by the policy change check module 765 of the real-time analysis module 720. If in decision step 1210, the real-time analysis module 720 determines that one or more TSDs 740 have a network delay value d>d max , then the real-time analysis module 720 uses the map data from the map data server to identify nearby related TSDs 740 in step 1215 .

[0178] At decision step 1220, it is determined that none of the identified related devices 740 include a non-real-time data transmission device, and then, at step 1225, the universal traffic data transmission frequency f of the related devices 740 is transmitted. g was lowered.

[0179] If it is determined in decision step 1220 that some of these devices 740 do transmit non-real-time data, then it is determined in decision step 1230 whether the transmission frequency of these non-real-time data transmitting devices 740 is greater than zero. If it is greater than zero, then the percentage of the transmission frequency of these non-real-time data transmitting devices will be reduced by: (d / d max )–1 (at step 1235 ), and the new value f of the non-real-time data transmitting device 740 will be transmitted to the corresponding TRM 760 at step 1240 .

[0180] Once the general traffic data transmission frequency f of the relevant device 740 is g In step 1225, the data transmission frequency f of the non-real-time related device 740 is reduced, and / or in step 1235, the method 1200 obtains a new network delay value d and repeats the steps of the third method 1200 and repeats the reduction of the general traffic data transmission frequency f of the related device 740. gand one or both of the data transmission frequencies f of the non-real-time related device 740 until d is less than d max The method 1200 may include reducing the transmission frequency of the non-real-time data transmitting device 740 to zero. However, in order to protect the security of the network system 100, the universal traffic data transmission frequency f of the relevant real-time data transmitting device 740 may be set to zero. g Therefore, the method performed by the real-time analysis module 720 includes the following steps: g There is a limit to the amount that can be lowered.

[0181] In the third method 1200, in step 1225, the general traffic data transmission frequency f of the relevant device 740 is reduced. g After that, in step 1245, the f of the relevant device 740 is g The new value of is sent to the experience analysis module 720. In one embodiment, f g Cannot be reduced to f g / 2 or less.

[0182] exist Figure 22 The determination step 1040, Figure 23 The decision step 1150 and Figure 24 In any of the decision steps 1230 , the policy change check module 765 preferably checks whether the transmission policy of the TSD 740 needs to be changed.

[0183] In the case where the 5G-V2X network is not integrated with TSN, the network monitor 750 may calculate the network delay value d by any suitable method. Figure 27 The timing diagram shows one method.

[0184] The method includes:

[0185] 1. TRM 760 sends a "start request" message to EGW 120, along with a timestamp T1.

[0186] 2. After receiving the "Start Request" with timestamp "T1" at timestamp T2, EGW 120 sends a delay request to TRM at timestamp T3;

[0187] 3. After receiving the "delay request" at T4, TRM 760 sends "T4" as a "delay response" to EGW 120;

[0188] 4. After receiving T4 from TRM 760, EGW 120 sends a signal to TRM 760 to complete the delay estimation;

[0189] 5. The network delay d can be calculated by the network monitor 750 from d=(T4-T1-T3+T2) / 2.

[0190] Previous about Figures 17 to 27 The described method may be implemented in each EGW 120 of the network system 100 .

[0191] The above-mentioned apparatus may be implemented at least in part by software. It will be understood by those skilled in the art that the above-mentioned apparatus may be implemented at least in part by using general-purpose computer equipment or by using customized equipment.

[0192] Various aspects of the methods and apparatus described herein can be executed on any device, including a communications system. The programmatic aspects of this technology can be considered a "product" or "article of manufacture," typically in the form of executable code and / or associated data, carried or embodied in a machine-readable medium. "Storage" media include any or all memory of a mobile station, computer, processor, or similar device, or related modules thereof, such as various semiconductor memories, tape drives, disk drives, etc., that can provide storage for software programming at any time. All or part of the software can sometimes be communicated over the Internet or various other telecommunications networks. For example, such communication can enable software to be loaded from one computer or processor to another. Thus, another type of media that can carry software elements includes optical, radio, and electromagnetic waves, such as those used over physical interfaces between local devices, over wired and optical landline networks, and over various airlinks. The physical elements that carry such waves, such as wired or wireless links, optical links, etc., can also be considered media that carry the software. As used herein, unless limited to tangible, non-transitory "storage" media, terms such as computer or machine "readable media" refer to any medium that participates in providing instructions to a processor for execution.

[0193] Although the present invention has been described and illustrated in detail in the accompanying drawings and the foregoing description, it should be considered as illustrative rather than restrictive, and it should be understood that only exemplary embodiments are shown and described and that the scope of the present invention is not limited in any way. It is understood that any feature described herein can be used in any embodiment. The illustrative embodiments do not exclude each other or other embodiments not described herein. Therefore, the present invention also provides an embodiment comprising a combination of one or more of the above-mentioned illustrative embodiments. Without departing from the spirit and scope of the present invention, the present invention may be modified and varied, and therefore, only the limitations shown in the appended claims should be applied.

[0194] In the appended claims and the foregoing description of the invention, unless the context requires otherwise due to explicit language or necessary implication, the word "comprise" or variations such as "comprising" are used in an inclusive sense, i.e. specifying the presence of stated features but not excluding the presence or addition of further features in various embodiments of the invention.

[0195] It will be appreciated that, if any prior art publication is referred to herein, this reference does not constitute an admission that the publication forms part of the common general knowledge in the art.

Claims

1. A method for controlling traffic data transmission in a 5G-V2X network, the method comprising: deploying a plurality of traffic sensing devices (TSDs) within at least one determined geographical area of the 5G-V2X network; Configuring an edge gateway module EGW for the at least one determined geographical area to communicate with the plurality of TSDs via one or more 5G channels of the 5G-V2X network; configuring each of the TSDs to provide traffic data to a transport controller TC via the EGW via the one or more 5G channels; wherein the TC dynamically adjusts the traffic data transmission frequency of at least one TSD among the plurality of TSDs according to a transmission control strategy; wherein the transmission control strategy is adjusted according to historical traffic data and real-time traffic data; wherein the historical traffic data is processed to determine a common traffic data transmission frequency f for the plurality of TSDs; g , processing the real-time traffic data to determine a safety traffic data transmission frequency f of at least one TSD among the plurality of TSDs s , so that when f s >f g When the traffic data transmission frequency f of the at least one TSD is adjusted to f=f s , otherwise keep f=f g .

2. The method according to claim 1, wherein When a dangerous moving traffic object is detected within the determined geographical area, the real-time traffic data is processed to determine one or more temporary traffic data transmission frequencies f for the plurality of TSDs or a subset of the plurality of TSDs. t , wherein the subset includes some or all of the TSDs in a set of source and destination TSDs, and if the plurality of TSDs or the set of source and destination TSDs f t >f g , then the universal traffic data transmission frequency of the plurality of TSDs or the set of source and target TSDs is updated to f t .

3. The method according to claim 2, wherein: The general traffic data transmission frequency is updated to the temporary traffic data transmission frequency f using the real-time traffic data from the target TSD t The method is only applicable to the target TSD in the set of source and target TSDs, so that once the predetermined parameters of the detected dangerous moving traffic object are met, the universal traffic data transmission frequency f of the target TSD is changed to g Reset to the normal general traffic data transmission frequency f calculated by the empirical analysis module g .

4. The method according to claim 1, wherein If the 5G-V2X network transmission delay d exceeds the predetermined, selected or calculated maximum delay value d max , the method transmits the universal traffic data transmission frequency f of part or all of the TSDs of the plurality of TSDs g Reduce to a new traffic data transmission frequency f g_new , until d <d max .

5. The method according to claim 4, wherein the method transmits the general traffic data at a frequency f g The reduction of f g_new ≥f g_old / 2,f g_old is f g The previous value of .

6. The method of claim 1, wherein the transmission control strategy is initially based on processing of historical traffic data and dynamically adjusted based on subsequent processing of real-time traffic data.

7. A method according to claim 1, wherein each TSD among the multiple TSDs and / or each group of TSDs among the multiple TSDs has a corresponding transmission restriction module TRM associated with it, and each TRM is controlled to apply a determined or calculated transmission strategy to its associated TSD or each TSD in its associated TSD group, and the determined or calculated transmission strategy includes the transmission control strategy.

8. The method of claim 7, wherein the TRM collects data from its associated TSD and / or TSDs in its associated TSD group, and then transmits the received data to the TC through the one or more 5G channels according to the determined or calculated transmission strategy of its associated TSD and / or each TSD in its associated TSD group.

9. The method according to claim 8, wherein For its associated TSD or the TSD in its associated TSD group, the TRM receives the traffic data from the selected TSD at the TRM and sends it out after the waiting countdown is completed according to the determined or calculated transmission strategy of the selected TSD, and then when an updated transmission strategy of the selected TSD is received, the TRM immediately updates the waiting time for sending traffic data according to the updated transmission strategy, and sends the received traffic data when the updated waiting time expires, and then resets the waiting time for sending traffic data according to the updated transmission strategy for subsequent sending operations after receiving data from the selected TSD.

10. A system for controlling traffic data transmission in a 5G-V2X network, the system comprising: a plurality of traffic sensing devices TSD located within at least one determined geographic area; The at least one edge gateway module EGW that determines a geographical area communicates with the plurality of TSDs via one or more 5G channels of the 5G-V2X network, each of the TSDs being configured to provide traffic data to a transmission controller TC via the one or more 5G channels through the EGW; wherein the TC is configured to dynamically adjust a traffic data transmission frequency of at least one TSD among the plurality of TSDs according to a transmission control policy; The TC includes an experience analysis module for processing historical traffic data and a real-time analysis module for processing real-time traffic data to adjust the transmission control strategy, wherein the experience analysis module is configured to process the historical traffic data to determine a common traffic data transmission frequency f for the plurality of TSDs. g The real-time analysis module is configured to process the real-time traffic data to determine a safety traffic data transmission frequency f of the at least one TSD among the plurality of TSDs. s , the TC is configured so that at f s >f g When the TC adjusts the traffic data transmission frequency f of the at least one TSD to f=f s Otherwise, the TC maintains the traffic data transmission frequency f of the at least one TSD at f=f g .

11. The system according to claim 10, wherein the system comprises a traffic data processor configured to process the raw traffic data from the plurality of TSDs and send structured traffic data to the TC, the structured traffic data comprising any one or more of the following: a speed of a moving traffic object detected by each of the plurality of TSDs; a position of each detected moving traffic object; a timestamp of each detected moving traffic object; The number of traffic alerts detected; the location of each detected traffic alert; the timestamp of each detected traffic alert; The number of detected traffic accidents; the location of each detected traffic accident; the timestamp of each detected traffic accident.

12. The system according to claim 10, wherein: The real-time analysis module is configured to determine a temporary traffic data transmission frequency f for the plurality of TSDs or a subset of the plurality of TSDs when the real-time analysis module detects a dangerous moving traffic object in the determined geographical area. t , a subset of the plurality of TSDs includes some or all of the TSDs in a set of source and target TSDs, if the plurality of TSDs or the set of source and target TSDs has a value of t >f g , the normal general traffic data transmission frequency f of the plurality of TSDs or the source and target TSD groups is g Update to f t .

13. The system according to claim 12, wherein: The real-time analysis module is configured to update the general traffic data transmission frequency to the temporary traffic data transmission frequency f according to the real-time traffic data from the target TSD. t The method is only applicable to the target TSD in the set of source and target TSDs, so that once the predetermined parameters of the detected dangerous moving traffic object are met, the real-time analysis module changes the universal traffic data transmission frequency f of the target TSD to g Reset to the normal general traffic data transmission frequency f calculated by the experience analysis module g .

14. The system according to claim 10, wherein the system comprises a network monitoring module, the network monitoring module being configured to measure the 5G-V2X network delay d and provide the measured value of the network delay d to the real-time analysis module, the real-time analysis module being configured to, if the measured value of the 5G-V2X network transmission delay d exceeds a predetermined, selected or calculated maximum delay value d max , the real-time analysis module transmits the universal traffic data transmission frequency f of part or all of the TSDs of the plurality of TSDs g Reduce to a new traffic data transmission frequency value f g_new , until d <d max .

15. A system according to claim 10, wherein the system includes a transmission restriction module TRM for each TSD of the plurality of TSDs and / or each group of TSDs of the plurality of TSDs, each TRM being configured to apply a determined or calculated transmission policy to its associated TSD or each TSD in its associated group of TSDs.

16. The system of claim 15, wherein: Each TRM is configured to collect data from its associated TSD and / or TSDs in its associated TSD group, and then transmit the received data to the TC via the one or more 5G channels according to a transmission strategy determined or calculated for its associated TSD and / or each TSD in its associated TSD group; Each TRM is configured to receive traffic data from the selected TSD at the TRM and send it out after the waiting countdown is completed according to the determined or calculated transmission strategy of the selected TSD, and then when an updated transmission strategy of the selected TSD is received, the TRM is configured to immediately update the waiting time for sending traffic data according to the updated transmission strategy, and send the received traffic data when the updated waiting time expires, and then reset the waiting time for sending traffic data according to the updated transmission strategy for subsequent sending operations after receiving data from the selected TSD.

17. A transmission controller (TC) for controlling traffic data transmission in a 5G-V2X network, the TC comprising: an experience analysis module for processing historical traffic data received from some or all of a plurality of traffic sensing devices (TSDs) located within a determined geographic area of the 5G-V2X network, the experience analysis module being configured to process the historical traffic data to determine transmission control strategies for the plurality of TSDs; a real-time analysis module configured to process real-time traffic data received from some or all of the plurality of TSDs to adjust the transmission control strategy, thereby providing a dynamic transmission control strategy; wherein the real-time analysis module is configured to control the transmission restriction modules TRM associated with the plurality of TSDs so as to apply a corresponding transmission policy for each of the plurality of TSDs; wherein the transmission control strategy is adjusted based on historical traffic data and real-time traffic data; The historical traffic data is processed to determine a common traffic data transmission frequency f for the plurality of TSDs. g , processing the real-time traffic data to determine a safety traffic data transmission frequency f of at least one TSD among the plurality of TSDs s , so that when f s >f g When the traffic data transmission frequency f of the at least one TSD is adjusted to f=f s , otherwise keep f=f g .

Images