Apparatus, method, and program for generating and transmitting vulnerable road user recognition messages

Abstract

This disclosure relates to intelligent transportation systems (ITS), and more particularly to Vulnerable Road User (VRU) Basic Services (VBS) for ITS-S (ITS-S). Different placements and configurations of the VBS within the facility layer of an ITS-S are described. Also described are VRU Awareness Message (VAM) formats, VAM generation and encoding, and different rules and / or conditions for VAM distribution.

Description

Technical Field

[0001] Related Applications This application claims priority to U.S. Provisional Patent Application No. 63 / 019,903 (AC9632-Z), filed on May 4, 2020; U.S. Provisional Patent Application No. 63 / 019,911 (AC9208-Z), filed on May 4, 2020; and U.S. Provisional Patent Application No. 63 / 033,576 (AD0302-Z), filed on Jun. 2, 2020, the contents of each of which are hereby incorporated by reference in their entirety.

[0002] The present disclosure described herein generally relates to implementations of edge computing, network communications, and communication systems, and more particularly to connected computer-assisted (CA) / autonomous driving (AD) vehicles, Internet of Vehicles (IoV), Internet of Things (IoT) technologies, and advanced road traffic systems.

Background Art

[0003] Advanced road traffic systems (ITS) include advanced applications and services related to various modes of transportation and traffic modes in order to improve traffic safety and efficiency and reduce emissions and fuel consumption. Various forms of wireless communication and / or radio access technology (RAT) may be used in ITS. These RATs may need to coexist in one or more communication channels, such as those available in the 5.9 gigahertz (GHz) band.

[0004] Cooperative Intelligent Transport Systems (C-ITS) are being developed to enable improved traffic safety and efficiency, and to reduce emissions and fuel consumption. The initial focus of C-ITS was on road traffic safety, particularly vehicle safety. Recent efforts have been made to improve the safety and efficiency of traffic for vulnerable road users (VRUs), which refer to both physical entities (e.g., pedestrians) and / or user devices used by physical entities (e.g., mobile stations). Regulation (EU) 168 / 2013 of the European Parliament and the Council of 15 January 2013 on the approval and market surveillance of two-wheeled or three-wheeled and four-wheeled vehicles ("EU Regulation 168 / 2013") provides various examples of VRUs. Computer-assisted and / or autonomous driving (AD) vehicles ("CA / AD vehicles") are expected to reduce VRU-related injuries and fatalities by eliminating or reducing human error in operating the vehicle. However, to this day, despite CA / AD vehicles being equipped with advanced sensing technologies as well as computing and mapping technologies, it is virtually impossible to correct or even detect human errors on the VRU side.

[0005] The drawings are not necessarily drawn to a consistent scale, and similar numbers may describe the same components in different drawings. Similar numbers with different subscripts may represent different instances of the same component. In the attached drawings, the explanations are provided without limitation. [Brief explanation of the drawing]

[0006] [Figure 1] This diagram shows a possible configuration. [Figure 2] This diagram shows an exemplary ITS-S reference architecture. [Figure 3] This diagram shows an illustrative VRU Basic Services (VBS) functional model. [Figure 4] This is a diagram of a VBS state machine. [Figure 5] This diagram shows the VAM format structure. [Figure 6] This diagram shows the vehicle ITS station (V-ITS-S) in a vehicle system. [Figure 7] This diagram shows a personal ITS station (P-ITS-S) that can be used as a VRU ITS-S. [Figure 8] This diagram shows the roadside ITS-S at a roadside infrastructure node. [Figure 9] This diagram shows the upgradeable Vehicle Computation System (UVCS) interface. [Figure 10] This figure shows a UVCS formed using the UVCS interface. [Figure 11] This is a software component diagram showing an in-vehicle system formed using UVCS. [Figure 12] This diagram shows the various components of computing nodes in an edge computing system. [Modes for carrying out the invention]

[0007] The following detailed description refers to the attached drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. The following description includes specific details, such as particular structures, architectures, interfaces, and technologies, for illustrative purposes only, not limitation, to provide a complete understanding.

[0008] Vehicle operation and control are becoming more autonomous over time, and most vehicles are likely to be fully autonomous in the future. Vehicles that include some form of autonomy or otherwise assist human operators are sometimes called “computer-assisted or autonomous” vehicles. Computer-assisted or autonomous (CA / AD) vehicles may include artificial intelligence (AI), machine learning (ML), and / or other similar self-learning systems that enable autonomous operation. Typically, these systems perceive their environment (e.g., using sensor data) and take various measures to maximize the likelihood of successful vehicle operation.

[0009] Vehicle-to-vehicle and vehicle-to-infrastructure (V2X) applications (simply referred to as "V2X") include the following types of communication: vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) and / or vehicle-to-infrastructure (I2V), vehicle-to-network (V2N) and / or network-to-vehicle (N2V), pedestrian-vehicle communication (V2P), and ITS-to-ITS (ITS-S) communication (X2X). V2X can use collaborative perception to provide more intelligent services to end users. This means that entities such as vehicle stations and vehicle user equipment (vUEs), including CA / AD vehicles, roadside infrastructure or roadside units (RSUs), application servers, and pedestrian devices (e.g., smartphones, tablets), collect knowledge of their local environment (e.g., information received from other nearby vehicles or sensor devices) and process and share that knowledge to provide more intelligent services such as collaborative perception and steering coordination used in collision warning systems, autonomous driving, etc.

[0010] One such V2X application includes Intelligent Transportation Systems (ITS), which are systems that use information and communication technologies to support the transport of goods and people in order to use transport infrastructure and means of transport (e.g., cars, trains, aircraft, ships, etc.) efficiently and safely. Elements of ITS are being standardized by various standardization bodies at both the international and regional levels.

[0011] Communications in ITS (ITSC) can utilize a variety of existing and new access technologies (or radio access technologies (RATs)) and ITS applications. Examples of these V2X RATs include IEEE RATs and 3G Partnerships (3GPP®) RATs. IEEE V2X RATs include, for example, radio access in vehicle environments (WAVE), dedicated short-range communication (DSRC), intelligent road traffic systems (ITS-G5) in the 5GHz frequency band, the IEEE 802.11p protocol (which is the Layer 1 (L1) and Layer 2 (L2) portion of WAVE, DSRC, and ITS-G5), and, in some cases, the IEEE 802.16 protocol known as Worldwide Interoperability for Microwave Access (WiMAX®). The term "DSRC" refers to vehicle communications in the 5.9GHz frequency band as commonly used in the United States, and "ITS-G5" refers to vehicle communications in the 5.9GHz frequency band in Europe. Because any number of different RATs (including IEEE 802.11p-based RATs) that may be used in any geographical or political territory are applicable, the terms “DSRC” (used in the United States in particular) and “ITS-G5” (used in Europe in particular) may be used interchangeably throughout this disclosure. 3GPP V2X RATs include, for example, cellular V2X (C-V2X) using Long-Term Evolution (LTE) technology (sometimes referred to as “LTE-V2X”), and / or C-V2X using fifth-generation (5G) technology (sometimes referred to as “5G-V2X” or “NR-V2X”). Other RATs, such as RATs using UHF and VHF frequencies, Global Mobile Object Communications System (GSM®), and / or other wireless communication technologies, may be used in ITS and / or V2X applications.

[0012] 1. Vulnerable Road Users (VRUs) Figure 1 shows an overview of environment 100. As shown in the figure, the environment includes vehicles 110A and 110B (collectively, “vehicle 110”). Vehicle 110 includes an engine, transmission, axles, wheels, etc. (not shown). Vehicle 110 may be any type of motor-driven vehicle used for transporting people or goods, each equipped with an engine, transmission, axles, wheels, and control systems used for driving, parking, passenger comfort and / or safety, etc. As used herein, terms such as “motor” and “motor-driven” refer to a device that converts a form of energy into mechanical energy, and include internal combustion engines (ICE), compressed combustion engines (CCE), electric motors, and hybrids (e.g., ICE / CCE and electric motors). The multiple vehicles 110 shown in Figure 1 may represent automatic vehicles from various manufacturers, models, trims, etc.

[0013] For illustrative purposes, the following description provides a deployment scenario involving vehicle 110 in a 2D highway / main road / roadway environment where vehicle 110 is an automobile. However, this description may also be applicable to other types of vehicles such as trucks, buses, motorboats, motorcycles, electric personal mobility devices, and / or any other motor-driven devices capable of transporting people or goods. Furthermore, this description may also be applicable to social networking between vehicles of different vehicle types, and 3D deployment scenarios where part or all of vehicle 110 is implemented as an aircraft, drone, UAV, or other flying object, as well as / or any other similar motor-driven devices.

[0014] Vehicle 110 includes an In-Vehicle System (IVS) 101, which will be discussed in more detail below. However, Vehicle 110 may also include additional or alternative types of computing devices / systems, such as smartphones, tablets, wearables, laptops, laptop computers, in-vehicle infotainment systems, in-vehicle entertainment systems, instrument clusters, head-up display (HUD) devices, onboard diagnostic devices, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, microcontrollers, control modules, and engine management systems. Vehicle 110 including a computing system (e.g., IVS 101), and vehicles referred to throughout this disclosure, may be called a Vehicle User Equipment (vUE) 110, a Vehicle Station 110, a Vehicle ITS Station (V-ITS-S) 110, and / or a Computer-Assisted (CA) / Autonomous Driving (AD) Vehicle 110, etc.

[0015] Each vehicle 110 includes an In-Vehicle System (IVS) 101, one or more sensors 172, and one or more Driving Control Units (DCUs) 174. The IVS 100 includes several vehicle computing hardware subsystems and / or applications, including various hardware and software elements for implementing the ITS architecture shown in Figure 2, for example. The vehicle 110 may also have one or more V2X RATs, which enable the vehicles 110 to communicate directly with each other and with infrastructure equipment (e.g., network access nodes (NANs) 130). The V2X RATs may refer to 3GPP cellular V2X RATs (e.g., LTE, 5G / NR, and later), WLAN V2X (W-V2X) RATs (e.g., US DSRC and EU ITS-G5), and / or any other RATs, such as those discussed herein. Some or all of the vehicles 110 include positioning circuits for (roughly) determining their respective geographical locations and for communicating their current locations to the NAN130 in a secure and reliable manner. This allows the vehicles 110 to synchronize with each other and / or with the NAN130. In addition, some or all of the vehicles 110 may be computer-assisted or autonomous driving (CA / AD) vehicles, which may include artificial intelligence (AI) and / or robotics to assist in vehicle operation.

[0016] IVS101 includes ITS-S103, which may be the same as or similar to ITS-S601 in Figure 6. IVS101 may be or include an upgradeable vehicle computing system (UVCS) as described below. As discussed herein, ITS-S103 (or the underlying V2X RAT circuit on which ITS-S103 operates) may perform channel sensing or medium sensing operations, which utilize at least energy sensing (ED) to determine the presence or absence of other signals on the channel in order to determine whether the channel is occupied or free. ED may include sensing radio frequency (RF) energy across an intended transmission bandwidth, spectrum, or channel over a period of time and comparing the sensed RF energy to a predefined or configured threshold. If the sensed RF energy exceeds the threshold, the intended transmission bandwidth, spectrum, or channel may be considered occupied.

[0017] Apart from the UVCS technology of this disclosure, the IVS101 and CA / AD vehicle 110 may be any one of several in-vehicle systems and CA / AD vehicles, ranging from computer-assisted vehicles to partially or fully autonomous vehicles. In addition, the IVS101 and CA / AD vehicle 110 may include other components / subsystems not shown in Figure 1, such as elements illustrated and described throughout this disclosure. Other embodiments of the underlying UVCS technology used to implement the IVS101 will be further described with reference to the remaining Figures 2 to 8.

[0018] In addition to the functions discussed herein, the ITS-S601 (or the V2X RAT circuit on which the ITS-S601 operates) can measure various signals or determine / identify various signal / channel characteristics. Signal measurements may be performed for cell selection, handover, network connectivity, testing, and / or other purposes. The measurements / characteristics collected by the ITS-S601 (or V2X RAT circuit) may include one or more of the following: Bandwidth (BW), network or cell load, latency, jitter, round-trip time (RTT), interrupt count, data packet out-of-order delivery, transmit power, bit error rate, bit error ratio (BER), block error rate (BLER), packet loss rate (PLR), packet reception rate (PRR), channel busy rate (CBR), channel occupancy rate (CR), signal-to-noise ratio (SNR), signal-to-noise interference ratio (SINR), signal-to-noise plus distortion to noise plus distortion (SINAD) ratio, peak-to-average power ratio (PAPR), reference signal received power (RSRP), received signal strength index (RSSI), reference signal received quality (RSRQ), E-UTR GNSS timing of cell frames for AN or 5G / NR UE positioning (e.g., timing between NAN130 reference time and GNSS intrinsic reference time for a given GNSS), GNSS code measurements (e.g., GNSS code phase (integer and fractional parts) of the spreading code of the i-th GNSS satellite signal), GNSS carrier phase measurements (e.g., the number of carrier phase cycles (integer and fractional parts) of the i-th GNSS satellite signal measured since locking onto the signal, also known as integrated delta range (ADR)), channel interference measurements, thermal noise power measurements, received interference power measurements, and / or other similar measurements.The RSRP measurement value, RSSI measurement value, and / or RSRQ measurement value may include the RSRP measurement value, RSSI measurement value, and / or RSRQ measurement value of a cell-specific reference signal, channel state information reference signal (CSI-RS), and / or synchronization signal (SS) or SS block for a 3GPP network (e.g., LTE or 5G / NR), as well as the RSRP measurement value, RSSI measurement value, and / or RSRQ measurement value of various beacons, FILS discovery frames, or probe response frames for an IEEE802.11 WLAN / WiFi network. Other measurement values such as those discussed in 3GPP TS 36.214 v15.4.0 (2019-09), 3GPP TS 38.215 v16.1.0 (2020-04), IEEE802.11, Part 11, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, IEEE Std." may be used additionally or alternatively. The same or similar measurement values may be measured or collected by NAN130.

[0019] Subsystems / applications may also include instrument cluster subsystems, front and / or rear seat infotainment subsystems, and / or other similar media subsystems, navigation subsystem (NAV) 102, vehicle status subsystem / application, HUD subsystem, EMA subsystem, etc. The NAV 102 may be configured or operable to provide navigation guidance or control depending on whether the vehicle 110 is a computer-assisted vehicle, a partially autonomous vehicle, or a fully autonomous vehicle. The NAV 102 may be configured to include computer vision for recognizing stationary or moving objects (e.g., pedestrians, other vehicles, or any other moving objects) in the area surrounding the vehicle 110 as the vehicle 110 moves toward its destination. The NAV 102 may be configured or operable to recognize stationary or moving objects in the area surrounding the vehicle 110 and, in response, make decisions when guiding or controlling the DCU of the vehicle 110, at least in part based on sensor data collected by sensor 172.

[0020] The DCU 174 includes hardware elements that control various systems of the vehicle 110, such as the operations of the engine, transmission, steering, and braking. The DCU 174 is an embedded system or other similar computer device that controls the corresponding systems of the vehicle 110. The DCU 174 may each have components that are the same as or similar to the device / system of FIG. 12 described later, or may be any other suitable microcontroller or other similar processor device, memory device, communication interface, etc. An individual DCU 174 can communicate with one or more sensors 172 and actuators (e.g., actuator 1274 of FIG. 12). The sensors 172 are hardware elements that can be configured or operated to detect the environment surrounding the vehicle 110 and / or changes in the environment. The sensors 172 can be configured or operated to provide various sensor data to the DCU 174 and / or one or more AI agents to enable the DCU 174 and / or one or more AI agents to control the respective control systems of the vehicle 110. Some or all of the sensors 172 may be the same as or similar to the sensor circuit 1272 of FIG. 12. The IVS 101 may include or implement a facility layer and operate one or more facilities within the facility layer.

[0021] The IVS101 communicates or interacts with one or more vehicles 110, either by itself or in response to user interaction, via interface 153, which may be, for example, a 3GPP-based direct link or an IEEE-based direct link. The 3GPP (e.g., LTE or 5G / NR) direct link may be a side link, proximity service (ProSe) link, and / or PC5 interface / link, and the IEEE (WiFi®)-based direct link or personal area network (PAN)-based link may be, for example, a WiFi direct link, an IEEE 802.11p link, an IEEE 802.11bd link, or an IEEE 802.15.4 link (e.g., ZigBee®, IPv6 over low-power wireless personal area network (6LoWPAN), WirelessHART, MiWi, Thread, etc.). Other technologies such as Bluetooth® / Bluetooth Low Energy (BLE) may also be used. The vehicles 110 may exchange ITS protocol data units (PDUs) or other messages with each other over interface 153.

[0022] The IVS101 communicates or interacts with one or more remote / cloud servers 160 via the NAN130 on interface 112 and network 158, either by itself or in response to user interaction. The NAN130 is positioned to provide network connectivity to the vehicles 110 via their respective interfaces 112 between the NAN130 and the individual vehicles 110. The NAN130 is an ITS-S or includes an ITS-S, and may be a roadside ITS-S (R-ITS-S). The NAN130 is a network element that is part of an access network providing network connectivity to end-user devices (e.g., V-ITS-S110 and / or VRU ITS-S117). The access network may be a RAN such as an NG RAN or 5G RAN for a radio access network (RAN) operating on a 5G / NR cellular network, an E-UTRAN for a RAN operating on an LTE or 4G cellular network, or a legacy RAN such as UTRAN or GERAN for a GSM or CDMA cellular network. The access network, or RAN, may be referred to as the access service network for WiMAX implementations. In some implementations, all or part of the RAN may be implemented as one or more software entities running on a server computer as part of a virtual network that may be called Cloud RAN (CRAN), Cognitive Radio (CR), and / or Virtual Baseband Unit Pool (vBBUP), etc. CRAN, CR, or vBBUP may implement a RAN functional partitioning in which one or more communication protocol layers are operated by CRAN / CR / vBBUP, and other communication protocol entities are operated by separate RAN nodes 130. This virtualization framework enables the freed processor cores of NAN130 to run other virtualization applications, such as the VRU116 and / or V-ITS-S110 virtualization applications discussed herein.

[0023] Environment 100 also includes VRU116, and VRU116 includes VRU ITS-S117. VRU116 is a non-motorized road user and L-class vehicle (e.g., mopeds, motorcycles, Segways, etc.) as defined in Annex I of EU Regulation 168 / 2013 (see, for example, International Organization for Standardization (ISO) D, "Road vehicles - Vehicle dynamics and road-holding ability - Vocabulary", ISO 8855(2013) (hereinafter "[ISO8855]")). VRU116 is an operating entity that interacts with VRU system 117 in a given use case and behavioral scenario. For example, if VRU116 is equipped with a personal device, VRU116 can directly interact with other ITS stations and / or other VRU116s having VRU devices 117 via the personal device. VRU ITS-S117 can be either a pedestrian-type VRU (see, for example, P-ITS-S701 in Figure 7) or a vehicle-type VRU (on a bicycle, motorcycle). As used herein, the term "VRU ITS-S" refers to any type of VRU device or VRU system. Potential VRUs may be referred to as non-VRUs and considered to be idle or inactive within the ITS before they can be identified as VRUs.

[0024] If a VRU116 is not equipped with a device, it interacts indirectly when it is detected by another ITS station in the VRU system 117 via its sensing device, such as a sensor and / or other component. However, such a VRU116 cannot detect other VRU116s (e.g., a bicycle). In ETSI TS 103 300-2 V0.3.0 (2019-12) ("[TS103300-2]"), different types of VRU116s are classified into the following four profiles: VRU Profile-1: Pedestrians (sidewalk users, children, strollers, people with disabilities, the elderly, etc.) VRU Profile-2: People riding bicycles (light vehicles carrying people, wheelchair users, horses carrying riders, skaters, electric scooters, Segways, etc.), and VRU Profile-3: Motorcycle rider (motorcycle, motorized two-wheeled vehicle, moped, etc.). VRU Profile-4: Animals that pose a safety risk to other road users (dogs, wild animals, horses, cattle, sheep, etc.).

[0025] These profiles further define the VRU functional system and communication architecture for VRU ITS-S117. To robustly support the recognition and activation of VRU profiles, VRU-related functional system requirements, protocols, and message exchange mechanisms (e.g., VAM) are described in more detail below. In addition, applicable VRU device types are listed in Table 1 (see also, e.g., [TS103300-2]). [Table 1]

[0026] VRU116 may be equipped with a portable device (e.g., device 117). The term "VRU" may be used to refer to both VRU116 and its VRU device 117 unless otherwise intended in context. VRU device 117 may be initially configured and may evolve during its operation in accordance with contextual changes that need to be specified. This is especially true for the setup of VRU profiles and VRU types, which can be achieved automatically at power-up or via the HMI. Changes in road user vulnerability states also need to be provided to activate VRU basic services when road users become vulnerable or to deactivate VRU basic services when they enter a protected area. Initial configuration can be set up automatically at power-up of the device. This may apply to VRU device types, which may be VRU-Tx, which has only the ability to broadcast messages and complies with channel congestion control rules; VRU-Rx, which has only the ability to receive messages; and / or VRU-St, which has full-duplex communication capabilities. During operation, the VRU profile may also change due to some clustering or decomposition. As a result, the role of the VRU device can evolve in accordance with changes in the VRU profile.

[0027] A “VRU system” (e.g., VRU ITS-S117) comprises ITS artifacts related to VRU use cases and scenarios as discussed herein, including key components and their configurations, operating entities and their equipment, associated traffic conditions, and operating environments. The terms “VRU device,” “VRU equipment,” and “VRU system” refer to portable devices (e.g., mobile stations such as smartphones, tablets, wearable devices, and fitness trackers) or IoT devices (e.g., traffic control devices) used by VRU116 integrating ITS-S technology, and thus VRU ITS-S117 includes or may include “VRU device,” “VRU equipment,” and / or “VRU system.”

[0028] The VRU system considered in this disclosure is a cooperative intelligent transport system (C-ITS) comprising at least one vulnerable road user (VRU) and one ITS station having a VRU application. An ITS-S can be a vehicle ITS station or roadside ITS station that processes VRU application logic based on the lower communication layers (facility layer, networking & transport layer, and access layer (see, e.g., ETSI EN 302 665 V1.1.1 (2010-09) ("[EN302665]"))), associated hardware components, other in-station services, and services provided by sensor subsystems. A VRU system can be extended with other VRUs, other ITS-S, and other road users involved in scenarios such as vehicles, motorcycles, bicycles, and pedestrians. A VRU may be equipped with ITS-S or different technologies (e.g., IoT) that enable the VRU to transmit or receive alarms. Thus, the VRU system considered is a heterogeneous system. The definition of a VRU system is used to identify the system components that actively participate in use cases and behavioral scenarios. Active system components are equipped with ITS stations, while all other components are passive and form part of the environment of the VRU system.

[0029] The VRU ITS-S117 can operate one or more VRU applications. A VRU application is an application that enhances the recognition of VRUs and / or VRU clusters within or around other traffic participants, and / or awareness of VRUs and / or VRU clusters. A VRU application can reside in any ITS-S; that is, a VRU application can be found in the VRU itself or in a non-VRU ITS station, such as a car, truck, bus, roadside station, or central station. These applications are intended to provide VRU-related information directly to humans or to operating entities such as automated systems. A VRU application can enhance the recognition of vulnerable road users, provide VRU collision risk warnings to any other road users, or trigger automated actions within a vehicle. A VRU application may utilize data received from other ITS-S via the C-ITS network and additional information provided by the ITS-S's own sensor system and other integrated services.

[0030] Generally, there are four types of VRU equipment 117, including unequipped VRUs (e.g., VRU116 without a device), VRU-Tx (e.g., VRU116 equipped with an ITS-S117 that only has transmit (Tx) capability to broadcast recognition messages or beacons about VRU116 and has no receive (Rx) capability), VRU-Rx (e.g., VRU116 equipped with an ITS-S117 that only has Rx (no Tx) capability to receive broadcasted recognition messages or beacons about other VRU116s or other non-VRU ITS-Ss), and VRU-St (e.g., VRU116 equipped with an ITS-S117 that includes VRU-Tx and VRU-Rx capabilities). Use cases and behavioral scenarios consider a wide range of configurations of VRU systems 117 based on the equipment of VRU116 and the presence or absence of V-ITS-S110 and / or R-ITS-S130 with VRU applications. Examples of various VRU system configurations are shown in Table 2 of ETSI TR 103 300-1 v2.1.1(2019-09) ("[TR103300-1]").

[0031] The message specified for VRU116 / 117 is the VRU Recognition Message (VAM). The VAM is a message sent from VRU ITS117 to create and maintain recognition of VRU116 participating in the VRU / ITS system. The VAM is to be harmonized as much as possible with existing Cooperative Recognition Messages (CAMs) as defined in [EN302637-2]. Transmission of VAMs is restricted to the VRU profile specified in section 6.1 of [TS103300-2]. The VAM contains all necessary data depending on the VRU profile and actual environmental conditions. The data elements of the VAM should be as shown in Table 2. [Table 2]

[0032] The VRU system 117 supports flexible and dynamic triggering of messages at generation intervals starting from as frequent as X milliseconds (ms), where X is a number (e.g., X = 100 ms). The VAM frequency is related to the VRU kinematics and selected collision risk metrics, as discussed in section 6.5.10.5 of [TS103300-3].

[0033] The number of VRU116s operating in a given area can be very large. In some cases, VRU116s can be combined with VRU vehicles (e.g., riders such as bicycles). To reduce traffic and associated resource usage (e.g., spectral requirements), VRU116s may be grouped together into one or more VRU clusters. A VRU cluster is a set of two or more VRU116s (e.g., pedestrians) that move coherently, for example, at coherent speeds or directions and within a VRU bounding box. "Coherent cluster speed" refers to a range of speeds of VRU116s within a cluster such that the difference in speed and direction of travel between any two VRUs in the cluster is below a predefined threshold. A "VRU bounding box" is a rectangular area that accommodates all VRU116s in a VRU cluster such that all VRUs within the bounding box touch the surface at approximately the same height.

[0034] VRU clusters can be homogeneous (e.g., a group of pedestrians) or heterogeneous (e.g., a group of pedestrians and bicycles with human operators). These clusters are considered a single object / entity. VRU cluster parameters are communicated using VRU-aware messages (VAMs), with only the cluster head continuously sending VAMs. The VAM includes an optional field indicating whether VRU116 is leading the cluster, a field that does not exist for individual VRUs (e.g., other VRUs in the cluster should not send VAMs, or should send VAMs at very long intervals). The leading VRU also indicates in the VAM whether it is a homogeneous or heterogeneous cluster, with heterogeneous clusters being any combination of VRUs. Indicating whether a VRU cluster is heterogeneous and / or homogeneous can provide useful information for predicting the trajectory and behavior when the cluster dissolves.

[0035] The use of a bicycle or motorcycle will significantly alter the behavior and parameter set of the VRU using this non-VRU object (or VRU vehicle such as "bicycle" / "motorcycle"). The combination of VRU116 and a non-VRU object is called a "composite VRU". VRU116 with VRU profile 3 (e.g., motorcycle rider) does not typically participate in VRU clustering.

[0036] The VAM contains status and attribute information of the originating VRU ITS-S117. The content may vary depending on the VRU ITS-S117 profile. Typical status information includes time, location, motion status, cluster status, etc. Typical attribute information includes data on the VRU profile, type, dimensions, etc. The generation, transmission, and reception of VAMs are managed by the VRU Basic Services (VBS) (see, for example, Figures 2-3). The VBS is a facility layer entity that operates the VAM protocol. The VBS provides services such as handling the VRU role and transmitting and receiving VAMs to enhance VRU security. The VBS also specifies and / or manages VRU clustering in the presence of high-density VRU116 / 117s to reduce VAM communication overhead. In VRU clustering, nearby VRUs with coherent speed and direction of travel form a facility layer VRU cluster, and only the cluster head VRU116 / 117 transmits VAMs. Other VRU116 / 117s within the cluster will skip sending a VAM. Active VRU116 / 117s (for example, VRU116 / 117s not in a VRU cluster) will send a separate VAM (sometimes called a single VRU VAM). A "separate VAM" is a VAM containing information about a specific VRU116 / 117. An unqualified VAM can be a cluster VAM or a separate VAM.

[0037] The radio access technology (RAT) used by NAN130, V-ITS-S110, and VRU ITS-S117 may include one or more V2X RATs that enable V2X RATs to communicate directly with each other, with infrastructure equipment (e.g., NAN130), and with VRU device 117. In the example in Figure 1, any number of V2X RATs may be used for V2X communication. In one example, at least two separate V2X RATs may be used, including a WLAN V2X (W-V2X) RAT based on IEEE V2X technology (e.g., US DSRC or European ITS-G5) and a 3GPP C-V2X RAT (e.g., LTE, 5G / NR, and later). In one example, the C-V2X RAT may utilize air interface 112a, and the WLAN V2X RAT may utilize air interface 112b. The access layer of the ITS-G5 interface is outlined in ETSI EN 302 663 V1.3.1 (2020-01) (hereinafter referred to as "[EN302663]"), which describes the access layer of the ITS-S reference architecture 200. The ITS-G5 access layer includes the IEEE 802.11-2016 (hereinafter referred to as "[IEEE80211]") protocol and the IEEE 802.2 Logical Link Control (LLC) (hereinafter referred to as "[IEEE8022]") protocol. The access layer of the 3GPP LTE-V2X-based interface is outlined in particular in ETSI EN 303 613 V1.1.1 (2020-01) and 3GPP TS 23.285 v16.2.0 (2019-12), while 3GPP 5G / NR-V2X is outlined in particular in 3GPP TR 23.786 v16.1.0 (2019-06) and 3GPP TS 23.287 v16.2.0 (2020-03). A NAN130 or edge compute node140 may provide one or more services / capacities180.

[0038] In a V2X scenario, V-ITS-S110 or NAN130 may be an RSU or R-ITS-S130, or may function as an RSU or R-ITS-S, where RSU or R-ITS-S130 refers to any transport infrastructure entity used for V2X communication. In this example, RSU130 may be a fixed RSU such as a gNB / eNB type RSU or other similar infrastructure, or a relatively stationary UE. RSU130 may also be a mobile RSU or UE type RSU, which may be implemented by a vehicle (e.g., V-ITS-S110), a pedestrian, or any other device with such capabilities. In these cases, mobility issues can be managed to ensure adequate radio coverage of the conversion entity.

[0039] The RSU130 is a computing device coupled with a roadside-mounted radio frequency circuit that provides connectivity support to passing V-ITS-S110s. The RSU130 may also include an internal data storage circuit for storing intersection map shapes, traffic statistics, media, and applications / software for sensing and controlling oncoming vehicle and pedestrian traffic. The RSU130 provides various services / capabilities 180, such as ultra-low latency communication required for high-speed events, such as collision avoidance and traffic warnings. In addition, or alternatively, the RSU130 may provide other services / capabilities 180, such as cellular / WLAN communication services. In some implementations, the components of the RSU130 may be packaged in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller for providing wired connectivity (e.g., Ethernet®) to a traffic signal controller and / or backhaul network. Furthermore, the RSU130 may include a wired or wireless interface for communicating with other RSU130s (not shown in Figure 1).

[0040] In configuration 100, V-ITS-S110a may be equipped with a first V2X RAT communication system (e.g., C-V2X), and V-ITS-S110b may be equipped with a second V2X RAT communication system (e.g., W-V2X, which may be DSRC, ITS-G5, etc.). In addition, or alternatively, V-ITS-S110a and / or V-ITS-S110b may each be used with one or more V2X RAT communication systems. RSU 130 may provide a V2X RAT conversion service between one or more services / capabilities 180 so that individual V-ITS-S110s can communicate with each other even if the V-ITS-S110s implement different V2X RATs. RSU130 (or edge compute node 140) may provide VRU services between one or more services / capacities 180, and RSU130 shares CPM, MCM, VAM, DENM, CAM, etc. with V-ITS-S110 and / or VRU for VRU security purposes. V-ITS-S110 may also share such messages with each other, with RSU130 and / or VRU. These messages may include various data elements and / or data fields as discussed herein.

[0041] NAN130 may be a fixed RSU such as a gNB / eNB type RSU or other similar infrastructure. NAN130 may also be a mobile RSU or UE type RSU, which may be implemented by a vehicle, pedestrian, or any other device having such capabilities. In these cases, mobility issues can be managed to ensure adequate radio coverage for the conversion entity. NAN130 enabling connectivity may be called a “RAN node,” etc. A RAN node 130 may comprise a ground station (e.g., a ground access point) or satellite station providing coverage within a geographic area (e.g., a cell). A RAN node 130 may be implemented as a dedicated physical device such as a macrocell base station, and / or as one or more low-power base stations to provide a smaller coverage area, smaller user capacity, or higher bandwidth compared to a macrocell, such as a femtocell, picocell, or other similar cell. In this example, RAN node 130 is embodied as a NodeB, an evolved NodeB (eNB), or a next-generation NodeB (gNB), one or more relay nodes, distributed units, or roadside units (RSUs). Any other type of NAN can be used. In addition, RAN node 130 can perform a variety of logical functions for the RAN, including but not limited to RAN functions for radio resource management, admission control, dynamic resource allocation of uplink and downlink, radio bearer management, and data packet scheduling (e.g., radio network controller (RNC) functions and / or NG-RAN functions).

[0042] Network 158 may represent networks such as the Internet, a wireless local area network (WLAN), or a wireless wide area network (WWAN) including dedicated and / or enterprise networks for a company or organization, a cellular core network (e.g., an evolved packet core (EPC) network, a NextGen packet core (NPC) network, a 5G core (5GC), or any other type of core network), a cloud computing architecture / platform providing one or more cloud computing services, and / or a combination thereof. For example, Network 158 and / or access technology may include cellular technologies such as LTE, MuLTEfire, and / or NR / 5G (e.g., provided by a radio access network (RAN) node 130), WLAN (e.g., WiFi®) technology (e.g., provided by an access point (AP) 130), and so on. Different technologies offer advantages and limitations in different scenarios, and application performance in different scenarios depends on the choice of access network (e.g., WiFi, LTE, etc.) and the network and transport protocols used (e.g., Transport Control Protocol (TCP), Virtual Private Network (VPN), Multipath TCP (MPTCP), General Purpose Routing Encapsulation (GRE), etc.).

[0043] The remote / cloud server 160 may represent one or more application servers, a cloud computing architecture / platform providing cloud computing services, and / or any other remote infrastructure. The remote / cloud server 160 may include any one of several services and capabilities 180, such as ITS-related applications and services, driver assistance (e.g., mapping / navigation), and / or content delivery (e.g., multimedia infotainment streaming).

[0044] In addition, NAN130 is located in the same place as the edge compute nodes 140 (or a collection of edge compute nodes 140), which may provide any number of services / capabilities 180 to the vehicle 110, such as ITS services / applications, driver assistance, and / or content delivery services 180. The edge compute nodes 140 may include or be part of an edge network or “edge cloud”. The edge compute nodes 140 may also be referred to as “edge hosts 140”, “edge servers 140”, or “computation platforms 140”. The edge compute nodes 140 may partition resources (e.g., memory, CPU, GPU, interrupt controller, I / O controller, memory controller, bus controller, network connectivity, or sessions), and each partition may include security and / or integrity protection capabilities. The edge nodes may also provide orchestration of multiple applications through isolated user-space instances such as containers, partitions, virtual environments (VEs), virtual machines (VMs), servlets, servers, and / or other similar compute abstractions. The edge computing node 140 may be implemented in a data center or cloud facility, a designated edge node server, an enterprise server, a roadside server, a telecommunications central office, or on a service-providing local or peer edge device that consumes edge services. The edge computing node 140 can provide any number of driver assistance and / or content delivery services 180 to the vehicle 110. The edge computing node 140 may be implemented in a data center or cloud facility, a designated edge node server, an enterprise server, a roadside server, a telecommunications central office, or on a service-providing local or peer edge device that consumes edge services.Examples of other edge computing / networking technologies that can implement edge compute nodes 140 and / or edge computing networks / clouds include Multi-Access Edge Computing (MEC), Content Delivery Networks (CDNs) (also known as “Content Distribution Networks”), Mobility Service Provider (MSP) edge computing and / or Mobility as a Service (MaaS) provider systems (e.g., used in AECC architectures), Nebula edge cloud systems, fog computing systems, cloudlet edge cloud systems, mobile cloud computing (MCC) systems, Central Office Re-architected as a Datacenter (CORD) systems, mobile CORD (M-CORD) systems, and / or converged multi-access and core (COMAC) systems. Furthermore, the technologies disclosed herein may relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures may also be used.

[0045] 2. VAM overhead reduction and redundancy reduction The generation, transmission, and reception of VAMs are managed by the VRU Basic Service (VBS) by implementing the VAM protocol (see, e.g., [TS103300-3]). The VRU Basic Service is a facility layer entity that operates the VAM protocol. The VRU Basic Service provides three main services: handling VRU roles, and transmitting and receiving VAMs to enhance VRU security. However, the current standard (see, e.g., [TS103300-3]) does not provide details on VAM generation triggers, VAM generation frequency, and VAM segmentation when the VAM size exceeds the VAM size that lower layers can handle. Frequent transmission of VAMs may be desirable to achieve better nearby VRU recognition to improve VRU security, but it may result in significant or unacceptable communication overhead at the access layer. The concept of VRU clustering is employed in [TS103300-3] in the presence of high-density VRUs to reduce VAM communication overhead to some extent. In VRU clustering, nearby VRUs with coherent speed and direction of travel form a facility layer VRU cluster, and only the cluster leader / header transmits VAMs. However, cluster coupling constraints limit the scenarios in which clusters are formed in most cases, resulting in VRUs transmitting separate VAMs on the same radio resource at the access layer.

[0046] Currently, ETSI ITS Working Group 1 (WG1) is working on developing VRU basic services (see, e.g., [TS103300-3]) protocols and procedures. Details of VAM distribution have not yet been defined. It is necessary to balance the frequency and size of VAM generation by VBS at the facility layer with the communication overhead at the access layer, without affecting nearby VRU security and VRU recognition.

[0047] The VAM transmission frequency is dynamically adjusted based on several parameters / perceived contexts in the vicinity to reduce VAM communication overhead. This disclosure enables efficient distribution of VAM. VBS activation and deactivation conditions based on the roles and contexts of various station types (e.g., VRU, RSE, vehicle station, etc.) VBS-based generation frequency management for efficient VAM distribution. Trigger events for the initial generation and transmission of various types of VAMs (single VRU VAM, VRU cluster VAM, and infrastructure VAM) Conditions and procedures for the continuous transmission of these VAMs after they have been triggered to be generated and transmitted. VAM redundancy reduction mechanism for reducing communication overhead A VAM segmentation algorithm for when the VAM size exceeds the maximum transmission unit (MTU) that the lower layer can handle.

[0048] In summary, the description herein enables an efficient mechanism for VAM distribution that reduces communication overhead in vehicle networks (including Internet of Vehicles (IoV) networks and / or autonomous wireless sensor networks) to address the aforementioned problems / challenges.

[0049] In various implementations, ITS-S provides ITS services, which include sending and receiving ITS service messages (e.g., VAMs). ITS services are easily scalable across cities or geographical areas. In facility layer messages, an application container is used together with the ITS PDU header and / or ITS service container.

[0050] Furthermore, ETSI ITS standards / frameworks and / or edge computing standards / frameworks (e.g., Multi-Access Edge Computing (MEC)) can standardize and / or specify the various implementations discussed herein. In these implementations, one or more edge computing applications (e.g., MEC apps) provide VBS and generate, receive, and transmit VAM.

[0051] 2.1. Activation and termination of VRU Basic Services (VBS) As mentioned above, the generation, transmission, and reception of VAMs are handled by the VRU Basic Services (VBS) facility within the facility layer. Therefore, VBS must be active when VAMs need to be transmitted or received by the VRU ITS-S. The following VBS activation and deactivation triggers are used for different types of ITS-S and their current status.

[0052] 2.1.1. VRU ITS-S VBS can be activated for VRU ITS-S whenever the VRU is in an active VRU state, such as when the VRU may be at risk from other road users such as vehicles or motorcycles. The VRU should be in an active state when it is in a crosswalk, at an intersection, or on a sidewalk / bicycle lane. VBS should be terminated for VRU ITS-S whenever the VRU transitions to an idle VRU state, such as when the VRU boards a bus. As long as the VBS service is active, VAM generation, transmission, and reception should be managed by VBS.

[0053] 2.1.2. V-ITS-S The VBS service is activated along with ITS-S activation for V-ITS-S to receive VAM messages. The VBS service should be terminated when ITS-S is deactivated. As long as the VBS service is active, VAM reception should be managed by VBS.

[0054] 2.1.3. R-ITS-S The VBS service can be activated along with ITS-S activation or by remote configuration. Similarly, the VBS service can be deactivated along with ITS-S deactivation or by remote configuration. For example, in the case of activation / deactivation based on remote configuration, the VBS for an R-ITS-S closer to the school can be configured to be activated during student pick-up / drop-off times and deactivated at other times. As long as the VBS service is active, VAM reception should be managed by VBS on the R-ITS-S. As long as the VBS service is active and the R-ITS-S is configured to send infrastructure VAMs, VAM generation is managed by VBS.

[0055] 2.2. VAM Generation Frequency Management for VRU Devices Each VAM generation event results in the generation of one VAM. The generated VAM can be segmented as described below.

[0056] The minimum elapsed time between the start of consecutive VAM generation events should be greater than or equal to the value T_GenVam, where T_GenVamMin ≤ T_GenVam ≤ T_GenVamMax, where T_GenVamMin = minimum time between consecutive VAM transmissions (e.g., 100 ms) and T_GenVamMax = maximum time between consecutive VAM transmissions (e.g., 500 ms).

[0057] If information regarding channel congestion in the access layer is available in the facility layer, T_GenVam should be adjusted accordingly; for example, a longer T_GenVam can be defined for higher channel congestion. The congestion layer in the access layer can also be estimated in the facility layer, for example, by monitoring the average success rate of periodic data from neighbors (e.g., BSM, CAM, PSM, VAM) over a historical travel time window. A decrease in such an average success rate may indicate an increase in the congestion level in the access layer.

[0058] The parameter T_GenVam should be provided by the facility layer's management entity. If the management entity provides a value for this parameter greater than T_GenVamMax, T_GenVam will be set to T_GenVamMax; if the value is less than T_GenVamMin, or if this parameter is not provided, T_GenVam will be set to T_GenVamMin. The parameter T_GenVam represents the currently valid lower limit of the elapsed time between consecutive VAM generation events.

[0059] If VRU ITS-S is in the VRU-ACTIVE-STANDALONE VBS state (as specified in [TS103300-3]), VRU ITS-S sends a VAM of type "Single VRU VAM". If VRU ITS-S is in the VRU-ACTIVE-CLUSTERHEAD VBS state (see, for example, [TS103300-3]) (for example, if VRU ITS-S is the cluster head of a VRU cluster), VRU ITS-S sends a VAM of type "VRU Cluster VAM" on behalf of the VRU cluster. A Single VRU VAM contains information about the originating VRU ITS, and a VRU Cluster VAM contains information about the VRU cluster.

[0060] 2.2.1. Individual VAM transmission management using VBS in VRU ITS-S If any of the following conditions are met and a single VRU VAM transmission is not subject to the redundancy mitigation techniques specified in Section B.3, the first “single VRU VAM” should be generated immediately or at the earliest possible time for transmission. 1. The VRU is in the VRU-IDLE VBS state and has entered the VRU-ACTIVE-STANDALONE VBS state. 2. The VRU is in the VRU-PASSIVE VBS state and has decided to leave the cluster and enter the VRU-ACTIVE-STANDALONE VBS state. 3. The VRU is in the VRU-PASSIVE VBS state and has determined that one or more new vehicles or other VRUs (e.g., VRU Profile 3 - Motorcycle Driver) are approaching within the Minimum Safe Lateral Distance (MSLaD), within the Minimum Safe Longitudinal Distance (MSLoD), and within the Minimum Safe Vertical Distance (MSVD), and has decided to leave the cluster and enter the VRU-ACTIVE-STANDALONE VBS state to send an immediate VAM. 4. The VRU is in the VRU-PASSIVE VBS state, has determined that the VRU cluster head has been lost, and has decided to enter the VRU-ACTIVE-STANDALONE VBS state. 5. The VRU is in the VRU-ACTIVE-CLUSTERHEAD VBS state, has decided to dismantle the cluster, has sent a VRU cluster VAM with a dissolution instruction, and has decided to enter the VRU-ACTIVE-STANDALONE VBS state.

[0061] Consecutive VAM transmissions are subject to the conditions described herein. Consecutive single VRU VAM generation events should occur at intervals of T_GenVam or greater. If the originating VRU ITS-S is still in the VBS VRU-ACTIVE-STANDALONE VBS state, and any of the following conditions are met, and the individual VAM transmission is not subject to redundancy mitigation techniques (described later), then an individual VAM should be generated for transmission as part of a generation event. 1. The elapsed time since the last transmission of a single VRU VAM exceeds T_GenVamMax. 2. The Euclidean absolute distance between the current estimated position of the VRU reference point and the estimated position of the reference point last included in a single VRU VAM exceeds a predefined threshold (e.g., 4m). In some implementations, the predefined threshold can be minReferencePointPositionChangeThreshold. 3. The difference between the current estimated ground speed of the VRU reference point and the estimated absolute speed of the VRU reference point last included in a single VRU VAM exceeds a predefined threshold (e.g., 0.5 m / s). In some implementations, the predefined threshold can be minGroundSpeedChangeThreshold. 4. The difference between the direction of the current estimated ground velocity vector of the VRU reference point and the estimated direction of the ground velocity vector of the VRU reference point last included in a single VRU VAM exceeds a predefined threshold (e.g., 4 degrees). In some implementations, the predefined threshold may be minGroundVelocityOrientationChangeThreshold. 5. The difference between the current estimated collision probability with a vehicle or other VRU (e.g., measured by the trajectory interception probability) and the last reported estimated collision probability with a vehicle or other VRU in a single VRU VAM exceeds a predefined threshold (e.g., 4%). In some implementations, the predefined threshold may be minTrajectoryInterceptionProbChangeThreshold. 6. The originating ITS-S is a VRU in the VRU-ACTIVE-STANDALONE VBS state and has decided to join the cluster after sending a single VRU VAM. 7. The VRU determines that one or more new vehicles or other VRUs (e.g., VRU Profile 3 - Motorcycle Driver) simultaneously meet the following conditions after the last VAM was sent: a. Being closer than the minimum safe lateral distance (MSLaD) in the lateral direction. b. The distance in the vertical direction is less than the minimum safe vertical distance (MSLoD). c. Being closer than the minimum safe vertical distance (MSVD) in the vertical direction. 8. The VRU determines that one or more vehicles or other VRUs (e.g., VRU Profile 3 - Motorcycle Driver) simultaneously meet the following conditions after the last VAM sent (e.g., after the previous VAM sent): a. The vehicle is located further than the minimum safe lateral distance (MSLaD) in the lateral direction. b. The object is located further than the minimum safe vertical distance (MSLoD) in the vertical direction. c. Being further vertically than the minimum safe vertical distance (MSVD), and d. These vehicles or these VRUs (e.g., VRU Profile 3 - Motorcycle Driver) i. Closer to the minimum safe lateral distance (MSLaD) in the lateral direction, ii. Closer to the minimum safe vertical distance (MSLoD) in the vertical direction, iii. The last transmitted VAM is closer than the minimum safe vertical distance (MSVD) in the vertical direction.

[0062] 2.2.2. VRU Cluster VAM Transmission Management using VBS in VRU ITS-S If any of the following conditions are met and the VRU cluster VAM transmission is not subject to redundancy mitigation techniques, the first VRU cluster VAM should be generated immediately or at the earliest possible time for transmission. 1. VRU-ACTIVE-STANDALONE: VRUs in the VBS state decide to form a VRU cluster.

[0063] Consecutive VRU cluster VAM transmissions are subject to the conditions described herein. Consecutive VRU cluster VAM generation events should occur at the cluster head at intervals of T_GenVam or greater. A VRU cluster VAM should be generated for transmission by the cluster head as part of a generation event if any of the following conditions are met and the VRU cluster VAM transmission is not subject to redundancy mitigation techniques. 1. The elapsed time since the last VRU cluster VAM transmission exceeds T_GenVamMax. 2. The Euclidean absolute distance between the current estimated position of the VRU cluster's reference point and the estimated position of the reference point last included in the VRU cluster VAM exceeds a predefined threshold (e.g., 4m). In some implementations, the predefined threshold can be minReferencePointPositionChangeThreshold. 3. The difference between the current estimated ground velocity of the VRU cluster's reference point and the estimated absolute velocity of the reference point last included in the VRU cluster VAM exceeds a predefined threshold. In some implementations, the predefined threshold can be minClusterDistanceChangeThreshold. 4. The difference between the current estimated width of the cluster and the estimated width included in the last submitted VAM exceeds a predefined threshold (e.g., 2m). 5. The difference between the current estimated length of the cluster and the estimated length included in the last submitted VAM exceeds a predefined threshold (e.g., 2m). 6. The difference between the current estimated ground speed of the VRU cluster's reference point and the estimated absolute speed of the reference point last included in the VRU cluster VAM exceeds a predefined threshold (e.g., 0.5 m / s). In some implementations, the predefined threshold can be minGroundSpeedChangeThreshold. 7. The difference between the direction of the current estimated ground velocity vector of the reference point in the VRU cluster and the estimated direction of the ground velocity vector of the reference point last included in the VRU cluster VAM exceeds a predefined threshold (e.g., 4 degrees). In some implementations, the predefined threshold may be minGroundVelocityOrientationChangeThreshold. 8. The difference between the current estimated collision probability of a VRU cluster with a vehicle or other VRU (measured, e.g., by the trajectory interception probability of other vehicles / VRUs with the cluster boundary area) and the last reported estimated collision probability with a vehicle or other VRU in VAM exceeds Y% (e.g., 4%). In some implementations, a predefined threshold may be minTrajectoryInterceptionProbChangeThreshold. 9. The VRU cluster type has changed since the previous VAM generation event (for example, from a homogeneous cluster to a heterogeneous cluster, or vice versa). 10. The cluster head has decided to dissolve (break up) the cluster after the previous VRU cluster VAM has been sent. 11. The cluster head has decided to merge the cluster with another cluster after the previous VRU cluster VAM has been sent. 12. The cluster head now recognizes the current cluster split after the previous VRU cluster VAM has been sent. 13. After the previous VRU cluster VAM was sent, more than the predefined number of new VRUs (e.g., 3) have joined the VRU cluster. 14. After the previous VRU cluster VAM was sent, more than a predefined number of member VRUs (e.g., 3) have left the VRU cluster. 15. A VRU in VRU-ACTIVE-CLUSTERHEAD VBS state determines that one or more new vehicle or non-member VRUs (e.g., VRU profile 3 - motorcycle driver) simultaneously meet the following conditions after the last VAM transmission: a. Approaching the target laterally beyond the minimum safe lateral distance (MSLaD). b. Approaching the target in the vertical direction beyond the minimum safe vertical distance (MSLoD). c. The cluster boundary box is closer than the Minimum Safe Vertical Distance (MSVD) perpendicular to the last transmitted VAM. 16. A VRU in VRU-ACTIVE-CLUSTERHEAD VBS state determines that one or more vehicle or non-member VRUs (VRU profile 3 - motorcycle driver) simultaneously meet the following conditions after the last transmitted VAM: a. The vehicle moved further lateral than the minimum safe lateral distance (MSLaD). b. The vehicle moved further than the minimum safe vertical distance (MSLoD) in the vertical direction. c. The cluster boundary box was located more than the minimum safe vertical distance (MSVD) perpendicular to it. d. The vehicle and / or non-member VRU (e.g., VRU profile 3 - motorcycle driver) was closer to the cluster boundary box in the last transmitted VAM than the minimum safe lateral distance (MSLaD), the minimum safe longitudinal distance (MSLoD), and the minimum safe vertical distance (MSVD).

[0064] 2.2.3. VAM Redundancy Mitigation Technology A balance between the frequency of VAM generation at the facility layer and the communication overhead at the access layer should be considered without affecting nearby VRU security and VRU recognition. VAM transmission in a VAM generation event is subject to one or more of the following redundancy mitigation techniques. In addition, or alternatively, one or more of the following redundancy mitigation techniques may be combined or separated. Furthermore, in the following discussion, “peer ITS-S” may refer to any of the ITS-S discussed herein, such as another VRU ITS-S116 / 117, V-ITS-S110, R-ITS-S130, and / or any other ITS station.

[0065] 2.2.3.1. Redundancy Reduction Techniques 1 The originating VRU ITS-S will skip the current individual VAM if all of the following conditions are met simultaneously. The time elapsed since the last VAM was sent by the originating VRU ITS-S does not exceed numSkipVamsForRedundancyMitigation(e.g., 4) × T_GenVamMax. The Euclidean absolute distance between the current estimated position of the reference point in the originating VRU ITS-S and the estimated position of the reference point in the received VAM from the peer ITS-S is less than the minReferencePointPositionChangeThreshold (e.g., 4m). The difference between the current estimated speed of the reference point in the originating VRU ITS-S and the estimated absolute speed of the reference point in the received VAM from the peer ITS-S is less than minGroundSpeedChangeThreshold (e.g., 0.5 m / s). The difference between the direction of the current estimated ground velocity vector of the originating VRU ITS-S and the estimated direction of the ground velocity vector of the reference point in the received VAM from the peer ITS-S is less than the minGroundVelocityOrientationChangeThreshold (e.g., 4 degrees).

[0066] Alternatively, one of the following conditions is met: Refer to an appropriate map to verify whether the VRU is located within a protected area such as a building or an area where driving is impossible. The VRU must be located within a geographical area designated as a pedestrian-only zone (low-risk geographical area). Only VRU profiles 1 and 4 are permitted in this area (see table). The VRU considers itself a member of the VRU cluster and has not received a cluster disintegration message from the cluster leader. Information regarding the self-VRU is being reported by another ITS-S within T_GenVam.

[0067] 2.2.3.2. Redundancy Reduction Techniques 2 The originating VRU ITS-S will skip the current individual VAM if all of the following conditions are met simultaneously. The time elapsed since the last VAM was sent by the originating VRU ITS-S does not exceed numSkipVamsForRedundancyMitigation(e.g., 4) × T_GenVamMax. The VAM must have been received from peer ITS-S during the last T_GenVamMax time. The Euclidean absolute distance between the current estimated position of the reference point in the originating VRU ITS-S and the estimated position of the reference point in the received VAM from the peer ITS-S is less than minReferencePointPositionChangeThreshold (e.g., 4m). The difference between the current estimated speed of the reference point in the originating VRU ITS-S and the estimated absolute speed of the reference point in the received VAM from the peer ITS-S is less than minGroundSpeedChangeThreshold (e.g., 0.5 m / s). The difference between the direction of the current estimated ground velocity vector of the originating VRU ITS-S and the estimated direction of the ground velocity vector of the reference point in the received VAM from the peer ITS-S is less than minGroundVelocityOrientationChangeThreshold (e.g., 4 degrees).

[0068] 2.2.3.3. Redundancy Reduction Techniques 3 The originating VRU ITS-S skips the current VAM if all of the following conditions are met simultaneously. The elapsed time since the last VAM transmission by the originating VRU ITS-S does not exceed N (e.g., 4) × T_GenVamMax. During the last T_GenVamMax time, VAM (VRU cluster VAM or VRU cluster container within the infrastructure VAM) must have been received from peer ITS-S. The Euclidean absolute distance between the current estimated position of the reference point of the source VRU ITS-S and the nearest point within the bounding box of the cluster specified by the receiving VAM is less than a predefined threshold (e.g., 4m). The difference between the current estimated velocity of the reference point of the originating VRU ITS-S and the estimated absolute velocity of the reference point of the VRU cluster in the receiving VAM is less than a predefined threshold (e.g., 0.5 m / s). The difference between the direction of the current estimated ground velocity vector of the reference point of the originating VRU ITS-S and the estimated direction of the ground velocity vector of the reference point of the VRU cluster in the receiving VAM is less than a predefined threshold (e.g., 4 degrees).

[0069] 2.2.4. VAM Segmentation The size of the generated VAM should not exceed the maximum transmission unit (MTU) supported by the VBS NF-SAP (see, for example, [TS103300-3]). The MTU for the VAM may be called "MTU_VAM," etc. MTU_VAM depends on the MTU of the access layer technology on which the VAM is carried (MTU_AL). Specifically, MTU_VAM should be less than or equal to MTU_AL minus the header size of the facility layer protocol (HD_VAM) and the header size of the networking and transport layer protocols (HD_NT), i.e., MTU_VAM ≤ (MTU_AL - HD_VAM - HD_NT).

[0070] The current VAM capability will be extended to allow segmentation of VAM into two or more segments. The current VAM format specification does not allow VAM segmentation. VAM segmentation is unavoidable in order to limit the VAM size to less than the MTU supported by the lower layers. A new container "VamManagementParameters" can be added to the existing VAM structure for this purpose to carry segmentation information, as shown in Table 3. [Table 3]

[0071] If the size of the ASN.1 UPER-encoded VAM for transmission exceeds MTU_VAM, message segmentation should be performed. Content is included in the VAM segments in descending order of inclusion priority.

[0072] Message segmentation should be indicated by reading the VamSegmentInfo DF. All message segments should show the same generationDeltaTime DE.

[0073] Message segments can be sent in the same order in which they were generated. This is to prevent segments containing higher-priority containers from being postponed by lower-tier mechanisms for segments containing lower-priority containers.

[0074] 2.2.4.1. VAM Segmentation Management using VBS in VRU ITS-S If the size of the ASN.1 UPER encoded VAM (single VRU VAM or VRU cluster VAM) for transmission in the current VAM generation event exceeds MTU_VAM, message segmentation should be performed. The selected container should be included in the VAM segment in descending order of VruProfileId, VruDynamicProperties, VruPhysicalProperties, and VamExtension.

[0075] A container should be loaded into a segment as long as the resulting ASN.1 UPER encoded message size does not exceed MTU_VAM. A container should not be split into two VAM segments. The segment is generated in this manner until all containers are included in a VAM segment. Each segment is sent at the next transmission opportunity.

[0076] 2.3. VAM Time Requirements 2.3.1.VAM generation time In addition to the frequency of VAM generation, the time required for VAM generation and the timeliness of the data taken for message construction are critical to the data applicability at the receiving ITS-S. To ensure proper interpretation of received VAMs, each VAM is time-stamped. It is assumed that there is acceptable time synchronization between different ITS-S.

[0077] The time required for VAM generation should be less than the threshold T_AssembleVAM (e.g., 50ms). The time required for VAM generation refers to the time difference between the time VAM generation is triggered and the time VAM is sent to the networking and transport layer.

[0078] 2.3.2. VAM Timestamp The following requirements apply to VAM timestamp assignment. The reference timestamp provided in the VAM distributed by ITS-S corresponds to the time when the reference position provided in the BasicContainer DF and / or VruPhysicalProperties DF is determined by the originating ITS-S. The format and range of the timestamp are discussed in Table 4 and / or defined in Section B.1.3 of [TS103300-3] and / or Section B.3 of [EN302637-2]. [Table 4] The difference between the VAM generation time and the reference timestamp should be less than 32767ms.

[0079] 2.4. Exemplary VAM Parameters The parameters in Table 5 influence VRU decisions to create, join, or leave a cluster. These parameters may be set for individual devices or the entire system, and may be dependent on or independent of external conditions. [Table 5]

[0080] The parameters in Table 6 affect messaging behavior before and after joining and leaving a cluster. These parameters may be set for individual devices or the entire system, and may be dependent on or independent of external conditions. [Table 6]

[0081] Table 7 shows the parameters for VAM generation. The parameters may be set for individual devices or for the entire system, and may be dependent on or independent of external conditions. [Table 7]

[0082] The parameters in Table 8 influence the VAM generation trigger. These parameters may be set for individual devices or the entire system, and may be dependent on or independent of external conditions. [Table 8] JPEG0007871516000009.jpg150152

[0083] 2.5. Example Implementation of VAM One exemplary implementation of VAM may include the data fields (DFs) and data elements (DEs) shown in Table 9, which are represented in ASN.1 form based on SAE International, “Dedicated Short Range Communications (DSRC) Message Set Dictionary,” V2X Core Technical Committee, SAE Ground Vehicle Standard J2735, DOI:https: / / doi.org / 10.4271 / J2735_202007(July 23, 2020) ("[SAE-J2735]"). [Table 9] JPEG0007871516000011.jpg222152JPEG0007871516000012.jpg222152JPEG0007871516000013.jpg222152JPEG0007871516000014.jpg127152

[0084] Vulnerable Road User Recognition Messages (VAMs) are messages sent from VRU ITSs to create and maintain recognition of vulnerable road users participating in the VRU system. VAMs contain status and attribute information of the originating VRU ITS-S. The content may vary depending on the VRU ITS-S profile. Typical status information includes time, location, motion status, cluster status, etc. Typical attribute information includes data on the VRU profile, type, dimensions, etc. The generation, transmission, and reception of VAMs are managed by VRU Basic Services (VBS). VRU Basic Services is a facility layer entity that operates the VAM protocol. VRU Basic Services provides three main services: handling VRU roles, and transmitting and receiving VAMs to enhance VRU security. VBS also specifies the concept of VRU clustering in the presence of high-density VRUs to reduce VAM communication overhead. In VRU clustering, nearby VRUs with coherent speed and direction of travel form a facility layer VRU cluster, and only the cluster head VRU transmits VAMs. Other VRUs within the cluster will skip sending VAMs. Active VRUs (not within the VRU cluster) will send separate VAMs (called single VRU VAMs).

[0085] VAMs originating from a VRU ITS do not effectively address the recognition of unequipped VRUs (e.g., VRUs without an ITS-S for Tx, Rx, or both Tx / Rx). In many congested situations, such as busy intersections, pedestrian crossings, school drop-off / pick-up areas, public bus stops, school bus stops, busy intersections near shopping malls, construction work areas, and others, both equipped and unequipped VRUs are present. Cluster formation and management by individual VRU ITS-S (as cluster leaders) is limited by available resources (computation, communication, sensing). VRU clusters formed by individual VRUs cannot include unequipped VRUs in the cluster. In such cases, VRUs must be able to decode and interpret collective perception messages (CPMs) to obtain complete environmental awareness for safety. For this purpose, infrastructure (such as R-ITS-S) can play a crucial role in detecting potential VRUs (via sensors) and grouping them together into clusters in such scenarios that include both equipped and unequipped VRUs. For example, static RSEs may be installed at congested intersections, pedestrian crossings, school drop-off / pick-up areas, and busy intersections near shopping malls for this purpose, while mobile RSEs may be installed on designated vehicles (such as school buses, city buses, and commercial vehicles) to function as infrastructure / RSE at public bus stops, school bus stops, and construction work areas.

[0086] The current standard (see, for example, [TS103300-3]) discusses various forms of VAM formatting and transmission using only VRU ITS-S, but the current standard does not allow non-VRU ITS-S to transmit VAM.

[0087] Existing VAMs allow information sharing for either a single VRU or a single VRU cluster. However, in the case of non-VRU ITS-S (e.g., RSE or designated vehicle) VAMs, the non-VRU ITS-S may be able to detect one or more individual VRUs and / or one or more VRU clusters within the FOV that need to be reported in the VAM. This specification presents modifications to the existing VAM format to enable non-VRU ITS-S VAMs. In a non-VRU ITS-S VAM, VRU-aware content for one or more VRUs and / or one or more VRU clusters is carried.

[0088] In the following discussion, VAMs generated and transmitted by non-VRU ITS-S (e.g., R-ITS-S130, V-ITS-S110, etc.) may be referred to as “non-VRU VAMs” (or “nVAMs”), and VAMs generated and transmitted by infrastructure equipment (e.g., R-ITS-S130) may be referred to as “infrastructure VAMs” (or “iVAMs”). iVAMs are transmitted by infrastructure equipment, and nVAMs are transmitted by other non-VRU ITS-S (e.g., V-ITS-S110, R-ITS-S130, etc.), but these terms may be used interchangeably throughout this disclosure.

[0089] In addition, we will consider the detailed mechanism of non-VRU ITS-S supported VRU clustering, which includes both equipped and unequipped VRUs, where non-VRU ITS-S (such as R-ITS-S) functions as the cluster leader and transmits non-VRU ITS-S VAMs.

[0090] Reporting all detected VRUs and / or VRU clusters individually by a non-VRU ITS can be highly inefficient in certain scenarios, such as the presence of a large number of VRUs or overlapping views of VRUs or occlusion of VRUs within the sensor's FOV in the originating non-VRU ITS-S. Such reporting via existing DF / DE within VAM in the case of a large number of perceived VRUs and / or VRU clusters would require significant communication overhead, as well as increased latency in reporting all VRUs and / or VRU clusters. A non-VRU ITS-S may require the use of self-admission control, redundancy mitigation, or self-contained segmentation to manage congestion at the access layer. Self-contained segments are independent VAM messages that can be sent in each consecutive VAM generation event.

[0091] 3.1. Infrastructure VAM Infrastructure-assisted VRU clustering includes both equipped and unequipped VRUs, with the infrastructure (e.g., R-ITS-S130) acting as the cluster head and transmitting VAMs. These VAMs may be referred to herein as “infrastructure VAMs” (or “iVAMs”). Thus, existing VBSs are extended to allow non-VRU ITS-S (e.g., R-ITS-S130 and / or specified V-ITS-S110) to transmit infrastructure VAMs (“iVAMs”). VAM trigger conditions / events and VAM formats are also modified for this purpose. In addition, or alternatively, some or all of the trigger events / conditions for the iVAM / nVAM and / or VAM formats described below are specific to non-VRUs and / or specific to infrastructure equipment.

[0092] The VAM format specification (see, for example, [TS103300-3]) lacks details about the content that should be included in a VRU cluster VAM. The content of a VRU cluster VAM sent by a non-VRU cluster head, and new DFs and DEs that include such content in the VAM, are described below.

[0093] Existing VAMs allow information sharing about either a single VRU or a single VRU cluster. However, in the case of non-VRU ITS-S VAM transmissions, non-VRU ITS-S may discover one or more individual VRU116s and / or one or more VRU clusters that need to be reported in the VAM. As described later, the VBS and VAM formats are extended to allow non-VRU ITS-S to report VRU-aware content for one or more VRU116s and / or one or more VRU clusters within the same infrastructure VAM.

[0094] Current standards (see, e.g., [TS103300-3]) do not allow VAM segmentation. However, VAM segmentation is unavoidable to limit the VAM size to less than the maximum transmission unit (MTU) supported by the lower layers. Specifically, VAM segmentation may be useful for iVAMs reported by non-VRU ITS-S because the iVAM contains VRU-aware content for one or more VRU116s and / or one or more VRU clusters within the same VAM. The VBS operation and VAM format are modified as described below to allow segmentation of the VAM into two or more VAM segments. This specification also discusses utility function calculations for each candidate (e.g., perceived VRUs and VRU clusters selected to be included in the VAM to be segmented) that serve as a priority for determining the order in which to include them in consecutive VAM segments. In summary, An infrastructure-assisted VRU clustering mechanism that includes both equipped and unequipped VRUs, where the infrastructure (e.g., R-ITS-S130) acts as the cluster head and sends VAMs (called infrastructure VAMs). This extends the existing VRU Basic Services (VBS) to allow non-VRU ITS-S (such as RSUs and designated vehicles) to send infrastructure VAMs, including VAM triggers and VAM format changes for this purpose. This provides content for the VRU cluster VAM (sent by either the V-ITS-S cluster head or the R-ITS-S cluster head), and new DFs and DEs that include these provided contents in the VAM. This modifies existing VBS and VAM formats to enable non-VRU ITS-S to report VRU-aware content for one or more VRUs and / or one or more VRU clusters within the same infrastructure VAM. Modify the VBS behavior and VAM format to enable segmentation of a VAM into two or more segments, including calculating a utility function for each candidate (e.g., perceived VRUs and VRU clusters selected to be included in the VAM to be segmented) that serves as a priority for determining the order in which to include consecutive VAM segments. A new DE / DF for VAM is provided, allowing the CH (cluster head) to send multiple instructions, along with the reason for dissolution, to its members before dissolving the VRU cluster. Under the existing VAM format, the CH cannot send a dissolution instruction before dissolving the VRU cluster. This extends the existing VAM to enable CH role handover to a new ITS-S when an existing CH is no longer interested in the CH role, or when a CH is about to move out of the VRU cluster boundary box. Provide a new container (ClusterMergeInfo) to merge two or more clusters whose bounding boxes are close together and partially or completely overlap. A new container (ClusterSplitInfo) is provided to enable cluster splitting in two or more new clusters.

[0095] In various implementations, the station provides ITS services, which include sending and receiving ITS service messages (e.g., VAMs). In facility layer messages, the application container is used together with the ITS PDU header and / or ITS service container.

[0096] Several implementations can be specified and / or standardized in ETSI ITS standards / frameworks and / or edge computing standards / frameworks (e.g., Multi-Access Edge Computing (MEC)), and these implementations are easily scalable across cities or geographical areas. In these implementations, one or more edge computing applications (e.g., MEC apps) can provide VBS and generate, receive, and transmit VAM.

[0097] 3.1.1. VAM generation using non-VRU ITS-S Non-VRU ITS-S may include, for example, R-ITS-S130 and / or V-ITS-S110. Current standards and solutions (see, e.g., [TS103300-3]) do not effectively address the recognition of unequipped VRUs. In many cases, such as congested intersections, crosswalks, school drop-off / pick-up areas, public bus stops, school bus stops, congested intersections near shopping malls, and construction work areas, both equipped and unequipped VRUs exist. Forming clusters by individual VRUs may not be straightforward, and VRU clusters formed by VRUs cannot include unequipped VRUs in the cluster. Infrastructure (e.g., RSU ITS-S) can play a crucial role in detecting potential VRU clusters in such scenarios that include both equipped and unequipped VRUs. For example, for this purpose, static RSUs may be installed at congested intersections, pedestrian crossings, school drop-off / pick-up areas, and congested intersections near shopping malls, while mobile RSUs may be installed on designated vehicles (such as school buses, city buses, and commercial vehicles) to function as infrastructure / RSUs at public bus stops, school bus stops, and construction work areas. Similarly, vehicle sensors can detect equipped VRUs as well as unequipped VRUs or VRU clusters and report VAMs. Any VAM transmitted from a non-VRU ITS-S (e.g., R-ITS-S130 and / or V-ITS-S110) is referred to as an "infrastructure VAM". The following discussion relates to examples of R-ITS-S / RSUs that transmit and / or receive VAMs, but the description herein is also applicable to VAMs generated and transmitted / received from vehicle ITS-S.

[0098] Non-VRU ITS-S (e.g., R-ITS-S130) constantly detects / perceives equipped and unequipped VRUs from local sensors and / or receives V2X messages such as BSM, CAM, DENM, CPM, VAM, etc. from vehicles and VRUs. RSU may detect several VRUs at an intersection or on a sidewalk.

[0099] In other cases, the R-ITS-S130 (e.g., roadside equipment (RSE), roadside unit (RSU), etc.) may be located in the same place as the smart traffic signal controller and / or other traffic control elements. Several VRUs waiting to cross the intersection may request or instruct the traffic signal controller to cross the intersection. The RSU may retrieve this information from the traffic signal container and use this information to create a VRU cluster.

[0100] When several VRU116s are detected by the R-ITS-S130, the R-ITS-S130 decides to generate an infrastructure VAM as described in Section 2.2 below. If several perceived VRU116s (e.g., exceeding a threshold number) are very close to each other in coherent speed and direction of travel, as defined (see, e.g., [TS103300-3]), the R-ITS-S130 may decide to report them as a cluster and have them act as a cluster head (CH). The RSU may find two or more such VRU clusters to report, e.g., VRUs crossing an intersection or VRUs walking on a sidewalk. Some VRUs may need to be reported individually because they are far from other VRUs or their speeds may differ by more than a threshold for speed difference.

[0101] When R-ITS-S130 decides to report one or more individual perceived VRUs and / or one or more perceived VRU clusters, it generates VAMs and reports them together in a single infrastructure VAM. By sending the VAM and specifying the cluster boundary box, R-ITS-S130 indicates that it is acting as the cluster head for the perceived cluster. Equipped VRUs within the reported boundary box stop sending VAMs.

[0102] In some cases, a VRU cluster may have already been reported by a VRU-ITS-S, and the RSU perceives unequipped VRUs within and / or around the reported cluster boundary box. The RSU may send a VAM containing both equipped and unequipped VRUs using the same or an expanded boundary box. The VRU-ITS-S acting as the cluster head then stops sending VRU cluster VAMs.

[0103] 3.1.2. Facility VAM Generation Frequency Management for VRU Devices 3.1.2.1. VAM generation and frequency for infrastructure VAM Each VAM generation event results in the generation of one VAM. The generated VAM can be segmented as described below.

[0104] The minimum elapsed time between the start of consecutive VAM generation events should be greater than or equal to the value T_GenVam, where T_GenVamMin ≤ T_GenVam ≤ T_GenVamMax, where T_GenVamMin = minimum time between consecutive VAM transmissions (e.g., 100 ms) and T_GenVamMax = maximum time between consecutive VAM transmissions (e.g., 500 ms).

[0105] If information regarding channel congestion in the access layer is available in the facility layer, T_GenVam should be adjusted accordingly; for example, a longer T_GenVam can be defined for higher channel congestion. The congestion layer in the access layer can also be estimated in the facility layer, for example, by monitoring the average success rate of periodic data from neighbors (e.g., BSM, CAM, PSM, VAM) over a historical travel time window. A decrease in such an average success rate may indicate an increase in the congestion level in the access layer.

[0106] The parameter T_GenVam should be provided by the facility layer's management entity. If the management entity provides a value for this parameter greater than T_GenVamMax, T_GenVam will be set to T_GenVamMax. If the value is less than T_GenVamMin, or if this parameter is not provided, T_GenVam will be set to T_GenVamMin. The parameter T_GenVam represents the currently valid lower limit of the elapsed time between consecutive VAM generation events.

[0107] 3.1.2.2. VAM transmission in non-VRU ITS-S A VRU ITS-S in the VRU-ACTIVE-STANDALONE state will send an "individual VAM," while a VRU ITS-S in the VRU-ACTIVE-CLUSTERLEADER VBS state will send a "cluster VAM" on behalf of the VRU cluster. A cluster member VRU ITS-S in the VRU-PASSIVE VBS state will send an individual VAM including the VruClusterOperationContainer while leaving the VRU cluster. A VRU ITS-S in the VRU-ACTIVE-STANDALONE state will send a VAM as an "individual VAM" including the VruClusterOperationContainer while participating in the VRU cluster.

[0108] In some cases, non-VRU ITS-S (e.g., static or mobile RSE on designated vehicles such as school buses, construction vehicles, or police cars) may need to send a VAM (e.g., an infrastructure VAM) in particular when a VRU that is not equipped is detected. Such an infrastructure VAM may be sent to report either an individual detected VRU or a cluster of VRUs. A non-VRU ITS-S may choose to send an infrastructure VAM that reports individual detected VRUs and clusters of VRUs in the same infrastructure VAM by including zero or more individual detected VRUs and zero or more VRU clusters in the same infrastructure VAM.

[0109] 3.1.2.3. VAM transmission management using VBS in non-VRU ITS-S If a non-VRU ITS-S has not yet sent a continuous (e.g., periodic) infrastructure VAM, and the infrastructure VAM transmission is not subject to redundancy mitigation techniques, the first infrastructure VAM should be generated for transmission immediately or at the earliest possible time when any of the following conditions are met: 1) At least one VRU is detected by a source non-VRU ITS-S, the detected VRU has not sent a VAM for at least T_GenVamMax time, the perceived location of the detected VRU does not fall within the bounding box of any cluster specified in any VRU cluster VAM received by a source non-VRU ITS-S during the last T_GenVamMax time, and the detected VRU is not included in any infrastructure VAM received by a source non-VRU ITS-S during the last T_GenVamMax time. 2) At least one VRU cluster is detected by a source non-VRU ITS-S, the cluster head of the detected VRU cluster has not sent a VRU cluster VAM for at least T_GenVamMax time, and the perceived bounding box of the detected VRU cluster does not overlap with the bounding box of any VRU cluster specified in a VRU cluster VAM or infrastructure VAM received by a source non-VRU ITS-S during the last T_GenVamMax time by a predefined threshold maxInterVRUClusterOverlapInfrastructureVAM.

[0110] Consecutive infrastructure VAM transmissions are subject to the conditions described herein. Consecutive infrastructure VAM generation events should occur at intervals of T_GenVam or greater. If the originating non-VRU ITS-S has at least one selected perceived VRU or VRU cluster that should be included in the current infrastructure VAM, then the infrastructure VAM should be generated for transmission as part of the generation event.

[0111] The current VAM capability will be extended to allow non-VRU ITS-S (e.g., RSUs or vehicles) to transmit VAMs. The current VAM format allows only VRU ITS-S (as individual VRUs or as VRU cluster heads) to transmit VAMs. Since VAM-transmitting ITS-S may not be the same VRU as in the case of VAMs generated by R-ITS-S (or V-ITS-S), new data elements (originatingStationType and originatingStationReferencePosition) will be included in the existing VAM to allow non-VRU ITS-S to transmit VAMs. These new DEs will be added to a new "VamManagementParameters" DF / container. OriginatingStationType indicates whether the VAM transmitting station is a VRU, vehicle, or RSU. originatingStationReferencePosition provides a reference point for all measurements related to the reported VRU or VRU cluster in the case of VAMs generated by non-VRU ITS-S. A new DE VamType will be introduced to indicate whether a VAM is a single VRU VAM, a VRU cluster VAM, or an infrastructure VAM, as shown below. Current VAM capabilities will be extended to allow non-VRU ITS-S to report VRU-aware content for one or more VRUs and / or one or more VRU clusters in the same VAM by defining "vamParameters SEQUENCE(SIZE(0..MAX))" in VamParameters. Existing VAMs will allow information sharing about either one VRU or one VRU cluster within each VAM. These changes are shown in Table 10. [Table 10] JPEG0007871516000016.jpg31152

[0112] The new ClusterID DE is used to specify a cluster ID that allows non-VRU ITS-S (e.g., R-ITS-S and V-ITS-S) to report multiple VRU clusters in the same VAM. The new clusterID includes the cluster head's station ID and an intraClusterHeadID to separate multiple clusters led / managed by the same non-VRU ITS-S. An example ClusterID DE is shown in Table 11. [Table 11]

[0113] If a non-VRU ITS-S has not yet sent a continuous (e.g., periodic) infrastructure VAM, and the infrastructure VAM transmission is not subject to redundancy mitigation techniques, then an infrastructure VAM should be generated immediately or at the earliest possible time for transmission, provided that any of the following conditions are met: 1. At least one VRU is detected by a source non-VRU ITS-S, the detected VRU has not sent a VAM for at least T_GenVamMax time, the perceived location of the detected VRU does not fall within the bounding box of any cluster specified in any VRU cluster VAM received by a source non-VRU ITS-S during the last T_GenVamMax time, and the detected VRU is not included in any infrastructure VAM received by a source non-VRU ITS-S during the last T_GenVamMax time. 2. At least one VRU cluster is detected by a source non-VRU ITS-S, the cluster head of the detected VRU cluster has not sent a VRU cluster VAM for at least T_GenVamMax time, and the perceived bounding box of the detected VRU cluster does not overlap by a predefined threshold (e.g., 80%) with the bounding box of any VRU cluster specified in a VRU cluster VAM or infrastructure VAM received by a source non-VRU ITS-S during the last T_GenVamMax time.

[0114] Consecutive infrastructure VAM transmissions are subject to the following conditions: Consecutive infrastructure VAM generation events should occur at intervals of T_GenVam or greater. If the originating non-VRU ITS-S has at least one selected perceived VRU or VRU cluster that should be included in the current infrastructure VAM, then the infrastructure VAM should be generated for transmission as part of the generation event.

[0115] 3.1.2.4. Perceived VRU Inclusion Management in Current Infrastructure VAM and / or Other Non-VRU ITS-S VAMs Perceived VRUs to be considered for inclusion in the current infrastructure VAM should meet all of the following conditions: 1) The originating non-VRU ITS-S has not received any VAM from the detected VRU for at least T_GenVamMax time. 2) The perceived location of the detected VRU does not fall within the bounding box of any VRU cluster specified in any VRU cluster VAM received by the source non-VRU ITS-S during the last T_GenVamMax time. 3) The detected VRU is not included in the infrastructure VAM received by the source non-VRU ITS-S during the last T_GenVamMax time, and 4) The detected VRU does not belong to any of the infrastructure VAMs (including VRU clusters that should be included in the current infrastructure VAM) reported by the originating non-VRU ITS-S.

[0116] If a perceived VRU also satisfies one of the following conditions, then the VRU that is perceived with sufficient confidence to satisfy the above conditions and is not subject to redundancy mitigation techniques should be selected for inclusion in the current VAM generation event. 1) The VRU is first detected by a source non-VRU ITS-S after the last infrastructure VAM generation event. 2) The elapsed time since the perceived VRU was last included in the infrastructure VAM exceeds T_GenVamMax. 3) The Euclidean absolute distance between the current estimated position of the perceived VRU reference point and the estimated position of the last perceived VRU reference point included in the infrastructure VAM exceeds a predefined threshold minReferencePointPositionChangeThreshold (e.g., 4m). 4) The difference between the current estimated ground speed of the perceived VRU reference point and the estimated absolute speed of the perceived VRU reference point last included in the infrastructure VAM exceeds a predefined threshold minGroundSpeedChangeThreshold (e.g., 0.5 m / s). 5) The difference between the current estimated ground velocity vector orientation of the perceived VRU reference point and the estimated ground velocity vector orientation of the last perceived VRU reference point included in the infrastructure VAM exceeds a predefined threshold minGroundVelocityOrientationChangeThreshold (e.g., 4 degrees). 6) The difference between the perceived current estimated collision probability of a VRU with a vehicle or other VRU (e.g., measured by the trajectory disruption probability) and the last reported estimated collision probability with a vehicle or other VRU in the Infrastructure VAM exceeds a predefined threshold (e.g., 4%). 7) One or more new vehicles or other VRUs (e.g., VRU Profile 3 - Motorcycle Driver) are closer to a VRU than the minimum safe lateral distance (MSLaD), the minimum safe longitudinal distance (MSLoD), and the minimum safe vertical distance (MSVD) in the longitudinal direction after the last transmitted Infrastructure VAM. 8) One or more vehicles or other VRUs (e.g., VRU Profile 3 - Motorcycle Driver) are located beyond the minimum safe lateral distance (MSLaD) in the lateral direction, beyond the minimum safe longitudinal distance (MSLoD) in the longitudinal direction, and beyond the minimum safe vertical distance (MSVD) in the vertical direction, and these vehicles or these VRUs (e.g., VRU Profile 3 - Motorcycle Driver) are located beyond the minimum safe lateral distance (MSLaD) in the lateral direction, beyond the minimum safe longitudinal distance (MSLoD) in the longitudinal direction, and beyond the minimum safe vertical distance (MSVD) in the vertical direction, in the last transmitted infrastructure VAM.

[0117] 3.1.2.5. Perceived VRU Cluster Inclusion Management in Current Infrastructure VAM and / or Other Non-VRU ITS-S VAMs Perceived VRU clusters considered for inclusion in the current infrastructure VAM should meet all of the following conditions: 1. The perceived bounding box of a detected VRU cluster does not overlap by more than X% (80%) with the bounding box of a VRU cluster specified in either the VRU cluster VAM or infrastructure VAM received by the source non-VRU ITS-S during the last T_GenVamMax time.

[0118] If a perceived VRU cluster also satisfies one of the following conditions, then a VRU cluster that is perceived with sufficient confidence to satisfy the above conditions and is not subject to redundancy mitigation techniques should be selected for inclusion in the current VAM generation. 1. The VRU cluster is first detected by a non-VRU ITS-S originating after the last infrastructure VAM generation event. 2. The elapsed time since the perceived VRU cluster was last included in the infrastructure VAM exceeds T_GenVamMax. 3. The Euclidean absolute distance between the current estimated position of the reference point of the perceived VRU cluster and the estimated position of the reference point of the last perceived VRU cluster included in the infrastructure VAM exceeds a predefined threshold minReferencePointPositionChangeThreshold (e.g., 4m). 4. The difference between the current estimated width of the perceived VRU cluster and the estimated width of the perceived VRU cluster included in the last transmitted VAM exceeds a predefined threshold minClusterWidthChangeThreshold (e.g., 2m). 5. The difference between the current estimated length of the perceived VRU cluster and the estimated length of the perceived VRU cluster included in the last transmitted VAM exceeds a predefined threshold minClusterLengthChangeThreshold (e.g., 2m). 6. The difference between the current estimated ground speed of the perceived VRU cluster reference point and the estimated absolute speed of the reference point included in the last transmitted VAM exceeds a predefined threshold minGroundSpeedChangeThreshold (e.g., 0.5 m / s). 7. The difference between the current estimated ground velocity vector orientation of the reference point in the perceived VRU cluster and the estimated ground velocity vector orientation of the reference point included in the last transmitted infrastructure VAM exceeds a predefined threshold minGroundVelocityOrientationChangeThreshold (e.g., 4 degrees). 8. The difference between the current estimated collision probability of a perceived VRU cluster with a vehicle or other VRU (e.g., measured by the trajectory obstruction probability of the other vehicle / VRU's trajectory with the trajectory of the VRU cluster boundary box) and the estimated collision probability with a vehicle or other VRU last reported in the Infrastructure VAM exceeds a predefined threshold (e.g., 4%). 9. The originating non-VRU ITS-S has decided to merge the perceived cluster with another cluster after the previous infrastructure VAM generation event. 10. The originating non-VRU ITS-S has decided to split the current cluster after the previous infrastructure VAM generation event. 11. The originating non-VRU ITS-S determines a change in the perceived VRU cluster type (e.g., from homogeneous cluster to heterogeneous cluster, or vice versa) after the previous infrastructure VAM generation event. 12. The originating non-VRU ITS-S determines that one or more new vehicles or non-member VRUs (e.g., VRU profile 3 - motorcycle driver) are closer than the minimum safe lateral distance (MSLaD) in the lateral direction, closer than the minimum safe longitudinal distance (MSLoD) in the longitudinal direction, and closer than the minimum safe vertical distance (MSVD) in the vertical direction relative to the cluster boundary box since the last transmitted infrastructure VAM. 13. The originating non-VRU ITS-S determines that one or more vehicles or non-member VRUs (VRU profile 3 - motorcycle driver) are located beyond the minimum safe lateral distance (MSLaD), beyond the minimum safe longitudinal distance (MSLoD), and beyond the minimum safe vertical distance (MSVD) perpendicular to the cluster boundary box, and that these vehicles or these VRUs (e.g., VRU profile 3 - motorcycle driver) are located beyond the minimum safe lateral distance (MSLaD), beyond the minimum safe longitudinal distance (MSLoD), and within the last transmitted infrastructure VAM, they were located beyond the minimum safe vertical distance (MSVD) perpendicular to the cluster boundary box.

[0119] The explanation extends the current VAM capability to allow segmentation of VAMs into two or more segments. The current VAM format does not allow segmentation. VAM segmentation is unavoidable to limit the VAM size to less than the maximum transmission unit (MTU) supported by the lower layer, especially in the case of infrastructure VAMs reported by non-VRU ITS-S (such as RSUs). Note that the proposed infrastructure VAM can include VRU-aware content for one or more VRUs and / or one or more VRU clusters in the same VAM message. A new container "VamManagementParameters" is added to the existing VAM structure to carry segmentation information, as shown in Table 12. [Table 12]

[0120] 3.1.2.6. Other enhancements to VAM capabilities Details of the modifications to the existing VAM are provided in Section 2.3 below. Some of the modifications are as follows:

[0121] The explanation includes modifications to the existing VAM format that enable reporting of each VRU profile type present in a VRU cluster by defining "activeProfile as SEQUENCE(Size(0..Max)) of VruProfileId". The existing VAM format (see, for example, [TS103300-3]) cannot indicate whether the VRU cluster is homogeneous or heterogeneous, or, if heterogeneous, which types of VRUs are present in the VRU cluster. An example is shown in Table 13. [Table 13]

[0122] The VAM format modifications discussed herein enable VRUs to provide details related to joining and leaving (departing from) a cluster, along with the reasons for doing so. Table 14 shows an example of such a VAM. [Table 14]

[0123] The ClusterID DE is used to specify a cluster ID that allows non-VRU ITS-S (e.g., R-ITS-S and V-ITS-S) to report multiple VRU clusters in the same VAM. The new clusterID includes the station ID of the cluster head and an intraClusterHeadID to separate multiple clusters led / managed by the same non-VRU ITS-S. Table 15 shows an example of such a VAM. [Table 15]

[0124] A new DE / DF is provided to allow the cluster head (CH) to send multiple instructions, along with the reason for dissolution, to its members before dissolving the VRU cluster. Under the existing VAM format, the CH cannot send any dissolution instructions before dissolving the VRU cluster, which can result in a longer delay for its members to recognize the cluster's dissolution. An example is shown in Table 16. [Table 16] JPEG0007871516000023.jpg6152

[0125] The explanation extends existing VAMs to enable CH role handovers to new ITS-S in several scenarios, such as when an existing CH is no longer interested in the CH role, or when a CH is about to move out of the VRU cluster boundary box. For example, during an intersection crossing, a CH may reach the sidewalk on the other side of the road and no longer need to be in the cluster, while others are still on the intersection / crosswalk and require clustering. These changes allow existing CHs to smoothly select new CHs and handover CH roles. Otherwise, the VRU cluster would need to be disbanded, requiring the initiation of a new VRU clustering process that would incur significant VAM overhead. Note that after disbanding, all members must send at least one VAM before joining the new cluster. An example is shown in Table 17. [Table 17] JPEG0007871516000025.jpg95152

[0126] A new container (ClusterMergeInfo) is provided to merge two or more clusters whose bounding boxes are approaching each other and partially or completely overlapping, and which have coherent speed and direction of progress. These DEs and DFs within this container allow the CHs of these clusters to negotiate, agree, and merge the clusters into a new, larger cluster, further reducing VAM overhead. The provided container also keeps the members of these clusters informed of the ongoing merge process. An example is shown in Table 18. [Table 18]

[0127] The explanation also includes a new container (ClusterSplitInfo) that enables cluster splitting in two or more new clusters, selection of CHs in the split clusters, and keeps members informed of the ongoing splitting process in a timely manner. An example is shown in Table 19. [Table 19]

[0128] 3.1.3. Example Implementation of VAM Exemplary implementations of the VAM discussed herein, including related DFs and DEs, are shown in Table 20, represented in ASN.1 notation based on [SAE-J2735]. [Table 20] JPEG0007871516000029.jpg222152JPEG0007871516000030.jpg222152JPEG000 7871516000031.jpg222152JPEG0007871516000032.jpg222152JPEG00078715160 00033.jpg222152JPEG0007871516000034.jpg222152JPEG0007871516000035.j pg222152JPEG0007871516000036.jpg222152JPEG0007871516000037.jpg184152

[0129] 3.2. Enable VAM generation and transmission using non-VRU ITS-S. As mentioned above, a VAM is a message sent from a VRU ITS to create and maintain awareness of vulnerable road users participating in a VRU system. A VAM contains status and attribute information of the originating VRU ITS-S. The content may vary depending on the VRU ITS-S profile. Typical status information includes time, location, motion status, cluster status, etc. Typical attribute information includes data on the VRU profile, type, dimensions, etc. The generation, transmission, and reception of VAMs are managed by the VRU Basic Service (VBS) by implementing the VAM protocol. The VRU Basic Service is a facility layer entity that operates the VAM protocol. The VRU Basic Service provides three main services: handling VRU roles, and transmitting and receiving VAMs to enhance VRU safety. Current standards (see, e.g., [TS103300-3]) also employ the VRU clustering concept in the presence of high-density VRUs to reduce VAM communication overhead. In VRU clustering, nearby VRUs with coherent speed and direction of travel form a facility layer VRU cluster, and only the cluster head VRU sends VAMs. Other VRUs within the cluster skip sending VAMs. Active VRUs (not within a VRU cluster) send separate VAMs (called single VRU VAMs).

[0130] VAMs originating from VRU ITS do not effectively address the recognition of unequipped VRUs. In many cases, such as congested intersections, crosswalks, school pick-up / drop-off areas, public bus stops, school bus stops, congested intersections near shopping malls, and construction work areas, both equipped and unequipped VRUs exist. Forming clusters of individual VRUs may not be easy, and VRU clusters formed by VRUs cannot include unequipped VRUs in the cluster. Infrastructure (e.g., fixed RSU ITS-S (R-ITS-S)) can play a crucial role in detecting potential VRU clusters in such scenarios that include both equipped and unequipped VRUs. For example, static RSUs may be installed at congested intersections, crosswalks, school pick-up / drop-off areas, and congested intersections near shopping malls, while mobile R-ITS-S can be installed on designated vehicles (e.g., school buses, city buses, service vehicles) to function as infrastructure at public bus stops, school bus stops, and construction work areas.

[0131] This disclosure provides infrastructure-assisted VRU clustering, including both equipped and unequipped VRUs, in which the infrastructure (e.g., R-ITS-S) acts as the cluster head and transmits VAMs (referred to as “Infrastructure VAMs,” “iVAMs,” etc.). Existing VBSs are extended to allow non-VRU ITS-S (e.g., RSUs or designated vehicles) to transmit iVAMs.

[0132] Existing VAMs allow information sharing about either one VRU or one VRU cluster within each VAM. However, in the case of non-VRU ITS-S (e.g., RSU or Designated Vehicle ITS-S (V-ITS-S)) VAMs, the non-VRU ITS-S may discover one or more individual VRUs and / or one or more VRU clusters that need to be reported in the VAM. The existing VAM format will be modified to allow non-VRU ITS-S to report VRU-aware content for one or more VRUs and / or one or more VRU clusters in the same iVAM. Current standards (see, for example, [TS103300-3]) do not allow VAM segmentation.

[0133] Reporting all detected VRUs and / or VRU clusters by a non-VRU ITS can be highly inefficient in certain scenarios, such as the presence of a large number of VRUs or overlapping views of VRUs or occlusion of VRUs within the sensor's FOV in a source non-VRU ITS-S. For example, reporting in this manner via existing DF / DE within a VAM in the case of a large perceived VRU and / or VRU cluster generates enormous communication overhead, as the VAM message may need to be segmented into multiple segments, and it takes longer to report all VRUs and / or VRU clusters. One segment can be sent in each consecutive VAM generation event, requiring several VAM generation periods to send the VAM. Therefore, to support a large number of detected VRUs and / or VRU clusters or overlapping views of VRUs or occlusion of VRUs within the FOV, a dedicated grid-based bandwidth-efficient VRU awareness message should be supported. The value of each grid can indicate the presence of a VRU, the presence of a VRU cluster, the absence of a VRU and / or VRU cluster, etc. Furthermore, non-VRU ITS-S can better perceive the environment through a collective perception service (CPS) via the exchange of collective perception messages (CPMs) [4]. VRUs are not expected to listen to CPMs. However, non-VRU ITS-S can distribute perceived environmental information obtained from the CPS to VRUs via the VAM by adding DFs based on occupied grid / cost maps. Hierarchical cost maps or occupied grid-based DFs can be included in the VAM to replace or complement the VAM's existing DFs / DEs and save considerable communication overhead.

[0134] The existing VRU Basic Service (VBS) will be extended to allow non-VRU ITS-S to send VAMs. The existing VAM format will also be extended and / or modified to allow non-VRU ITS-S to report VRU awareness information for one or more VRUs and / or one or more VRU clusters in the same iVAM. These changes to the VAM format include new DFs and / or DEs, as well as modifications to existing DEs and / or DFs.

[0135] Non-VRU ITS-S can also generate and transmit occupied grid-based bandwidth-efficient VAMs. These VAMs may be applicable when a large number of VRUs and / or VRU clusters are detected, overlapping views of VRUs are detected, and / or occlusion of VRUs within FoV is detected. A new DF based on a hierarchical cost map or occupied grid is added to such VAMs to enable non-VRU ITS-S to distribute perceived environmental information acquired from the CPS to the VRUs in a bandwidth-efficient manner.

[0136] VRU safety is expected to be one of the major obstacles to the adoption of CA / AD vehicles on public roads. The non-VRU ITS-S VAM transmission and VAM format discussed herein ensures road safety while reducing computational and signaling overhead compared to existing solutions.

[0137] Various message transmissions by nodes can be traced and / or tracked using known mechanisms. Non-VRU ITS-S VAM transmissions and VAM formats can be adopted, specified, standardized, or incorporated into cellular standards such as ETSI and / or 3GPP, edge computing standards (e.g., ETSI MEC), and / or used with various radio access technologies (RATs).

[0138] 3.2.1. Generation and transmission of VAM using non-VRU ITS-S (e.g., R-ITS-S or V-ITS-S) As mentioned above, current standards / specifications do not effectively address the recognition of unequipped VRUs. In many cases, such as congested intersections, crosswalks, school pick-up / drop-off areas, public bus stops, school bus stops, congested intersections near shopping malls, and construction work areas, both equipped and unequipped VRUs exist. Forming clusters of individual VRUs may not be easy, and VRU clusters formed by VRUs cannot include unequipped VRUs in the cluster. Infrastructure (e.g., RSU ITS-S) can play a crucial role in detecting potential VRU clusters in such scenarios that include both equipped and unequipped VRUs. For example, static RSUs may be installed in congested intersections, crosswalks, school pick-up / drop-off areas, congested intersections near shopping malls, etc., while mobile RSUs may be installed on designated vehicles (e.g., school buses, city buses, service vehicles) to function as infrastructure / RSUs in public bus stops, school bus stops, construction work areas, etc. Similarly, vehicle sensors can detect and report VAMs for equipped VRUs as well as unequipped VRUs or VRU clusters. For the purposes of this disclosure, VAMs transmitted from non-VRU ITS-S (e.g., R-ITS-S or V-ITS-S) are referred to as "infrastructure VAMs," "iVAMs," etc.

[0139] Non-VRU ITS-S (e.g., RSUs or vehicles) continuously detect / perceive equipped and unequipped VRUs from local sensors. Non-VRU ITS-S can detect / perceive equipped and unequipped VRUs by cooperating with each other, such as by CPS[4] by sharing / receiving CPM messages. A non-VRU ITS-S may detect several VRUs at an intersection or on a sidewalk. In another case, roadside equipment (RSE) / RSU may be located in the same place as the smart traffic signal controller. Several VRUs waiting to cross the intersection may be requesting or instructing the traffic signal controller to cross the intersection. The RSU may obtain this information from the traffic signal controller and use this information to identify one or more VRU clusters. If several perceived VRUs (exceeding a threshold number) are very close to each other at coherent speed and direction of travel, as defined in [TS103300-3], the non-VRU ITS-S may decide to report them as a cluster. An RSU might find two or more such VRU clusters to report, for example, VRUs crossing an intersection or VRUs walking on a sidewalk. Some VRUs may need to be reported individually because they are far apart from others or their speeds may differ by more than a threshold for speed difference. When a non-VRU ITS-S decides to report one or more individual perceived VRUs and / or one or more perceived VRU clusters, it generates VAMs and reports them together in a single iVAM.

[0140] In some cases, a VRU cluster may have already been reported by a VRU-ITS-S, and a non-VRU ITS-S will perceive unequipped VRUs within and / or around the reported cluster boundary box. The non-VRU ITS-S may send a VAM containing both equipped and unequipped VRUs using the same or an expanded boundary box. A VRU-ITS-S acting as the cluster head may then stop sending VRU cluster VAMs.

[0141] 3.2.2. Enable non-VRU ITS-S to report VAM content for one or more VRUs and / or one or more VRU clusters in the same VAM. Current VAM capabilities will be extended to allow non-VRU ITS-S to submit VAMs. Existing VAM formats (see, e.g., [TS103300-3]) allow only VRU ITS-S (as individual VRUs or as VRU cluster heads) to submit VAMs. Part of a complementary solution will be formulated to allow non-VRU ITS-S to report VRU-aware content for one or more VRUs and / or one or more VRU clusters in the same VAM [5]. Current VAM capabilities will be extended to allow non-VRU ITS-S to report VRU-aware content for one or more VRUs and / or one or more VRU clusters in the same VAM.

[0142] The VruHighFrequencyContainer in the VamParameters DF is changed to an optional DF. For non-VRU originating VAMs, VamParameters has only one DE, "BasicContainer". The BasicContainer contains the originating station type, which can be used to identify non-VRU originating VAMs. In this case, VAM details are added to the VAM extension DF, as shown below for non-VRU ITS-S originating VAMs. This requires minimal changes to the existing VAM format. The VAM extension carries information such as the total number of individual VRUs reported, the total number of VRU clusters reported, and segmentation information if the VAM is segmented for non-VRU ITS-S originating VAMs. To carry other existing information from VamParameters for non-VRU originating VAMs (e.g., DF and / or DE), a new DF, VamParametersNonVruItsStation, is defined in the VAM extension. The VamParametersNonVruItsStation DF is included for each of the reported individual VRUs and VRU clusters. Since there is a high probability of segmentation of VAMs originating from non-VRU sources, segmentation information is needed. [Table 21] JPEG0007871516000039.jpg216152JPEG0007871516000040.jpg62152

[0143] In addition, or as an alternative, the BasicContainer is moved from DF vamParameters to DF VruAwareness. The BasicContainer provides information about the originating ITS-S (station type and location). The BasicContainer includes the originating station type, which can be used to identify VAMs originating from non-VRU sources. In this case, VAM details are added to the VAM extension DF, as shown below for VAMs originating from non-VRU ITS-S sources. This requires minimal changes to the existing VAM format. The VAM extension carries information such as the total number of individual VRUs reported, the total number of VRU clusters reported, and segmentation information if the VAM is segmented for VAMs originating from non-VRU ITS-S sources. To carry other existing information from VamParameters for VAMs originating from non-VRU sources (e.g., DF and / or DE), a new DF VamParametersNonVruItsStation is defined in the VAM extension. The VamParametersNonVruItsStation DF is included for each of the individual VRUs and VRU clusters being reported. Segmentation information can be added to VruAwareness DF or VAM extensions. The likelihood of segmenting non-VRU-originating VAMs is very high. [Table 22] JPEG0007871516000042.jpg216152JPEG0007871516000043.jpg57152

[0144] In addition, or as an alternative, the BasicContainer is moved from the DF vamParameters to the DF VruAwareness. The BasicContainer provides information about the originating ITS-S (station type and location). The BasicContainer includes the originating station type, which can be used to identify VAMs originating from non-VRU ITS-S. In addition, vamParameters is defined as a SEQUENCE OF VamParameters so that one VamParameters DF can be included for each reported individual VRU or VRU cluster in VAMs originating from non-VRU ITS-S. Segmentation information can be added to the VruAwareness DF or VAM extension. The likelihood of segmentation of VAMs originating from non-VRU is very high. In that case, an additional DF / DE is added to the VAM extension DF for VAMs originating from non-VRU ITS-S, as shown below. The VAM extension carries information such as the total number of reported individual VRUs, the total number of reported VRU clusters, and segmentation information if the VAM is segmented for VAMs originating from non-VRU ITS-S. [Table 23] JPEG0007871516000045.jpg176152

[0145] In addition, or as an alternative, a new DF, "VamParametersNonVruItsStation," is added to the existing VamParameters, changing VruHighFrequencyContainer from mandatory to optional. VamParametersNonVruItsStation is dedicated to VAMs originating from non-VRU ITS-S. The BasicContainer contains the origin station type, which can be used to identify VAMs originating from non-VRU. The VamParametersNonVruItsStation DF is added to each individual VRU or VRU cluster reported in VAMs originating from non-VRU ITS-S. For VAMs originating from non-VRU ITS-S, VamParameters has only two DFs: BasicContainer and VamParametersNonVruItsStation. The other DFs in VamParameters are carried in VamParametersNonVruItsStation for VAMs originating from non-VRU ITS-S. Segmentation information can be added to the VruAwareness DF or VAM extension. The likelihood of segmenting non-VRU-originating VAMs is very high, as described in [5]. In that case, an additional DF / DE is added to the VAM extension DF for non-VRU ITS-S-originating VAMs, as shown below. The VAM extension carries information such as the total number of individual VRUs reported and the total number of VRU clusters reported. [Table 24] JPEG0007871516000047.jpg222152JPEG0007871516000048.jpg30152

[0146] In addition, or as an alternative, VamParameters offers two options, namely, a VAM option originating from VRU ITS-S and another option for a VAM originating from non-VRU ITS-S, as shown below. [Table 25] JPEG0007871516000050.jpg222152JPEG0007871516000051.jpg94152

[0147] 3.2.3. Bandwidth-efficient non-VRU ITS-S originating VAM Reporting all detected VRUs and / or VRU clusters by a non-VRU ITS can be highly inefficient in certain scenarios, such as the presence of a large number of VRUs or overlapping views of VRUs or occlusion of VRUs within the sensor's FOV in the originating non-VRU ITS-S. For example, reporting in this manner via existing DF / DE within a VAM in the case of a large number of perceived VRUs and / or VRU clusters generates enormous communication overhead and takes longer to report all VRUs and / or VRU clusters, as the VAM message may need to be segmented into multiple segments. One segment can be sent in each consecutive VAM generation event, requiring several VAM generation periods to send the VAM. Therefore, for scenarios with a large number of detected VRUs and / or VRU clusters or overlapping views of VRUs or occlusion of VRUs within the FoV, a dedicated grid-based bandwidth-efficient VRU-aware messaging should be supported.

[0148] This specification describes a bandwidth-efficient VAM based on an occupied grid originating from a non-VRU ITS-S, with examples provided below. In particular, this occupied grid can be used in cases of a large number of detected VRUs and / or VRU clusters or occlusion of VRUs in overlapping views or FOVs of VRUs. For this purpose, a new DF, "VruOccupancyGridMap," is provided. For scenarios with a large number of detected VRUs and / or VRU clusters or occlusion of VRUs in overlapping views or FOVs of VRUs, only the VruOccupancyGridMap may be included in a VAM originating from a non-VRU ITS-S. The VruOccupancyGridMap can also be included as complementary information along with other DEs / DFs. [Table 26] JPEG0007871516000053.jpg209152JPEG0007871516000054.jpg216152JPEG0007871516 000055.jpg216152JPEG0007871516000056.jpg222152JPEG0007871516000057.jpg50152

[0149] 3.2.4. Bandwidth-efficient mechanism for distributing collective perceptual information to VRUs via non-VRU ITS-S originating VAM. Furthermore, non-VRU ITS-S can better perceive the environment through the Collective Perceived Service (CPS) via the exchange of Collective Perceived Messages (CPMs). VRUs are not expected to listen to CPMs. However, non-VRU ITS-S can distribute perceived environmental information obtained from the CPS to VRUs via the VAM by adding a DF based on the occupied grid / cost map. A hierarchical cost map or occupied grid-based DF will be included in the VAM. This can replace or complement the existing DF / DE in the VAM, potentially saving significant communication overhead. The description includes a mechanism that enables non-VRU ITS-S to distribute perceived environmental information obtained from the CPS to VRUs in a bandwidth-efficient manner via the VAM by adding a new DF LayeredCostMapVamContainer based on a hierarchical cost map or occupied grid / cost map. The DF LayeredCostMapVamContainer can be defined in a similar manner to that described above.

[0150] 3.2.5. VAM Extension Container The VRU extension container of type VamExtension should carry motion prediction containers for each of the VRUs and VRU clusters reported in VAMs originating from non-VRU ITS-S, including the VRU low frequency, VRU high frequency, cluster information container, cluster operation container, and non-VRU ITS-S originating VAMs. The extension also carries the totalIndividualVruReported container, totalVruClusterReported container, and VruRoadGridOccupancy container in VAMs originating from non-VRU ITS-S.

[0151] The Road Grid Occupancy DF is of type VruRoadGridOccupancy and should indicate whether a cell is occupied (by another VRU ITS station or object) or vacant. The indication should be represented by the VruGridOccupancyStatusIndication DE, and the corresponding confidence value of the indication should be given by the ConfidenceLevelPerCell DE. Additional DFs / DEs are included to carry the grid size and cell size, road segment reference ID, and grid reference point.

[0152] An example is shown in Table 21. [Table 27] JPEG0007871516000059.jpg114152

[0153] 4. Configuration and placement of ITS stations Figure 2 shows an exemplary ITS-S reference architecture 200. In ITS-based implementations, some or all of the components shown in Figure 2 may conform to the ITSC protocol, which is based on the principles of the OSI model for hierarchical communication protocols extended for ITS applications. The ITSC includes, in particular, an access layer corresponding to OSI layers 1 and 2, a networking and transport (N&T) layer corresponding to OSI layers 3 and 4, a facility layer corresponding to OSI layers 5 and 6, at least some of the functions of OSI layer 7, and an application layer corresponding to some or all of OSI layer 7. Each of these layers is interconnected via its respective interface, SAP, API, and / or other similar connector or interface.

[0154] Application Layer 201 provides ITS services, and ITS applications are defined within Application Layer 201. An ITS application is an application layer entity that implements the logic to satisfy one or more ITS use cases. An ITS application utilizes the underlying facilities and communication capacity provided by ITS-S. Each application can be assigned to one of three identified application classes: traffic safety, traffic efficiency, and other applications (see, for example, [EN302663], ETSI TR 102 638 V1.1.1 (2009-06) (hereinafter referred to as "[TR102638]")). Examples of ITS applications may include driver assistance applications (e.g., for collaborative recognition and road obstacle warning), including AEB applications, EMA applications, and FCW applications; speed management applications; mapping applications and / or navigation applications (e.g., turn-by-turn navigation and collaborative navigation); applications that provide location-based services; and applications that provide networking services (e.g., global internet services and ITS-S lifecycle management services). V-ITS-S110 may require an interface to provide ITS applications to vehicle drivers and / or occupants and to access in-vehicle data from the in-vehicle network or in-vehicle systems. For deployment and performance needs, a particular instance of V-ITS-S110 may include grouping of applications and / or facilities.

[0155] Facility Layer 202 comprises middleware, software connectors, software glues, etc., and includes multiple facility layer functions (or simply "facilities"). In particular, the facility layer includes functions from the OSI application layer, the OSI presentation layer (e.g., ASN.1 encoding and decoding, as well as encryption), and the OSI session layer (e.g., inter-host communication). Facilities are components that provide functions, information, and / or services to applications in the application layer and exchange data with lower layers to communicate their data with other ITS-S. Exemplary facilities include Cooperative Recognition Services, Collective Perception Services, Device Data Provider (DDP), Location and Time Management (POTI), Local Dynamic Map (LDM), Cooperative Recognition Basic Services (CABS) and / or Cooperative Recognition Basic Services (CABS), Signaling Phase and Timing Services (SPATS), Vulnerable Road Users Basic Services (VBS), Distributed Environment Notification (DEN) Basic Services, and Maneuvering Coordination Services (MCS). In the case of vehicle ITS-S, the DDP is connected to the in-vehicle network and provides vehicle status information. The POTI entity provides location and time information for the ITS-S. A list of common facilities is provided in ETSI TS 102 894-1 V1.1.1 (2013-08) (hereinafter, "[TS102894-1]").

[0156] Each of the aforementioned Interface / Service Access Point (SAP) may provide full-duplex data exchange with the facility layer and may implement appropriate APIs to enable communication between various entities / elements.

[0157] In the case of a vehicle ITS-S, the facility layer 202 is connected to the in-vehicle network via an in-vehicle data gateway, as illustrated and described in [TS102894-1]. The facilities and applications of the vehicle ITS-S receive the necessary in-vehicle data from the data gateway to construct messages (e.g., CSM, VAM, CAM, DENM, MCM, and / or CPM) and to use the applications. To transmit and receive CAMs, the CA-BS includes the following entities: CAM coding entity, CAM decoding entity, CAM transmission management entity, and CAM reception management entity. To transmit and receive DENMs, the DEN-BS includes the DENM coding entity, DENM decoding entity, DENM transmission management entity, DENM reception management entity, and DENM keep-alive transfer (KAF) entity. The CAM / DENM transmission management entity implements the protocol operations of the originating ITS-S, including activating and terminating CAM / DENM transmission operations, determining the frequency of CAM / DENM generation, and triggering CAM / DENM generation. The CAM / DENM Receive Management entity implements the protocol behavior of the receiving ITS-S, including triggering the CAM / DENM Decoding entity upon reception of CAM / DENM, provisioning received CAM / DENM data to the receiving ITS-S's LDM, facility, or application, discarding invalid CAM / DENM, and checking information about the received CAM / DENM. The DENM KAF entity KAF stores received DENMs during its validity period and forwards them when applicable. The usage conditions of the DENM KAF may be defined by ITS application requirements or by the cross-layer functionality of the ITSC Management entity 206. The CAM / DENM Encoding entity constructs (encodes) CAM / DENMs to include various things, and the object list may include a list of DEs and / or DFs contained in the ITS data dictionary.

[0158] The ITS station type / capability facility provides information describing the profile of the ITS-S to be used in the application and facility layers. This profile indicates the ITS-S type (e.g., vehicle ITS-S, roadside ITS-S, personal ITS-S, or central ITS-S), the role of the ITS-S, and its detection capabilities and context (e.g., the ITS-S's positioning capability, sensing capability, etc.). The station type / capability facility can store the sensor capabilities of various connected / coupled sensors and the sensor data obtained from such sensors. Figure 2 shows VRU-specific functions, including interfaces mapped to the ITS-S architecture. The VRU-specific functions are centered around the VRU Basic Services (VBS) 221 located in the facility layer, which consumes data from other facility layer services such as Location and Time Management (PoTi) 222, Local Dynamic Map (LDM) 223, HMI Support 224, DCC-FAC 225, and CA Basic Services (CBS) 226. The PoTi entity 222 provides location and time information for the ITS-S. The LDM 223 is a database within the ITS-S and can be updated with received CAM and CPM data (see, for example, ETSI TR 102 863 v1.1.1 (2011-06)) in addition to onboard sensor data. Message distribution-specific information related to the current channel utilization rate is received by interfaced with the DCC-FAC entity 225. The DCC-FAC 225 provides access network congestion information to the VBS 221.

[0159] The Location and Time Management Entity (PoTi) 222 manages location and time information for use by the ITS application layer, facility layer, network layer, management layer, and security layer. For this purpose, PoTi 222 acquires information from subsystem entities such as GNSS, sensors, and other subsystems of the ITS-S. PoTi 222 ensures ITS time synchronization between ITS-S within an ITS constellation, maintains data quality (e.g., by monitoring time deviations), and manages updates of location (e.g., motion and orientation) as well as time. An ITS constellation is a group of ITS-S that exchange ITS data among themselves. The PoTi entity 222 may include augmentation services to improve the accuracy, completeness, and reliability of location and time. Among these methods, communication technologies may be used to provide positioning assistance and infrastructure from mobile ITS-S to mobile ITS-S. Considering the ITS application requirements regarding location and time accuracy, PoTi 222 may use augmentation services to improve location and time accuracy. Various augmentation methods may be applied. PoTi222 can support these augmentation services by providing a message service that broadcasts augmentation data. For example, a roadside ITS-S may broadcast GNSS correction information to an oncoming vehicle ITS-S, and the ITS-S may exchange raw GPS data or ground radio position and time-related information. PoTi222 maintains and provides position and time reference information according to the service requirements of the application layer, facility layer and other layers in the ITS-S. In the context of ITS, "position" includes attitude and motion parameters, including velocity, direction of travel, horizontal speed, and optionally others. The motion and attitude states of a rigid body included in an ITS-S included position, velocity, acceleration, orientation, angular velocity, and possible other motion-related information. Position information at a particular moment is referred to as the motion and attitude state of a rigid body, including time. In addition to motion and attitude states, PoTi222 should also maintain information regarding the reliability of the variables of the motion and attitude states.

[0160] VBS221 is also linked to other entities such as Application Support Facilities, including, for example, the Collaborative / Cooperative Recognition Basic Services (CABS), Signaling Phase and Timing Services (SPATS), Distributed Environment Notification (DEN) services, Collective Perception Services (CPS), Maneuvering Coordination Services (MCS), and Infrastructure Services 212. VBS221 plays a role in sending VAMs, identifying whether a VRU is part of a cluster, and enabling assessment of potential collision risks. VBS221 may also interact with VRU profile management entities within the management layer for VRU-related purposes.

[0161] VBS221 interfaces with N&T via Network-Transport / Facility (NF)-Service Access Point (SAP) to exchange CPM with other ITS-S. VBS221 interfaces with security entities via Security Facility (SF)-SAP to access security services for VAM transmission and VAM reception 303. VBS221 interfaces with management entities via Management Facility (MF)-SAP when received VAM data is provided directly to the application, and interfaces with the application layer via Facility Application (FA)-SAP. Each of the aforementioned interfaces / SAPs may provide full-duplex data exchange with the facility layer and may implement appropriate APIs to enable communication between various entities / elements.

[0162] VBS module / entity 221 exists and / or operates at the facility layer, generates VAMs, checks related service / messages to coordinate the transmission of VAMs in conjunction with other ITS service messages generated by other facilities and / or other entities within the ITS-S, and the VAMs are then passed to the N&T and access layers for transmission to other nearby ITS-S. The VAMs are included in ITS packets, and the ITS packets are facility layer PDUs that can be passed to the access layer via the N&T layer or to the application layer for consumption by one or more ITS applications. Thus, the VAM format is designed to be independent of the underlying access layer and to allow VAMs to be shared regardless of the underlying access technology / RAT.

[0163] The application layer recommends possible distributions of functional entities that will be involved in protecting VRU116, based on an analysis of the VRU use case. The application layer also includes device role setting function / application (app) 211, infrastructure service function / app 212, steering coordination function / app 213, collaborative perception function / app 214, remote sensor data fusion function / app 215, collision risk analysis (CRA) function / app 216, collision risk avoidance function / app 217, and event detection function / app 218.

[0164] The device role setting module 211 receives configuration parameter settings and user preference settings, and enables / disables different VRU profiles depending on the parameter settings, user preference settings, and / or other data (e.g., sensor data). A VRU can be equipped with a portable device that needs to be configured initially and may evolve during its operation according to context changes that need to be specified. This is especially true for setting up VRU profiles and types, which can be achieved automatically at power-up or via the HMI. Changes in the vulnerability state of road users also need to be provided to activate VBS221 when a road user becomes vulnerable or to deactivate VBS221 when entering a protected area. Initial configuration can be set up automatically at power-up of the device. This may apply to VRU device types that can be VRU-Tx (a VRU that only has the ability to broadcast messages and complies with channel congestion control rules), VRU-Rx (a VRU that only has the ability to receive messages), and VRU-St (a VRU that has full-duplex (Tx and Rx) communication capabilities). During operation, the VRU profile may also change due to some clustering or decomposition. As a result, the role of the VRU device can evolve in accordance with changes in the VRU profile.

[0165] The Infrastructure Services Module 212 is responsible for initiating new VRU instantiations, collecting usage data, and / or consuming services from the Infrastructure Bureau. An existing Infrastructure Services Module 212, as described below, can be used in the context of VBS221.

[0166] SPAT (Signal Phase and Timing) & MAP (SPAT-related demarcation area) broadcasts are already standardized and used by vehicles at the intersection level. In principle, they protect VRU crossings. However, signal violation warnings may exist and can be detected and signaled using DENM. This signal violation indication using DENM is highly relevant to VRU devices as it indicates an increased risk of collision with a vehicle that is violating the signal. If a signal violation indication is detected and analyzed using local captors or VAM, the traffic signal controller may delay the change from red to green, allowing the VRU to safely complete its road crossing.

[0167] Contextual speed limits using IVI (In-Vehicle Information) can be adapted when a large cluster of VRU116s is detected (for example, limiting the vehicle's speed to 30 km / h). At such low speeds, the vehicle can operate efficiently when it perceives the VRU116s using its own local perception system.

[0168] Some implementations also include remote sensor data fusion and actuator applications / functions 215 (including ML / AI). Local perception data obtained by computation of data collected by local sensors can be augmented by remote data collected by elements of the VRU system (e.g., VRU system 117, V-ITS-S110, R-ITS-S130) via ITS-S. This remote data is transferred using standard services such as CPS. In such cases, it may be necessary to fuse this data. In some implementations, data fusion can provide at least three possible outcomes: (i) after a data integrity check, the received remote data is not coherent with the local data, and the system element must decide which data source to trust and ignore the other data source; (ii) only one input (e.g., remote data) is available, meaning that the other source is unlikely to provide information, and the system element can trust only the available source; and (iii) after a data integrity check, the two sources provide coherent data that augments the individual inputs provided. The use of ML / AI may be necessary to recognize and classify not only the detected objects (e.g., VRUs, motorcycles, vehicle types, etc.) but also the dynamics associated with them. AI can be placed on any element of a VRU system. The same technique can be applied to actuators, but in this case, the actuators are the target of data fusion.

[0169] Collective perception (CP) involves ITS-S sharing information about the current environment with each other. ITS-S participating in the CP broadcast information about their current (e.g., driving) environment, rather than information about themselves. To this end, the CP involves different ITS-S actively exchanging locally perceived objects (e.g., other road participants, VRU116, obstacles, etc.) detected by local perception sensors via one or more V2X RATs. In some implementations, the CP includes a perception chain that may be a fusion of the results of several perception functions at a predefined time. These perception functions may include local and remote perception functions.

[0170] Local perception is provided by the collection of information from the environment of the ITS elements under consideration (e.g., VRU devices, vehicles, infrastructure, etc.). This information collection is achieved using relevant sensors (optical cameras, thermal cameras, radar, LiDAR, etc.). Remote perception is provided by the provision of perceptual data via C-ITS (primarily V2X communication). Remote perception can be communicated using existing basic services such as collaborative perception (CA) or more recent services such as collective perception services (CPS).

[0171] In this case, several perceptual sources may be used to achieve the collaborative perception function 214. The consistency of these sources may be verified at a predefined moment, and if inconsistent, the CP function may select the best one according to the confidence level associated with each perceptual variable. The CP result should conform to the required level of precision specified by PoTi. The associated confidence level may be necessary to construct the CP obtained from the fusion when there is a difference between local and remote perception. This confidence level may also be necessary for the use of the CP result in other functions (e.g., risk analysis).

[0172] The perceptual function from local sensor processing of the device to the final result at the collaborative perception 214 level can present a considerable latency time of several hundred milliseconds. Characterizing the VRU trajectory and its velocity progression requires a certain number of vehicle position and velocity measurements, thus increasing the overall latency time of perception. Consequently, it becomes necessary to estimate the overall latency time of this function in order to take it into consideration when selecting a collision avoidance strategy.

[0173] The CRA function 216 analyzes the predicted kinematics of a considered moving object, associated with its respective confidence level. The objective is to estimate the likelihood of a collision and then, in the case of the resulting likelihood, to determine the time to collision (TTC) as accurately as possible. Other variables may be used to calculate this estimate.

[0174] The VRU's CRA function 216 and dynamic state prediction can reliably predict the behavior of relevant road users with an acceptable level of confidence, for the purpose of triggering appropriate collision avoidance measures, assuming that the input data is of sufficient quality. The CRA function 216 analyzes the level of collision risk based on a reliable prediction of the progression of each dynamic state. As a result, the manner of confidence can be characterized as the confidence level of the selected collision risk metric, as discussed in sections 6.5.10.5 and 6.5.10.9 of [TS103300-2]. The confidence of the VRU's dynamic state prediction is calculated for the purpose of risk analysis. Predicting the dynamic state of a VRU is complex, especially for some specific VRU profiles (e.g., animals, children, disabled persons, etc.). Therefore, a confidence level may be associated with this prediction, as described in sections 6.5.10.5, 6.5.10.6, and 6.5.10.9 of [TS103300-2]. A reliable prediction of VRU motion is used to trigger the broadcast of the relevant VAM when a collision risk involving a VRU is detected with sufficient confidence to avoid false positive alarms (see, for example, sections 6.5.10.5, 6.5.10.6, and 6.5.10.9 of [TS103300-2]).

[0175] The calculation of TTC uses the following two conditions: First, two or more moving objects under consideration follow trajectories that intersect at some point that can be called a “potential conflict point.” Second, if the moving objects maintain their kinematics (e.g., approach, trajectory, speed, etc.), it is possible to predict that they will collide at a given time, which can be estimated by calculating the time required (called the Time to Collision (TTC)) for them to simultaneously reach the level of the identified potential conflict point. The TTC is a calculated data element that allows for the selection of the nature and urgency of collision avoidance measures to be taken.

[0176] TTC prediction can only be reliably established when VRU116 enters the collision risk area. This is due to uncertainty in the kinetics (primarily its trajectory) of the VRU pedestrian before it decides to cross the road.

[0177] At potential conflict point levels, another measure, the "Time Difference Between Pedestrian and Vehicle to the Potential Conflict Point" (TDTC), can be used to estimate the collision risk level. For example, if it does not affect the pedestrian's and / or the vehicle's kinetics, the TDTC is equal to 0 and a collision is certain. Increasing the TDTC reduces the risk of collision between the VRU and the vehicle. Potential conflict points are located in the center of a collision risk area, which can be defined according to the lane width (e.g., 3.5m) and vehicle width (up to 2m for passenger cars).

[0178] TTC is one of the variables that can be used to define collision avoidance strategies and the operational collision avoidance measures to be taken. Other variables can also be considered, such as road conditions, weather conditions, the triple of {Longitudinal Distance (LoD), Lateral Distance (LaD), Vertical Distance (VD)}, and the corresponding triple of {MSLaD, MSLoD, MSVD} thresholds, the Trajectory Interruption Indicator (TII), and the ability of a moving object to avoid a collision in response to the collision risk (see, for example, item 6.5.10.9 of [TS103300-2]). The TII is an indicator of the likelihood that the VRU116 will collide with one or more other VRU116s, non-VRUs, or even objects on the road.

[0179] The CRA function 216 compares the LaD, LoD, and VD with their respective predefined thresholds MSLaD, MSLoD, and MSVD, and if all three measurement criteria are simultaneously less than their respective thresholds, i.e., when LaD < MSLaD, LoD < MSLoD, and VD < MSVD, the collision avoidance measures are initiated. These thresholds can be set and updated dynamically periodically or according to the speed, acceleration, type, and payload of the vehicle and VRU116, as well as environmental and weather conditions. On the other hand, the TII reflects how likely it is that the own VRU ITS-S117 trajectory will be blocked by neighboring ITSs (non-VRU ITSs such as other VRU116s and / or vehicles 110).

[0180] The likelihood of a collision associated with TTC can also be used as a trigger condition for message broadcast (for example, infrastructure elements that obtain a complete perception of the situation can broadcast DENM, IVI (context speed limit), CPM, or MCM).

[0181] The collision risk avoidance function / application 217 includes a collision avoidance strategy to be selected according to the TTC value. In the case of the autonomous vehicle 110, the collision risk avoidance function 217 may involve the identification of the steering coordination 213 / vehicle motion control 608 to achieve collision avoidance according to the possibility of VRU trajectory obstruction by other road users detected by the TII and steering identifier (MI), as described later.

[0182] The collision avoidance strategy may take into account several environmental conditions, such as visibility conditions related to local weather, vehicle stability conditions related to road conditions (e.g., slippery), and vehicle braking ability. The vehicle collision avoidance strategy then needs to take into account the vehicle profile, the remaining TTC, road and weather conditions, and the VRU's operational capabilities according to the vehicle's autonomous operating capabilities. Collision avoidance measures may be implemented using steering coordination 213 (and associated steering coordination message (MCM) exchange), as is done in the French PAC V2X project or other similar systems.

[0183] For example, under favorable conditions, collision avoidance measures can be triggered when the TTC is greater than 2 seconds (1 second for driver reaction time and 1 second to achieve collision avoidance measures). If it is less than 2 seconds, the vehicle can be considered to be in a “pre-crash” situation, and therefore mitigation measures should be triggered to reduce the severity of the collision impact under VRU116 / 117. Possible collision avoidance and impact mitigation measures are listed in requirement FSYS08 of section 5 of [TS103300-2].

[0184] Road infrastructure elements (e.g., R-ITS-S130) may also include CRA functions 216 and collision risk avoidance functions 217. These functions may indicate collision avoidance measures for nearby VRUs 116 / 117 and vehicles 110.

[0185] Collision avoidance measures for VRU, V-ITS-S110, and / or R-ITS-S130 (e.g., using MCM as is done in the French PAC V2X project) may depend on the level of vehicle automation. Collision avoidance or impact mitigation measures may be triggered as a warning / alert to the driver or as a direct action on the vehicle 110 itself. Examples of collision avoidance include any combination of extending or changing the phase of traffic signals, acting on the trajectory and / or speed of the vehicle 110 (e.g., deceleration, lane change, etc.) if the vehicle 110 has a sufficient level of automation, issuing alerts to ITS device users via HMI, and distributing C-ITS messages to other road users, including VRU116 / 117, where applicable. Examples of impact mitigation measures may include any combination of triggering protective measures at the vehicle level (e.g., deployment of external airbags) and triggering portable VRU protective airbags.

[0186] Road infrastructure may provide services to support road crossings by VRUs, such as traffic signals. When a VRU begins crossing the road at a traffic signal level that permits the VRU, the traffic signal should not change phase until the VRU has completed its crossing. Therefore, the VAM should include data elements that allow the traffic signal to determine the completion of a road crossing by VRUs 116 / 117.

[0187] The steering coordination function 213 executes collision avoidance measures associated with the determined (and selected) collision avoidance strategy. The collision avoidance measures are triggered at the VRU 116 / 117, vehicle 110, or both levels, depending on the VRU's operational capabilities (e.g., VRU profile and type), the vehicle type and capabilities, and the actual risk of collision. VRU116 / 117 may not always have the ability to act to avoid a collision, especially when the TTC is short (a few seconds) (e.g., animals, children, the elderly, disabled persons, etc.) (see, for example, sections 6.5.10.5 and 6.5.10.6 of [TS103300-2]). This function should be present at the vehicle 110 level and may be present at the VRU device 117 level according to the VRU profile, depending on the automation level of the vehicle 110 (e.g., not present in non-automated vehicles). At the vehicle 110 level, this function interfaces with vehicle electronics that control the dynamic state of the vehicle with respect to direction of travel and speed. At the VRU device 117 level, this function may interface with HMI support functions according to the VRU profile so that warnings or alarms can be issued to VRU116 / 117 according to the TTC.

[0188] The steering coordination 213 can be proposed from infrastructure elements to the vehicle, and the infrastructure elements can obtain a better perception of the kinematics of the moving objects involved by their own sensors or by fusing their data with remote perception obtained from standard messages such as CAM.

[0189] Maneuver coordination 213 in VRU116 may be enabled between the VRU and neighboring ITS by firstly sharing a TII that reflects how likely it is that the trajectory of the VRU ITS-S117 will be interrupted by a neighboring ITS (another VRU or a non-VRU ITS such as a vehicle), and secondly, by sharing a Maneuver Identifier (MI) that indicates the type of VRU maneuver required. The MI is an identifier for the maneuver that should be used in Maneuver Coordination Service (MCS) 213. The choice of maneuver may be generated locally based on sensor data available in the VRU ITS-S117 and may be shared with neighboring ITS-S (e.g., other VRU116s and / or non-VRUs) in the vicinity of the VRU ITS-S117 to initiate joint maneuver coordination between VRU116s (see, for example, section 6.5.10.9 of [TS103300-3]).

[0190] Depending on the scene analysis regarding sensory and shared inputs, a simple TII range can be defined to indicate the possibility that the self-VRU's 116 paths may be blocked by another entity. Such indications can help trigger timely maneuvers. For example, the TII can also be defined as a TII index that can simply indicate the likelihood (low, moderate, high, or very high) of the CRA216's potential path blocking. If there are multiple other entities, the TII may indicate a specific entity distinguishable by a simple ID that depends on the simultaneous number of entities in the neighborhood at that time. The neighborhood may also be just one cluster in which the current VRU is located. For example, the minimum number of entities or users in a cluster is 50 per cluster (worst case). However, the set of users that may collide with the VRU may be much smaller than 50, which can be indicated by a few bits in the VAM, for example.

[0191] On the other hand, the MI parameters can contribute to collision risk avoidance 217 by triggering / suggesting the type of maneuver required at the VRU 116 / 117. The number of such possible maneuvers can be very small. For simplicity, they can also be defined as {vertical trajectory change maneuver, lateral trajectory change maneuver, direction of travel change maneuver or emergency braking / deceleration} as the possible measures to be selected from among them to avoid the potential collisions indicated by the TII. The TII and the MI parameters can also be exchanged by including them as part of the VAM DF structure.

[0192] The event detection function 218 assists the VBS 221 during its operation when transitioning from one state to another. Examples of events to be considered include changes in the VRU role when the road user becomes vulnerable (activation) or when the road user has died while being vulnerable (deactivation), when the VRU enters a cluster with other VRUs or new mechanical elements (e.g., bicycles, scooters, motorcycles, etc.), or changes in the VRU profile when the VRU cluster is in a breakdown scenario, the risk of a collision between one or more VRUs and at least one other VRU or vehicle (using a VRU vehicle) (such events are detected by the perception capabilities of the VRU system), changes in the VRU dynamics (trajectory or speed) that affect the TTC and the confidence of the previous prediction, and changes in the situation of road infrastructure equipment (traffic signal phase) that affect the VRU movement.

[0193] In addition, or as an alternative, existing infrastructure services 212, such as those described herein, can also be used in the context of VBS221. For example, broadcasts of Signal Phase and Timing (SPAT) and SPAT-related Demarcated Areas (MAP) have already been standardized and are used by vehicles at the intersection level. In principle, they protect VRU116 / 117 from crossing. However, signal violation warnings may exist and can be detected and signaled using DENM. This signal violation indication using DENM is highly relevant to VRU device 117 as it indicates an increased risk of collision with a vehicle that has violated a signal. If the signal violation indication uses local capta or detects and analyzes VAM, the traffic signal controller may delay the change from red to blue, allowing VRU116 / 117 to safely complete the road crossing. Contextual speed limits using In-Vehicle Information (IVI) can be adapted when a large cluster of VRU116 / 117 is detected (e.g., limiting vehicle speed to 30 km / h). At such low speeds, the vehicle 110 can operate efficiently when perceiving the VRU by the vehicle's own local perception system.

[0194] The ITS Management (mgmnt) layer includes the VRU Profile mgmnt entity. The VRU Profile Management function is a crucial support element for VBS221, as it manages VRU profiles during VRU active sessions. Profile management is part of ITS-S Configuration Management, in which case it is initialized with typical parameter values ​​necessary to fulfill its function. ITS-S Configuration Management is also responsible for updates required throughout the system lifecycle (e.g., new standard versions).

[0195] When VBS221 is activated (vulnerability configured), VRU profile management needs to characterize the VRU personal profile based on the VRU's experience and the provided initial configuration (common VRU type). VRU profile management can then continue to learn about the VRU's habits and behaviors for the purpose of increasing the confidence level (reliability) associated with its kinematics (trajectory and speed) and its progress prediction.

[0196] VRU profile management 261 can adapt the VRU profile according to the detected events signaled by VBS management and VRU cluster management 302 (cluster construction / formation or cluster decomposition / dissolution).

[0197] The VRU may or may not be affected by some road infrastructure event (e.g., the progress of a traffic signal phase) according to its profile, thus enabling a better estimate of the confidence level to be associated with its movement. For example, an adult pedestrian is likely to wait at a green traffic signal and then cross the road when the traffic signal turns red. Animals do not care about the color of the traffic signal, and children may or may not be able to wait depending on their age and educational level.

[0198] Figure 3 shows an exemplary VBS functional model 300. VBS221 is a facility layer entity that operates the VAM protocol. VBS221 provides three main services: processing the VRU role, transmitting and receiving VAM. The VBS uses the services provided by the ITS networking & transport layer protocol entity to distribute the VAM. In some implementations, the presence or absence of the dotted / dashed blocks depends on whether the VRU device type is VRU-Tx, VRU-Rx, or VRU-St (see, for example, [TS103300-2]).

[0199] Among other things, those within the scope of the present disclosure can be briefly summarized as follows. 1. VBS (Service) Management 301: Responsible for activating or deactivating VAM transmissions according to device role parameters, and managing the trigger conditions for VAM transmissions. 2. VRU Cluster Management 302: For managing the creation and dismantling of combined and clustered VRUs. 3. VAM Reception Management 303 After decoding the VAM message, check the relevance, consistency, validity, and completeness of the Rx message, and store or delete the Rx message data elements in the Local Dynamic Map (LDM). 4. VAM transmission management 304 Assembles the VAM DE and sends it to the encoding function. 5. VAM Encoding 305 Encodes the VAM DE coming from the VAM Tx management function and triggers VAM transmission to the network and transport layers (this function is only present if VRU-ITS-S VRU-Rx is available). 6. VRU Decoding 306: Extracts the relevant DEs from the received VAM (this function exists only if VRU-ITS-S VRU-Rx is available) and sends them to the receive management function.

[0200] VRU Role Processing: VBS221 receives unilateral instructions from the VRU profile management entity regarding whether the device user is in a context in which they are considered a VRU (e.g., a pedestrian crossing a road) or (e.g., a bus passenger) (see, for example, Section 6.4 of [TS103300-2]). VBS221 remains operational in both states, as defined by Table 21. [Table 28]

[0201] For example, there may be cases where the VRU profile management entity provides invalid information, such as a VRU device user being considered a VRU, but its role being VRU_ROLE_OFF. This is implementation-dependent, as the receiving ITS-S has very robust validation checks and needs to take the VRU context into account during risk analysis. The accuracy of the positioning system (on both the transmitting and receiving sides) should also strongly influence the detection of such cases.

[0202] Transmitting a VAM involves two activities: VAM generation and VAM transmission. In VAM generation, the source ITS-S117 creates the VAM, which is then sent to the ITS's networking and transport layers for distribution. In VAM transmission, the VAM is transmitted over one or more communication media using one or more transport and networking protocols. A natural model is that the VAM is transmitted directly by the source ITS-S to all ITS-S within communication range. VAMs are generated at a frequency determined by the control VBS221 within the source ITS-S. If a VRU ITS-S is not in a cluster, or is the cluster leader, the VRU ITS-S transmits VAMs periodically. A VRU ITS-S117 that is in a cluster but is not the cluster leader does not transmit VAMs. The generation frequency is determined based on changes in motion, the location of the VRU ITS-S117, and radio channel congestion. Security measures, such as authentication, are applied to the VAM during the transmission process in coordination with security entities.

[0203] Upon receiving a VAM, VBS221 makes the VAM's contents available to ITS applications and / or other facilities within the receiving ITS-S117 / 130 / 110, such as Local Dynamic Maps (LDMs). VBS221 works in conjunction with security entities to apply all necessary security measures, such as relevance or message integrity checks.

[0204] The VBS221 includes a VBS management function 301, a VRU cluster management function 302, a VAM receive management function 303, a VAM transmit management function 304, a VAM encoding function 305, and a VAM decoding function 306. The presence of some or all of these functions depends on the VRU device type (e.g., VRU-Tx, VRU-Rx, or VRU-St) and may vary depending on the use case and / or design choices.

[0205] The VBS management function 301 performs the following operations: remembering the assigned ITS AID and the network port assigned for use with VBS221; remembering the VRU configuration, which is received during initial setup or updated later for encoding VAM data elements; receiving and sending information from the HMI; activating / deactivating the VAM transmission service 304 according to device role parameters (for example, the service is deactivated when a pedestrian boards the bus); and managing the trigger conditions for VAM transmission 304 in relation to network congestion control. For example, after the activation of a new cluster, it may be decided to stop the transmission of elements of the cluster.

[0206] The VRU cluster management function 302 performs the following operations: detecting whether the associated VRU can be the leader of the cluster; calculating and storing cluster parameters at activation to encode cluster-specific VAM data elements; managing the state machine associated with the VRU according to detected cluster events (see, for example, the example state machine provided in section 6.2.4 of [TS103300-2]); and activating or deactivating the broadcast of VAM or other standard messages (e.g., DENM) according to the state and type of the associated VRU.

[0207] Clustering as part of VBS221 is intended to optimize resource usage in ITS systems. These resources are primarily spectral resources and processing resources.

[0208] A large number of VRUs (Special Events such as crosswalks, large plazas, and large pedestrian gatherings in urban environments) in a specific area will result in a considerable number of individual messages being sent by the VRU ITS-S, thus leading to the need for large spectral resources. In addition, all of these messages need to be processed by the receiving ITS-S, potentially involving overhead for security operations.

[0209] To reduce this resource usage, this specification specifies clustering functionality. A VRU cluster is a group of VRUs having similar behavior (see, for example, [TS103300-2]), and the VAM associated with a VRU cluster provides information about the entire cluster. Within a VRU cluster, VRU devices can act as either leaders (one per cluster) or members. Leader devices send VAMs containing cluster information and / or cluster behavior. Member devices send VAMs containing cluster behavior containers to join / leave a VRU cluster. Member devices never send VAMs containing cluster information containers.

[0210] A cluster can contain VRU devices with multiple profiles. If a cluster contains devices with only one profile, it is called "homogeneous." If a cluster contains VRU devices with two or more profiles (e.g., a mixed group of pedestrians and cyclists), it is called "heterogeneous." The VAM ClusterInformationContainer includes fields that allow the cluster container to indicate which VRU profiles are present in the cluster. Indicating heterogeneous clusters is important because it provides useful information for predicting the trajectory and behavior of the cluster when it is broken down.

[0211] Support for the clustering function is optional in VBS 221 for all VRU profiles. The decision on whether to support clustering depends on the implementation for all VRU profiles. If the conditions are met (see clause 5.4.2.4 of [TS103300-3]), support for clustering is recommended for VRU profile 1. Implementations that support clustering may also allow the device owner to activate or deactivate clustering by configuration. This configuration also depends on the implementation. If the clustering function is supported and activated within the VRU device, and only in this case, the VRU ITS-S shall comply with the requirements specified in clauses 5.4.2 and 7 of [TS103300-3] and shall define the parameters specified in clause 5.4.3 of [TS103300-3]. As a result, in this specification, the cluster parameters are grouped into two specific conditional mandatory containers.

[0212] The basic operations to be performed as part of VRU cluster management 302 in VBS 221 are cluster identification, i.e., identification within the cluster by cluster participants in ad hoc mode, and cluster creation, i.e., creation of a cluster of VRUs including VRU devices that are located close and have similar intended directions and speeds. Details of the cluster creation operation are described in clause 5.4.2.2 of [TS103300-3], and cluster decomposition, i.e., dissolution of the cluster when the cluster is no longer involved in safety-related traffic or when the density drops below a given threshold, cluster participation and cluster departure, i.e., operation within the cluster, addition or removal of individual members to / from an existing cluster, and cluster expansion or cluster shrinkage, i.e., operations to increase or decrease the size (area or density).

[0213] Any VRU device shall lead at most one cluster. Therefore, a cluster leader shall dismantle its cluster before beginning to join another cluster. This requirement also applies to composite VRUs, as defined in [TS103300-2], which join different clusters (e.g., while crossing a pedestrian crossing). A composite VRU may, in that case, be recreated after leaving heterogeneous clusters as needed. For example, if a person riding a bicycle with a VRU device detects that they are currently in a composite cluster with their own bicycle, which also has a VRU device, and that they may join a larger cluster, the leader of the composite VRU shall dismantle the cluster, and both devices shall each join that larger cluster separately. The possibility of including or merging VRU clusters or composite VRUs within a VRU cluster is left to further research. In some implementations, simple in-band VAM signaling may be used for the operation of VRU clustering. Further methods may be defined for establishing, maintaining, and dismantling associations between devices (e.g., Bluetooth®, UWB, etc.).

[0214] Interactions between the VRU base service and other facility layer entities in the ITS-S architecture are used to obtain information for generating the VAM. The interfaces for these interactions are described in Table 22. IF.OFa (interfaces with other facilities) are implementation-dependent. [Table 29]

[0215] In VRU cluster operation, depending on the context, VBS221 is in one of the cluster states specified in Table 23. In addition to the normal VAM trigger conditions defined in Section 6 of [TS103300-3], the aforementioned events can trigger VBS state transitions related to cluster operation. The parameters that control these events are summarized in Section 8, Tables 14 and 15 of [TS103300-3] and / or Tables 5 and 6 above. [Table 30]

[0216] In all VBS states, the VRU basic services within the VRU device are assumed to remain operational.

[0217] The VAM reception management function 303, after decoding the VAM message, performs the following operations: checking the relevance of the received message according to its current mobility characteristics and state; checking the semantic consistency, validity, and completeness of the received message (liaison reference with the security protocol); and discarding or storing the data elements of the received message in the LDM according to the results of the previous operation.

[0218] The VAM transmission management function 304 is available only at the VRU device level, and not at the level of other ITS elements such as V-ITS-S110 or R-ITS-S130. This function may not even exist at the VRU device level, depending on its initial configuration (see device role setting function 211). The VAM transmission management function 304 performs the operations of assembling message data elements according to the message standard specification and sending the constructed VAM to the VAM encoding function 305, in response to a request from the VBS management function 301. The VAM encoding function 305 encodes the data elements provided by the VAM transmission management function 304 according to the VAM specification. The VAM encoding function 305 is available only when the VAM transmission management function 304 is available.

[0219] The VAM decoding function 306 extracts relevant data elements contained in the received message. These data elements are then sent to the VAM reception management function 303. The VAM decoding function 306 is only available when the VAM reception management function 303 is available.

[0220] A VRU can consist of VRU profiles. VRU profiles form the basis for further defining the VRU functional architecture. Profiles are derived from the various use cases discussed herein. A VRU typically refers to an organism. An organism is considered a VRU only when it is in the context of a safety-related traffic environment. For example, an organism inside a house is not a VRU until it is near a street (e.g., 2m or 3m), and at the point of being near a street, the organism is part of a safety-related context. This makes it possible to limit the amount of communication, for example, a C-ITS communication device only needs to start operating as a VRU-ITS-S when the organism associated with that device begins acting in the role of a VRU.

[0221] A VRU can be equipped with a portable device. The term "VRU" may be used to refer to both the VRU and its VRU device unless otherwise intended in context. A VRU device may be initially configured and may evolve during its operation in accordance with contextual changes that need to be specified. This is especially true for the setup of VRU profiles and VRU types, which can be achieved automatically at power-up or via the HMI. Changes in the vulnerability state of road users also need to be provided to activate the VBS when a road user becomes vulnerable or to deactivate the VBS when entering a protected area. Initial configuration can be set up automatically at power-up of the device. This may apply to VRU device types, which may be VRU-Tx, which has only the ability to broadcast messages and complies with channel congestion control rules; VRU-Rx, which has only the ability to receive messages; and / or VRU-St, which has full-duplex communication capabilities. During operation, the VRU profile may also change due to some clustering or decomposition. As a result, the role of the VRU device may evolve in accordance with changes in the VRU profile.

[0222] The following profile classification parameters can be used to classify different VRU116s. Maximum and average (e.g., typical) speed values ​​(which may have, for example, their standard deviation). Minimum and average (e.g., typical) communication ranges can be calculated based on the assumption that a 5-second recognition time is required to warn / act on traffic participants. Environment or area type (e.g., city, suburb, rural, main road, etc.). Average weight and standard deviation. Directional / trajectory ambiguity (gives a confidence level of predictability of the VRU's behavior in VRU motion). Cluster size: The number of VRUs (Variable Units) in the cluster. A VRU may lead the cluster, in which case it may indicate its size. In such cases, the leading VRU can be positioned to serve as the reference point for the cluster.

[0223] These profile parameters are not dynamic parameters maintained in an internal table, but rather indicators of typical values ​​that should be used to classify VRU116 and evaluate the behavior of VRU116 belonging to a particular profile. An example VRU profile may be as follows: VRU Profile 1 - Pedestrians. VRU116 in this profile may include any road users not using mechanical devices, such as pedestrians on sidewalks, children, people with strollers, people with disabilities, blind people guided by dogs, elderly people, and cyclists who have dismounted. VRU Profile 2 - Person on a Bicycle. VRU 116 in this profile may include persons on bicycles and, in some cases, riders of similar light vehicles equipped with electric engines. This VRU profile includes persons on bicycles, as well as unicyclists, wheelchair users, horses carrying riders, skaters, electric scooters, Segways, etc. Note that light vehicles themselves do not represent a VRU; they only form a VRU when combined with a person. VRU Profile 3 - Motorcycle Drivers. VRU 116 in this profile may include drivers of motorcycles equipped with an engine that enables them to travel on roads. This profile includes users of powered two-wheeled vehicles (PTWs) such as mopeds (motorized scooters), motorcycles, or sidecars (e.g., drivers and passengers, e.g., children and animals), and may also include all-terrain vehicles (ATVs), snowmobiles (or snow machines), jet skis for marine environments, and / or other similar powered vehicles. VRU Profile 4 - Animals that pose a safety risk to other road users. VRU116 in this profile may include dogs, wild animals, horses, cattle, sheep, etc. Some of these VRU116 may have their own ITS-S (e.g., urban dogs and horses) or some other type of device (e.g., GPS module in dog collar, embedded RFID tag, etc.), but the majority of VRU116 in this profile are detected only indirectly (e.g., wild animals in rural areas or on main roads). Clusters of animal VRU116 may be clusters of animals such as clusters of sheep, cattle, or wild boars. This profile has a lower priority when decisions must be made to protect VRUs.

[0224] As specified in ETSI TS103 300-3 V0.1.11(2020-05) ("[TS103300-3]"), point-to-multipoint communication, such as that discussed in ETSI EN 302 636-4-1 v1.3.1(2017-08) (hereinafter "[EN302634-4-1]") and ETSI EN 302 636-3 v1.1.2(2014-03) ("[EN302636-3]"), may be used to transmit VAM.

[0225] The frequency / periodicity range of VAMs. A VAM generation event results in the generation of one VAM. The minimum elapsed time between the start of consecutive VAM generation events is greater than or equal to T_GenVam. T_GenVam is limited to T_GenVamMin ≤ T_GenVam ≤ T_GenVamMax, where T_GenVamMin and T_GenVamMax are specified in Table 11 (Section 8). When cluster VAMs are sent, T_GenVam can be smaller than that of individual VAMs.

[0226] For ITS-G5, T_GenVam is managed according to the channel usage requirements for Distributed Congestion Control (DCC) as specified in ETSI TS103 175. The parameter T_GenVam is provided by the VBS management entity in milliseconds. If the management entity provides a value for this parameter greater than T_GenVamMax, T_GenVam is set to T_GenVamMax; if the value is less than T_GenVamMin, or if this parameter is not provided, T_GenVam is set to T_GenVamMin. The parameter T_GenVam represents the currently valid lower limit of the elapsed time between consecutive VAM generation events.

[0227] In the case of C-V2X PC5, T_GenVam is managed according to the congestion control mechanism defined by the access layer in ETSI TS 103 574.

[0228] Trigger conditions. Individual VAM transmission management by VBS in VRU ITS-S. If any of the following conditions are met and the individual VAM transmission is not subject to redundancy mitigation techniques, the first individual VAM is generated for transmission immediately or at the earliest time. 6. VRU116 is in VRU-IDLE VBS state and is in VRU-ACTIVE-STANDALONE state. 7. VRU116 / 117 is in the VRU-PASSIVE VBS state and has decided to leave the cluster and enter the VRU-ACTIVE-STANDALONE VBS state. 8. VRU116 / 117 is in the VRU-PASSIVE VBS state, and the VRU has determined that one or more new vehicles or other VRU116 / 117 (e.g., VRU Profile 3 - Motorcycle Driver) are approaching within the minimum safe lateral distance (MSLaD), within the minimum safe longitudinal distance (MSLoD), and within the minimum safe vertical distance (MSVD), and has decided to leave the cluster and enter the VRU-ACTIVE-STANDALONE VBS state to send an immediate VAM. 9. VRU116 / 117 is in the VRU-PASSIVE VBS state, and it has been determined that the VRU cluster leader has been lost, so it has decided to enter the VRU-ACTIVE-STANDALONE VBS state. 10. VRU116 / 117 is in the VRU-ACTIVE-CLUSTERLEADER VBS state, has decided to dismantle the cluster, has sent a VRU cluster VAM with a dissolution instruction, and has decided to enter the VRU-ACTIVE-STANDALONE VBS state.

[0229] Consecutive VAM transmissions are subject to the conditions described herein. Consecutive individual VAM generation events occur at intervals of T_GenVam or greater. An individual VAM is generated for transmission as part of a generation event if the source VRU-ITS-S117 is still in the VBS VRU-ACTIVE-STANDALONE VBS state, any of the following conditions are met, and the individual VAM transmission is not subject to redundancy mitigation techniques. 9. The elapsed time since the last transmission of an individual VAM exceeds T_GenVamMax. 10. The Euclidean absolute distance between the current estimated position of the VRU reference point and the estimated position of the reference point last included in the individual VAM exceeds the predefined threshold minReferencePointPositionChangeThreshold. 11. The difference between the current estimated ground speed of the reference point of VRU116 and the estimated absolute speed of the reference point of the last VRU included in the individual VAM exceeds the predefined threshold minGroundSpeedChangeThreshold. 12. The difference between the direction of the current estimated ground velocity vector of the VRU116 reference point and the estimated direction of the ground velocity vector of the VRU116 reference point last included in the individual VAM exceeds the predefined threshold minGroundVelocityOrientationChangeThreshold. 13. The difference between the current estimated collision probability with a vehicle or other VRU116 (e.g., measured by the trajectory interception probability) and the estimated collision probability with a vehicle or other VRU116 last reported in the individual VAM exceeds the predefined threshold minCollisionProbabilityChangeThreshold. 14. The originating ITS-S is a VRU in the VRU-ACTIVE-STANDALONE VBS state and has decided to join the cluster after sending its previous individual VAM. 15. VRU116 / 117 determines that one or more new vehicles or other VRU116 / 117 simultaneously meet the following conditions after the last VAM transmitted: the vehicle is closer than the minimum safe lateral distance (MSLaD) in the lateral direction, closer than the minimum safe longitudinal distance (MSLoD) in the longitudinal direction, and closer than the minimum safe vertical distance (MSVD) in the vertical direction.

[0230] VRU cluster VAM transmission management by VBS in VRU-ITS-S. If any of the following conditions are met, such as VRU116 in the VRU-ACTIVE-STANDALONE VBS state deciding to form a VRU cluster, and VRU cluster VAM transmission is not subject to redundancy mitigation techniques, the first VRU cluster VAM should be generated immediately or at the earliest possible time for transmission.

[0231] Consecutive VRU cluster VAM transmissions are subject to the conditions described herein. Consecutive VRU cluster VAM generation events occur in the cluster leader at intervals of T_GenVam or greater. A VRU cluster VAM is generated for transmission by the cluster leader as part of a generation event if any of the following conditions are met and the VRU cluster VAM transmission is not subject to redundancy mitigation techniques. 17. The elapsed time since the last VRU cluster VAM transmission exceeds T_GenVamMax. The Euclidean absolute distance between the current estimated position of the VRU cluster's reference point and the estimated position of the reference point last included in the VRU cluster VAM exceeds the predefined threshold minReferencePointPositionChangeThreshold. The difference between the current estimated width of the cluster and the estimated width included in the last submitted VAM exceeds the predefined threshold minClusterWidthChangeThreshold. The difference between the current estimated length of the cluster and the estimated length included in the last submitted VAM exceeds the predefined threshold minClusterLengthChangeThreshold. The difference between the current estimated ground speed of the VRU cluster's reference point and the estimated absolute speed of the reference point last included in the VRU cluster VAM exceeds the predefined threshold minGroundSpeedChangeThreshold. The difference between the direction of the current estimated ground velocity vector of the reference point in the VRU cluster and the estimated direction of the ground velocity vector of the reference point last included in the VRU cluster VAM exceeds the predefined threshold minGroundVelocityOrientationChangeThreshold. The difference between the current estimated collision probability of a VRU cluster with a vehicle or other VRU (measured, for example, by the trajectory obstruction probability of other vehicles / VRU116 / 117 with respect to the cluster boundary area) and the estimated collision probability with a vehicle or other VRU last reported in VAM exceeds the minCollisionProbabilityChangeThreshold. The VRU cluster type has changed since the previous VAM generation event (for example, from a homogeneous cluster to a heterogeneous cluster, or vice versa). The cluster leader has decided to dismantle the cluster after the previous VRU cluster VAM transmission. Following the previous VRU cluster VAM transmission, more new VRU116 / 117s than the predefined number have joined the VRU cluster. Since the previous VRU cluster VAM was sent, more than the predefined number of members have left the VRU cluster. A VRU in the VRU-ACTIVE-CLUSTERLEADER VBS state determines that one or more new vehicles or non-member VRU116 / 117 (e.g., VRU profile 3 - motorcycle driver) have simultaneously met the following conditions since the last VAM: being closer than the minimum safe lateral distance (MSLaD) in the lateral direction, closer than the minimum safe longitudinal distance (MSLoD) in the longitudinal direction, and closer than the minimum safe vertical distance (MSVD) perpendicular to the cluster boundary box.

[0232] VAM redundancy mitigation. A balance is taken between the frequency of VAM generation at the facility layer and the communication overhead at the access layer, without affecting nearby VRU security and VRU recognition. VAM transmission in a VAM generation event may be subject to the following redundancy mitigation techniques. The source VRU-ITS-S117 skips the current individual VAM if all of the following conditions are met simultaneously: The elapsed time since the last VAM was transmitted by source VRU-ITS-S117 does not exceed N (e.g., 4) × T_GenVamMax. The Euclidean absolute distance between the current estimated position of the reference point and the estimated position of the reference point in the received VAM is less than minReferencePointPositionChangeThreshold, the difference between the current estimated speed of the reference point and the estimated absolute speed of the reference point in the received VAM is less than minGroundSpeedChangeThreshold, and the difference between the direction of the current estimated ground velocity vector and the estimated direction of the ground velocity vector of the reference point in the received VAM is less than minGroundVelocityOrientationChangeThreshold. Alternatively, one of the following conditions is met: VRU116 refers to an appropriate map to verify whether VRU116 is in a protected area such as a building or an area where driving is not permitted; VRU is in a geographic area designated as a pedestrian zone; only VRU profiles 1 and 4 are permitted in the area; VRU116 considers itself a member of a VRU cluster and has not received a cluster disintegration message from the cluster leader; information about itself VRU116 has been reported by another ITS-S in T_GenVam.

[0233] VAM generation time. In addition to the VAM generation frequency, the time required for VAM generation and the timeliness of the data taken for message construction are critical to the applicability of the data at the receiving ITS-S. To ensure proper interpretation of received VAMs, each VAM is time-stamped. Acceptable time synchronization between different ITS-S is expected, which is outside the scope of this specification. The time required for VAM generation is less than T_AssembleVAM. The time required for VAM generation refers to the time difference between the time VAM generation is triggered and the time the VAM is sent to the N&T layer.

[0234] VAM timestamp. The reference timestamp provided in the VAM distributed by ITS-S corresponds to the time when the reference position provided in the BasicContainer DF is determined by the originating ITS-S. The format and range of the timestamp are defined in section B.3 of ETSI EN 302 637-2 V1.4.1 (2019-04) (hereinafter "[EN302637-2]"). The difference between the VAM generation time and the reference timestamp is less than 32767ms, as specified in [EN302637-2]. This may help avoid the timestamp wraparound issue.

[0235] VAM transmission. VRU-ITS-S117 in VRU-ACTIVE-STANDALONE state transmits an "individual VAM," while VRU ITS-S in VRU-ACTIVE-CLUSTERLEADER VBS state transmits a "cluster VAM" on behalf of the VRU cluster. Cluster member VRU-ITS-S117 in VRU-PASSIVE VBS state transmits an individual VAM containing the VruClusterOperationContainer while leaving the VRU cluster. VRU-ITS-S117 in VRU-ACTIVE-STANDALONE state transmits a VAM as an "individual VAM" containing the VruClusterOperationContainer while participating in the VRU cluster.

[0236] The VRU116 / 117 exhibits diverse profiles that result in random behavior when moving within a shared area. Furthermore, the inertia of the VRU is much lower than that of a vehicle (for example, a pedestrian can make a U-turn in less than a second), making the VRU's kinematics more difficult to predict.

[0237] VBS221 enables the distribution of VRU Recognition Messages (VAMs), the purpose of which is to create recognition at the level of other VRUs 116 / 117 or vehicle 110 in order to resolve conflict situations that could lead to a collision. Possible actions a vehicle can take to resolve a conflict situation are directly related to the remaining time before the conflict, vehicle speed, the vehicle's ability to decelerate or change lanes, and weather and vehicle conditions (e.g., road conditions and vehicle tire condition). In the best case, a vehicle may have 1-2 seconds to avoid a collision, but in the worst case, it may take more than 4-5 seconds to avoid a collision. If a vehicle is very close to a VRU and at a constant speed (e.g., 1-2 seconds to collision), this serves as a warning to both the VRU and the vehicle, so there is no need to discuss recognition further.

[0238] For a VRU 116 / 117 and a vehicle in a conflict situation, the conflict situation must be detected at least 5-6 seconds before reaching the point of conflict in order to ensure that there is enough time to act to avoid a collision. Generally, collision risk indicators (e.g., TTC, TDTC, PET, etc., see e.g., [TS103300-2]) are used to predict the moment of conflict. These indicators require prediction of the trajectory (path) that the VRU and the vehicle will take, and / or the time it will take for the VRU and the vehicle to reach the point of conflict together.

[0239] These predictions should be derived from data elements exchanged between the target VRU and the target vehicle. In the case of a vehicle, the vehicle's trajectory is constrained by road terrain, traffic, traffic regulations, etc., but because VRU116 / 117 have a much greater degree of freedom of movement, trajectory and time predictions can be made better than for VRUs. In the case of vehicles, their dynamics are also constrained by their size, mass, and ability to vary in direction of travel, which is not true for most VRUs.

[0240] Therefore, in many situations, it is impossible to predict the exact trajectory or velocity of VRU116 / 117 based solely on the VRU's recent path history and current position. Attempting to do so would likely result in numerous false positives and false negatives, potentially leading to incorrect collision avoidance decisions.

[0241] Possible methods to avoid false positives and false negatives include basing vehicle and VRU path predictions on deterministic information (kinetic change indications) provided by the vehicle and VRU, respectively, and a better understanding of the statistical VRU behavior in iterative contextual situations. Predictions can always be verified retrospectively when constructing the path history. In this case, detected errors can be used to correct future predictions.

[0242] VRU dynamics change instructions (MDCI) are either provided directly by the VRU device itself or constructed from deterministic indicators arising from mobility mode state changes (e.g., transitioning from pedestrian to cyclist, from pedestrian on bicycle to pedestrian pushing bicycle, from motorcyclist on motorcycle to being thrown from motorcycle and becoming motorcyclist, transitioning from a dangerous area to a protected area, such as entering tram tracks or a train).

[0243] Figure 5 shows an exemplary VAM format structure. As shown in Figure 5, the VAM includes a common ITS PDU header, a generation (delta) time container, a base container, a VRU high-frequency container containing the VRU's mechanical properties (e.g., motion, acceleration, etc.), a VRU low-frequency container containing the VRU's physical properties (conditionally required, e.g., at a higher frequency, see Section 7.3.2 of [TS103300-3]), a cluster information container, a cluster behavior container, and a motion prediction container. In some implementations, the VAM is extensible, but extensibility is not defined herein.

[0244] The ITS PDU header shall be as specified in ETSI TS 102 894-2 V1.3.1(2018-08) ("[TS102894-2]"). Detailed data presentation rules for the ITS PDU header in the context of VAM shall be as specified in Annex B of [TS103300-3]. The StationId field in the ITS PDU header shall change when the signature pseudonym certificate changes or when a VRU begins sending individual VAMs after being a member of a cluster (for example, when a VRU disassembles a cluster as a leader or when it leaves a cluster as an arbitrary cluster member). An exception may be when a VRU device experiences a cluster "join failure" as defined in section 5.4.2.2 of [TS103300-3], in which case it must continue to use the StationId and other identifiers used before the join failure. The generation time in the VAM is the GenerationDeltaTime used by the CAM. This is a measure of the number of milliseconds elapsed since the ITS epoch, modulo 2 16 (For example, 65536.)

[0245] The base container provides basic information about the source ITS-S, including, for example, the type of source ITS-S and the latest geographical location of the source ITS-S. For the type of source ITS-S, this DE overlaps in some way with the VRU profile, even if not a perfect match (for example, both Moped (3) and Motorcycle (4) correspond to VRU profile 3). To allow for the future possibility of having VAMs transmitted by non-VRU ITS-S (see Section 4.1 and Annex I), both data elements are kept independent. For the latest geographical location of the source ITS-S obtained by VBS at the time of VAM generation, this DF is already defined in [TS102894-2] and includes positionConfidenceEllipse, which provides measurement location accuracy with a 95% confidence level. The base container shall exist for VAMs generated by all ITS-S implementing VBS.

[0246] The basic container has the same structure as the BasicContainer in other ETSI ITS messages, but the type DE includes VRU-specific type values ​​that are not used by BasicContainer for vehicle messages. At some point in the future, the type field of the ITS Common Data Dictionary (CDD) in [TS102894-2] is intended to be extended to include VRU types. At this point, the VRU BasicContainer and Vehicle BasicContainer will be identical.

[0247] All VAMs generated by VRU ITS-S include at least a VRU High Frequency (VRU HF) container. The VRU HF container contains potentially rapidly changing situational information from VRU ITS-S, such as direction of travel and speed. Since VAMs are not used by VRUs from Profile 3 (motorcycle rider), none of these containers apply to VRU Profile 3. Instead, VRU Profile 3 transmits only motorcycle-specific containers using CAM (see, for example, sections 4.1, 7.4, and 4.4 of [TS103300-2]). In addition, if the relevant conditions are met, VAMs generated by VRU ITS-S may include one or more of the containers specified in Table 7. [Table 31]

[0248] The VAM's VRU HF container contains potentially rapidly changing status information for VRU ITS-S. The VAM's VRU HF container shall contain the parameters listed in Section B.3.1.

[0249] Some of the information in this container is not meaningful for certain VRU profiles. Therefore, they are presented as optional but recommended for specific VRU profiles.

[0250] Note: VRU profiles are contained within VRU LF containers and are therefore not transmitted as frequently as VRU HF containers (see Section 6.2). However, recipients may infer the VRU profile from the vruStationType field, where pedestrians indicate profile 1, cyclists or light VRU vehicles indicate profile 2, mopeds or motorcycles indicate profile 3, and animals indicate profile 4.

[0251] The DF used to describe lane positions within a CAM is insufficient when considering VRUs because it does not include bicycle paths and sidewalks. Therefore, it has been extended to cover all possible locations where a VRU may be located. Where present, the vruLanePosition DF shall describe either a lane on the road (the same as for vehicles), a lane off the road, or a traffic island between two of the aforementioned types of lanes. Further details are provided in the DF definitions in section B.3.10.

[0252] VruOrientation DF complements the dimensions of the VRU vehicle by defining the angle of the VRU vehicle's longitudinal axis relative to WGS84 North. VruOrientation DF is limited to VRUs from Profile 2 (cyclist) and Profile 3 (motorcycle rider). If present, VruOrientation DF shall be as defined in Section B.3.17. VruOrientationAngle, unlike the vehicle's direction of travel which relates to VRU motion, is oriented relative to the VRU's position.

[0253] RollAngle DF provides instructions for cornering a motorcycle. RollAngle DF is defined as the angle between the ground and the current orientation of the vehicle's y-axis relative to the ground around the x-axis, as specified in [ISO8855]. This DF also includes angular precision. Both values ​​are encoded in the same way as DF_Heading, following the conventions described below, see A.101 of [TS102894-2].

[0254] A positive value indicates rolling to the right (0...500), where 500 corresponds to a roll angle of 50 degrees to the right.

[0255] A negative value indicates rolling to the left (3600..."3100"), where 3100 corresponds to a roll angle of 50 degrees to the left.

[0256] Values ​​between 500 and 3100 will not be used.

[0257] The DE vruDeviceUsage provides VAM recipients with instructions regarding the parallel activity of the VRU. This DE is similar to DE_PersonalDeviceUsageState specified in SAE International, "Vulnerable Road User Safety Message Minimum Performance Requirements," V2X Vehicular Applications Technical Committee, SAE Ground Vehicle Standard J2945 / 9 (March 1, 2017) ("[SAE-J2945 / 9]"). This DE is limited to VRUs from profile 1, e.g., pedestrians. If present, this DE shall be as defined in section B.3.19 and provide the possible values ​​shown in Table 25. To respect the user's choice for privacy, the device configuration application should include a consent form for transmitting this information. How this consent form is implemented is outside the scope of this specification. If this choice is opted out (default), the device shall systematically transmit the value "Unavailable (0)". [Table 32]

[0258] DE VruMovementControl describes the mechanism used by the VRU to control the longitudinal motion of the VRU vehicle. DE VruMovementControl primarily targets VRUs from Profile 2, e.g., a person riding a bicycle. Where present, DE VruMovementControl is presented as defined in Section B.3.16 and provides the possible values ​​shown in Table 26. The use of the different values ​​provided in the table may depend on the country to which they apply. For example, in some countries, depending on the bicycle, pedal motion may be required for braking. This DE can also function as information for onboard systems of surrounding vehicles to identify (in particular) a person riding a bicycle, and thus can improve / speed up the "matching" process between messages already received from the VRU vehicle (before it enters the car's field of view) and objects detected by the cameras of the other vehicle (after the VRU vehicle enters the field of view). [Table 33]

[0259] The VRU LF container of the VAM contains the potential slowly changing information of the VRU ITS-S. This container shall contain the parameters listed in section B.4.1 of [TS103300-3]. Some elements are mandatory, while others are optional or conditionally required.

[0260] The VRU LF container shall be included in the VAM at a parameterizable frequency as specified in Section 6.2 of [TS103300-3]. The VAM VRU LF container shall have the following content:

[0261] DE VruProfileAndSubProfile, if defined, shall include the identification of the profile and subprofile of the originating VRU ITS-S. Table 27 lists the profiles and subprofiles specified herein. [Table 34]

[0262] If a VRU LF container exists, DE VruProfileAndSubProfile is optional. If it does not exist, this means the profile is unavailable. The subprofile of VRU profile 3 is used only in CAM-only containers. DE VRUSizeClass contains information about the size of the VRU. DE VruSizeClass is assumed to depend on the VRU profile. This dependency is shown in Table 28. [Table 35]

[0263] DE VruExteriorLight shall indicate the status of the most important external lighting switches of the VRU ITS-S emitting VAM. DE VruExteriorLight shall be mandatory for Profiles 2 and 3 if a low VRU LF container is present. For all other profiles, this shall be optional.

[0264] The VAM VRU cluster container contains cluster information and / or operation related to the VRU cluster of VRU ITS-S. The VRU cluster container consists of two types of cluster containers, depending on the characteristics of the data / parameters it contains.

[0265] The VRU cluster information container shall be attached to the VAM originating from the VRU cluster leader. This container shall provide information / parameters related to the VRU cluster. The VRU cluster information container shall be of type VruClusterInformationContainer.

[0266] The VRU cluster information container shall contain information regarding the cluster ID, the shape of the cluster bounding box, the cluster density size, and the profile of the VRUs within the cluster. The cluster ID is of type ClusterID. The ClusterID shall be selected by the cluster leader to be non-zero and locally unique, as specified in section 5.4.2.2 of [TS103300-3]. The shape of the VRU cluster bounding box shall be specified by DF ClusterBoundingBoxShape. The shape of the cluster bounding box may be rectangular, circular, or polygonal.

[0267] The VRU cluster operation container shall contain information about changes in the cluster state and configuration. This container may be included by the cluster VAM sender or by a cluster member (leader or regular member). The cluster leader shall include the VRU cluster operation container for performing cluster operations such as dissolution (breakup) of the cluster. Cluster members shall include the VRU cluster operation container in their individual VAMs for performing cluster operations such as joining a VRU cluster and leaving a VRU cluster.

[0268] The VRU cluster operation container is of type VruClusterOperationContainer. VruClusterOperationContainer includes the following: DF clusterJoinInfo for cluster operation, enabling new members to join a VRU cluster. DF clusterLeaveInfo for an existing cluster member to leave a VRU cluster. DF clusterBreakupInfo is used to execute cluster operations in which the cluster leader dissolves (breaks down) each cluster. The DE clusterIdChangeTimeInfo indicates that the cluster leader plans to change the cluster ID at the time indicated by the DE. For privacy reasons, no instructions are provided for the new ID (see, for example, sections 5.4.2.3 and 6.5.4 of [TS103300-3]).

[0269] VRU devices joining or leaving a cluster, as notified by messages other than VAM, shall be indicated using a ClusterId value of 0.

[0270] VRU devices leaving a cluster shall use DE ClusterLeaveReason to indicate the reason for leaving the cluster. Available reasons are shown in Table 29. VRU leading devices breaking up a cluster shall use ClusterBreakupReason to indicate the reason for breaking up the cluster. Available reasons are shown in Table 30. If the reason for leaving or breaking up a cluster does not exactly match one of the available reasons, the device shall systematically send the value "notProvided(0)".

[0271] In particular, a VRU in a cluster may determine that one or more new vehicles or other VRUs (e.g., VRU profile 3 - motorcycle driver) are approaching within the minimum safe lateral distance (MSLaD), within the minimum safe longitudinal distance (MSLoD), and within the minimum safe vertical distance (MSVD) (e.g., the minimum safe distance conditions are met as described in section 6.5.10.5 of [TS103300-2]), and the VRU will leave the cluster and enter the VRU-ACTIVE-STANDALONE VBS state to immediately send a VAM with ClusterLeaveReason "SafetyCondition(8)". The same applies if any other safety issue is detected by the VRU device.

[0272] Device suppliers must declare the conditions under which a VRU device will join or leave a cluster. [Table 36] [Table 37]

[0273] The VruClusterOperationContainer does not include the creation of the VRU cluster by the cluster leader. When the cluster leader starts sending the cluster VAM, it indicates that the cluster leader has created the VRU cluster. While the cluster leader is sending the cluster VAM, any individual VRU can join the cluster if the participation conditions are met.

[0274] The VRU motion prediction container carries information about the past and future motion state of the VRU. The VRU motion prediction container of type VruMotionPredictionContainer shall include the past position of the VRU of type PathHistory, the predicted future position of the VRU (formatted as SequenceOfVruPathPoint), information regarding the safe distance indication between the VRU and other road users / objects of type SequenceOfVruSafeDistanceIndication, possible trajectory interception of the VRU by another VRU / object of type SequenceOfTrajectoryInterceptionIndication, changes in the acceleration of the VRU of type AccelerationChangeIndication, changes in the direction of travel of the VRU of HeadingChangeIndication, and changes in the stability of the VRU of type StabilityChangeIndication.

[0275] A path history DF is of type PathHistory. A PathHistory DF shall contain the recent movements of a VRU over past time and / or distance. A PathHistory DF may consist of up to 40 past path points (see, for example, [TS102894-2]). If a VRU leaves a cluster and wants to send its past location via VAM, the VRU may use a PathHistory DF.

[0276] The route prediction DF is of type SequenceOfVruPathPoint and defines up to 40 future path points, confidence values, and corresponding time instances of VRU ITS-S. The route prediction DF contains future path information up to 10 seconds or up to 40 path points, whichever is smaller.

[0277] The safe distance indication is of type SequenceOfVruSafeDistanceIndication and provides an indication of whether the VRU is at a recommended safe distance laterally, longitudinally, and vertically from up to eight other stations in its vicinity. A simultaneous comparison between the lateral distance (LaD), longitudinal distance (LoD), and vertical distance (VD) and their respective thresholds, Minimum Safe Lateral Distance (MSLaD), Minimum Safe Longitudinal Distance (MSLoD), and Minimum Safe Vertical Distance (MSVD), as defined in Section 6.5.10.5 of [TS103300-2], shall be used to set the VruSafeDistanceIndication DF. Other ITS-S involved are indicated as StationID DE within the VruSafeDistanceIndication DE. The timetocollision(TTC)DE within the container shall reflect the estimated time required for collision based on the most recent onboard sensor measurements and VAM.

[0278] The SequenceOfTrajectoryInterceptionIndication DF shall include possible trajectory interceptions of the VRU by up to eight other stations within its vicinity. Trajectory interceptions of a VRU are indicated by the VruTrajectoryInterceptionIndication DF. Other ITS-S involved are specified by the StationID DE. The trajectory interception probability and its confidence level metrics are indicated by the TrajectoryInterceptionProbability DE and TrajectoryInterceptionConfidence DE.

[0279] The Track Interruption Instructor (TII) DF corresponds to the TII definition in [TS103300-2].

[0280] The AccelerationChangeIndication DF shall include the future acceleration change (acceleration or deceleration) of the self-VRU over a certain period of time. DE AccelOrDecel shall provide the choice between acceleration and deceleration. DE ActionDeltaTime shall indicate the duration.

[0281] HeadingChangeIndication DF shall include the future change in the direction of travel (left or right) of the self VRU over a certain period of time. DE LeftOrRight shall provide the option of changing direction to the left or right. DE ActionDeltaTime shall indicate the duration.

[0282] StabilityChangeIndication DF shall include the change in the stability of the self-VRU over a certain period of time. DE StabilityLossProbability shall indicate the probability of loss of stability of the self-VRU. DE ActionDeltaTime shall indicate the duration.

[0283] The container description is given in section B.7 of [TS103300-3], and the corresponding DF and DE to be added to [TS102894-2] are given in section F.7 of [TS103300-3].

[0284] The ITS station for a VRU profile 3 device (motorcycle driver) already transmits a CAM. Therefore, as specified in [TS103300-2] and section 5, those ITS stations do not transmit a complete VAM, but may transmit a VRU-specific vehicle container with the CAM they already transmit. Where applicable, this requirement also applies to a composite VRU consisting of one VRU profile 3 (motorcycle) and one or more VRU profile 1 (pedestrian) (see section 5.4.2.6 of [TS103300-3]).

[0285] The purpose of this dedicated vehicle container is to notify surrounding vehicles that the V-ITS-S is hosted by a VRU profile 3 device and to provide additional instructions regarding VRU profile 3. The dedicated container for motorcycle drivers shall include the parameters listed in section D.2 of [TS103300-3].

[0286] Returning to Figure 3, the VRU116 / 117 can be classified into four profiles as defined in Section 4.1 of [TS103300-3]. SAE International, “Taxonomy and Classification of Powered Micromobility Vehicles,” Powered Micromobility Vehicles Committee, SAE Ground Vehicle Standard J3194 (November 20, 2019) ("[SAE-J3194]") also proposes the following classifications and classifications for powered micromobility vehicles: powered bicycles (e.g., electric bicycles), powered stand-up scooters (e.g., Segway®), powered seated scooters, powered self-balancing boards also called “self-balancing scooters” (e.g., Hoverboard® self-balancing boards and Onewheel® self-balancing single-wheel electric boards), powered skates, etc. Their main characteristics are vehicle weight, vehicle width, top speed, and power source (electric or combustion). Human-powered micromobility vehicles (bicycles, stand-up scooters) should also be considered. A transition between engine-driven and human-powered vehicles may occur, potentially altering the vehicle's dynamics. It is also possible that both human-powered and engine-driven systems may operate in parallel, affecting the vehicle's dynamics.

[0287] Sections 5.4.2.6 of [TS103300-2] and [TS103300-3] define a composite VRU116 / 117 as an assembly of VRU Profile 1 having one or more additional VRU116 / 117s, potentially accompanied by one VRU vehicle or animal. Several VRU vehicle types are possible. Even though most of those VRU vehicle types can carry a VRU, their propulsion modes differ and may lead to certain threats and vulnerabilities, and they may be propelled by humans (humans riding in the vehicle or humans riding in the animal) or by a thermal engine. In this case, the thermal engine is operated only when the ignition system is activated and / or they may also be propelled by an electric engine. In this case, the electric engine is operated immediately when the power is on (no ignition).

[0288] A composite VRU116 / 117 can be an assembly of one human and one animal (e.g., a person and a horse or a person and a camel). The person riding the horse may decide to dismount and lead the horse. In this case, VRU116 / 117 performs a transition from profile 2 to profile 1, with an impact on its velocity.

[0289] This diversity in VRU116 / 117 and cluster associations results in several VBS state machines that condition the distribution of standard messages and their respective dynamics. These state machines and their transitions can be summarized as shown in Figure 4.

[0290] Figure 4 shows an exemplary state machine and transition 400. In Figure 4, when the VRU is configured as VRU 402 of profile 2 with multiple devices attached, it is necessary to select the active VRU. This can be achieved for each device attached during the initial setup (configuration parameters) when the devices are activated. In Figure 4, the devices attached to the bicycle are configured to be active while combined with the VRU. However, when the VRU returns to profile 1 state 401, the devices attached to the VRU vehicle must be deactivated, while the VBS 221 within the devices attached to the VRU will resend the VAM if it is not in a protected location.

[0291] In the future, the VRUs of profile 2 402, profile 1 401, and profile 4 404 may become members of the cluster and thus add the state machine associated with the clustering operation to their own state. This means that the VRUs of profile 2 402, profile 1 401, and profile 4 404 must comply with cluster management requirements while continuing to manage their own state. When transitioning from one state to another, a composite VRU may leave the cluster if it no longer meets those requirements.

[0292] The mechanical state transitions identified in Figure 4 (e.g., T1-T4) affect the kinematics of the VRU. These transitions are continuously and deterministically detected with respect to VRU determination or mechanical causes (e.g., VRU ejection from the VRU vehicle). The identified transitions have the following VRU kinematic effects:

[0293] T1 is the transition from VRU profile 1 401 to profile 2 402. This transition is triggered manually or automatically when the VRU decides to actively use the VRU vehicle it is riding in. The VRU's kinetic velocity parameter values ​​change from low speed (pushing / pulling its own VRU vehicle) to faster speeds associated with the selected VRU vehicle class.

[0294] T2 is the transition from VRU profile 2 402 to profile 1 401. This transition is triggered manually or automatically when the VRU exits its VRU vehicle and leaves the VRU vehicle to become a pedestrian. The VRU's kinematic velocity parameter value changes from a given speed to a lower speed associated with the selected VRU vehicle class.

[0295] T3 is the transition from VRU profile 2 402 to profile 1 401. This transition is triggered manually or automatically when the VRU disembarks from the VRU vehicle and pushes / pulls the VRU vehicle into a protected environment (e.g., tram tracks, bus, train). The VRU's kinetic velocity parameter value changes from a given speed to a lower speed associated with the selected VRU vehicle class.

[0296] T4 is a transition from VRU profile 2 402 to profile 1 401. This transition is automatically triggered when it is detected that the VRU has been ejected from its own VRU vehicle. The VRU's kinetic velocity parameter value changes from a given speed to a lower speed associated with the VRU state resulting from the VRU being ejected. In this case, the VRU vehicle is considered an obstacle on the road and therefore needs to distribute DENM until it is removed from the road (its ITS-S is deactivated).

[0297] A throw-off can be detected by a stability index that includes the rider's skill level derived from the inertial sensor and its behavior. In this case, stability can be expressed as the risk level at which complete stability is lost. If the risk level is 100%, this can be determined as a de facto throw-off of the VRU.

[0298] By analyzing the variability of the dynamic velocity parameter values, it is possible to provide new path predictions from registered "contextual" past path history (average VRU traces). The contextual configuration considers several parameters related to the same context in which the VRU is evolving.

[0299] In addition to the state transitions described above, which can have a dramatic impact on VRU velocity, the following VRU instructions also affect VRU velocity and / or VRU trajectory (in addition to the parameters already defined in VAM).

[0300] Stop Indicator. A VRU or external source (a traffic signal that is red relative to the VRU) may indicate that the VRU has been stopped for a period of time. When this indicator is set, it may also be useful to know the duration of the VRU stop. This duration can be estimated either when provided by an external source (e.g., SPATEM information received from a traffic signal) or when known through analysis of VRU behavior in similar circumstances.

[0301] Visibility indicators. Weather conditions affect the visibility of a VRU, which can alter its dynamics accordingly. Even if a local vehicle detects these weather conditions, it may be difficult for the vehicle to estimate their impact on the VRU. Typical examples include: Depending on its orientation, a VRU may be hindered by the harsh glare of the sun (e.g., in the morning when the sun is rising or in the evening when the sun is setting), potentially limiting its speed.

[0302] Returning to Figure 2, the N&T layer 203 provides the functions of the OSI network layer and OSI transport layer, and includes one or more networking protocols, one or more transport protocols, and network and transport layer management. In addition, the sensor interface and communication interface configurations may be part of the N&T layer 203 and access layer 204. Networking protocols may include, in particular, IPv4, IPv6, IPv6 networking with mobility support, IPv6 over GeoNetworking, CALM FAST protocol, etc. Transport protocols may include, in particular, BOSH, BTP, GRE, GeoNetworking protocol, MPTCP, MPUDP, QUIC, RSVP, SCTP, TCP, UDP, VPN, one or more dedicated ITSC transport protocols, or any other suitable transport protocol. Each of the networking protocols may be connected to the corresponding transport protocol.

[0303] The access layer includes a physical layer (PHY) 204 that physically connects to the communication medium, a data link layer (DLL) which can be subdivided into a medium access control sublayer (MAC) that manages access to the communication medium, a logical link control sublayer (LLC), a managed adaptive entity (MAE) for directly managing the PHY 204 and DLL, and a security adaptive entity (SAE) for providing security services to the access layer. The access layer may also include an external communication interface (CI) and an internal CI. A CI is an instantiation of a specific access layer technology or RAT and protocol, such as 3GPP LTE, 3GPP 5G / NR, C-V2X (e.g., based on 3GPP LTE and / or 5G / NR), WiFi, W-V2X (e.g., including ITS-G5 and / or DSRC), DSL, Ethernet, Bluetooth, and / or any other RAT and / or communication protocol discussed herein, or a combination thereof. A CI provides the functionality of one or more logical channels (LCHs), and the mapping of LCHs to physical channels is specified by the standards of the particular access technology involved. As mentioned above, V2X RATs may include ITS-G5 / DSRC and 3GPP C-V2X. In addition, or as an alternative, other access layer technologies (V2X RATs) may be used.

[0304] The ITS-S reference architecture 200 may be applicable to the elements in Figures 6 and 8. ITS-S gateways 611, 811 (see, for example, Figures 6 and 8) interconnect OSI protocol stacks at OSI layers 5 through 7 in the facility layer. The OSI protocol stack is typically connected to a system network (e.g., vehicle systems or roadside systems), while the ITSC protocol stack is connected to the ITS station internal network. The ITS-S gateways 611, 811 (see, for example, Figures 6 and 8) can convert protocols, enabling ITS-S to communicate with external elements of the system in which it is implemented. The ITS-S routers 611, 811 provide the functional ITS-S reference architecture 200 excluding the application and facility layers. The ITS-S routers 611, 811 interconnect two different ITS protocol stacks at layer 3. The ITS-S routers 611, 811 may also be able to convert protocols. One of these protocol stacks typically connects to the ITS station's internal network. The ITS-S boundary router 814 (see, for example, Figure 8) provides the same functionality as the ITS-S routers 611 and 811, but includes a protocol stack related to external networks that may not adhere to ITS management and security principles (e.g., the ITS management layer and ITS security layer in Figure 2).

[0305] In addition, other entities operating at the same level but not included in ITS-S include related users at that level, related HMIs (e.g., audio devices, display / touchscreen devices, etc.), vehicle motion control for computer-assisted vehicles and / or automated vehicles (both HMI entities and vehicle motion control entities may be triggered by ITS-S applications) if the ITS-S is a vehicle, sensor systems and IoT platforms of local devices that collect and share IoT data, sensor fusion and actuator applications of local devices that include ML / AI and can aggregate the data flow emitted by the sensor systems, local perception and trajectory prediction applications that consume the output of the fusion applications and supply it to the ITS-S applications, and related ITS-S, as well as related ITS-S. Sensor systems may include one or more cameras, radar, LIDAR, etc., within the V-ITS-S110 or R-ITS-S130. At the central station, sensor systems may include sensors located along the roadside but that report their data directly to the central station without the involvement of the V-ITS-S110 or R-ITS-S130. In some cases, the sensor system may further include gyroscopes, accelerometers, etc. (see, for example, sensor circuit 1272 in Figure 12). Embodiments of these elements are discussed below with respect to Figures 6, 7, and 8.

[0306] Figure 6 shows an exemplary vehicle computing system 600. In this example, the vehicle computing system 600 includes a V-ITS-S 601 and an electronic control unit (ECU) 605. The V-ITS-S 601 includes a V-ITS-S gateway 611, an ITS-S host 612, and an ITS-S router 613. The vehicle ITS-S gateway 611 provides the function of connecting components of the in-vehicle network (e.g., ECU 605) to the ITS station internal network. The interface to the in-vehicle components (e.g., ECU 605) may be the same as or similar to those discussed herein (see, for example, IX1256 in Figure 12), and / or may be a unique interface / interconnection. Access to the components (e.g., ECU 605) may be implementation-specific. The ECU 605 may be the same as or similar to the driver control unit (DCU) 174 described above with respect to Figure 1. The ITS station connects to the ITS ad-hoc network via the ITS-S router 613.

[0307] Figure 7 shows an exemplary personal computing system 700. The personal ITS subsystem 700 provides ITSC application and communication capabilities in mobile devices such as smartphones, tablet computers, wearable devices, PDAs, portable media players, laptops, and / or other mobile devices. The personal ITS subsystem 700 includes a personal ITS station (P-ITS-S) 701 and various other entities not included in the P-ITS-S 701, which will be discussed in more detail below. A device used as a personal ITS station may also perform HMI functions as part of another ITS subsystem, connecting to another ITS subsystem via an ITS station internal network (not shown). For the purposes of this disclosure, the personal ITS subsystem 700 may be used as a VRU ITS-S 117.

[0308] Figure 8 shows an exemplary roadside infrastructure system 800. In this example, the roadside infrastructure system 800 includes R-ITS-S801, an output device 805, a sensor 808, and one or more radio units (RUs) 810. R-ITS-S801 includes R-ITS-S gateway 811, ITS-S host 812, ITS-S router 813, and ITS-S boundary router 814. The ITS station connects to the ITS ad-hoc network and / or the ITS access network via the ITS-S router 813. The R-ITS-S gateway 811 provides the function of connecting roadside system components in the roadside network (e.g., output device 805 and sensor 808) to the ITS station internal network. Interfaces to on-board components (e.g., ECU 605) may be the same as or similar to those discussed herein (see, for example, IX1256 in Figure 12), and / or may be unique interfaces / interconnections. Access to components (e.g., ECU605) may be implementation-specific. Sensor 808 may be the same as or similar to sensor 172 and / or sensor circuit 1272 described later with respect to Figure 12.

[0309] Actuator 813 is a device that plays a role in moving and controlling a mechanism or system. Actuator 813 is used to change the operating state (e.g., on / off, zoom or focus), position, and / or orientation of sensor 808. Actuator 813 is also used to change the operating state of several other roadside devices, such as gates, traffic signals, electronic signs, and variable information displays (VMS). Actuator 813 is configured to receive control signals from R-ITS-S801 via the roadside network and to convert signal energy (or any other energy) into electrical and / or mechanical motion. The control signals may be relatively low-energy voltages or currents. Actuator 813 comprises electromechanical relays and / or solid-state relays, which are configured to switch electronic devices on / off and / or control motors, and / or may be the same or similar actuator 1274 described later with respect to Figure 12.

[0310] Figures 6, 7, and 8 also show entities that operate at the same level but are not included in ITS-S, including related HMI606, 706, 806, vehicle motion control608 (at the vehicle level only), local device sensor systems and IoT platforms605, 705, 805, local device sensor fusion and actuator applications604, 704, 804, local perception and trajectory prediction applications602, 702, 802, motion prediction603, 703, or (at the RSU level) moving object trajectory prediction803, as well as connected systems607, 707, 807.

[0311] The local device sensor systems and IoT platforms 605, 705, and 805 collect and share IoT data. The VRU sensor system and IoT platform 705 consists of at least a PoTi management function present in each ITS-S of the system (see, for example, ETSI EN 302 890-2 ("EN302890-2")). The PoTi entity provides a global time and real-time location of moving elements common to all system elements. Local sensors may also be embedded in other moving elements as well as road infrastructure (e.g., cameras, electronic signs, etc., for smart traffic signals). IoT platforms that can be distributed across system elements may contribute to providing additional information related to the environment surrounding the VRU system 700. The sensor system may include one or more cameras, radar, LiDAR, and / or other sensors (see, for example, Figure 1222) within the V-ITS-S110 or R-ITS-S130. In VRU device 117 / 700, the sensor system may include a gyroscope, accelerometer, etc. (see, for example, 1222 in Figure 12). At a central station (not shown), the sensor system may be located along the roadside but includes sensors that report their data directly to the central station without the involvement of V-ITS-S110 or R-ITS-S130.

[0312] The (local) sensor data fusion function and / or actuator applications 604, 704, and 804 provide fusion of local perception data obtained from a VRU sensor system and / or different local sensors. This may include aggregating data flows emitted by the sensor system and / or different local sensors. Local sensor fusion and actuator applications may include machine learning (ML) / artificial intelligence (AI) algorithms and / or models. Sensor data fusion typically relies on the consistency of its inputs, and then on the consistency of their timestamps corresponding to a common given time. Sensor data fusion and / or ML / AL techniques may be used to determine the occupied values ​​of DCROM, as discussed herein.

[0313] Various ML / AI techniques can be used to perform sensor data fusion and / or for other purposes such as DCROM discussed herein. If apps 604, 704, and 804 are AI / ML functions (or contain AI / ML functions), they may include AI / ML models that have the ability to learn useful information (e.g., contextual information) from input data according to supervised learning, unsupervised learning, reinforcement learning (RL), and / or neural networks (NN). Separately trained AI / ML models can also be coupled together in an AI / ML pipeline during inference or predictive generation.

[0314] Input data may include AI / ML training information and / or AI / ML model inference information. Training information includes input (training) data plus ML model data including labels for supervised training, hyperparameters, parameters, probability distribution data, and other information necessary to train a particular AI / ML model. Model inference information is any information or data required as input to the AI / ML model for inference generation (or prediction). The data used by AI / ML models for training and inference can overlap considerably, but these information types refer to different concepts. Input data, also called training data, has known labels or results.

[0315] Supervised learning is a machine learning task that aims to learn a mapping function from input to output given a labeled dataset. Examples of supervised learning include regression algorithms (e.g., linear regression, logistic regression), instance-based algorithms (e.g., k-nearest neighbors), decision tree algorithms (e.g., classification and regression trees (CART), ID3 (Iterative Dichotomiser 3), C4.5, chi-squared automatic interaction detection (CHAID), fuzzy decision trees (FDT), etc.), support vector machines (SVM), Bayesian algorithms (e.g., Bayesian networks (BN), dynamic BN (DBN), naive Bayes, etc.), and ensemble algorithms (e.g., extreme gradient boosting, voting ensembles, bootstrap aggregation ("bagging"), random forests, etc.). Supervised learning can be further grouped into regression problems and classification problems. Classification concerns predicting labels, while regression concerns predicting quantities. In unsupervised learning, the input data is unlabeled and has no known results. Unsupervised learning is a machine learning task that aims to learn a function that describes the hidden structure from unlabeled data. Some examples of unsupervised learning are K-means clustering and principal component analysis (PCA). Neural networks (NNs) are typically used in supervised learning, but can also be used in unsupervised learning. Examples of NNs include deep NNs (DNNs), feedforward NNs (FFNs), deep FNNs (DFFs), convolutional NNs (CNNs), deep CNNs (DCNs), deconvolutional NNs (DNNs), deep belief NNs, perceptual NNs, recurrent NNs (RNNs) (including, for example, the Long Short-Term Memory (LSTM) algorithm and gated recurrent units (GRUs)), and deep stacking networks (DSNs). Reinforcement learning (RL) is goal-oriented learning based on interaction with the environment. In RL, the agent aims to optimize long-term goals by interacting with the environment based on a trial-and-error process. Examples of RL algorithms include Markov decision processes, Markov chains, Q-learning, multi-arm bandit learning, and deep RL.

[0316] One example is the use of ML / AI techniques for object tracking. Object tracking and / or computer vision techniques may include, for example, edge detection, corner detection, blob detection, Kalman filters, Gaussian mixture models, particle filters, mean-shift-based kernel tracking, ML object detection techniques (e.g., Viola-Jones object detection framework, scale-invariant feature transformation (SIFT), oriented gradient histogram (HOG), etc.), and deep learning object detection techniques (e.g., fully convolutional neural networks (FCNN), region-proposed convolutional neural networks (R-CNN), single-shot multi-box detectors, YOLO (you only look once) algorithm, etc.).

[0317] In another example, ML / AI technology is used for motion detection based on sensor data acquired from one or more sensors. In addition, or as an alternative, ML / AI technology is used for object detection and / or classification. An object detection or recognition model may include a registration phase and an evaluation phase. During the registration phase, one or more features are extracted from sensor data (e.g., image or video data). Features are individual measurable properties or characteristics. In the context of object detection, object features may include the size, color, shape, relationship to other objects, and / or any area or portion of an image such as edges, bumps, corners, blobs, and / or several defined regions of interest (ROIs). The features used may be implementation-specific and may be based, for example, on the object to be detected and the model to be formulated and / or used. The evaluation phase involves identifying or classifying objects by comparing the acquired image data with an existing object model created during the registration phase. During the evaluation phase, features extracted from the image data are compared with an object recognition model using appropriate pattern recognition techniques. The object model may be a qualitative or functional description, geometric surface information, and / or abstract feature vectors, and may be stored in a suitable database organized using some type of indexing scheme to facilitate the exclusion of unlikely object candidates from consideration.

[0318] Any suitable data fusion or data integration technique may be used to generate composite information. For example, the data fusion technique may be a direct fusion technique or an indirect fusion technique. Direct fusion combines data acquired directly from multiple vUEs or sensors, which may be the same or similar (e.g., all vUEs or sensors perform the same type of measurement) or different (e.g., different vUEs or sensor types, historical data, etc.). Indirect fusion leverages historical data and / or known properties of the environment and / or human input to generate a high-accuracy dataset. In addition, the data fusion technique may include one or more fusion algorithms such as a smoothing algorithm (e.g., estimating a value using multiple measurements in real time or non-real time), a filtering algorithm (e.g., estimating the state of an entity using current and historical measurements in real time), and / or a predictive state estimation algorithm (e.g., analyzing historical data (e.g., geographic location, speed, direction, and signal measurements) in real time to predict a state (e.g., future signal strength / quality at a specific geographic location coordinate)). For example, data fusion algorithms may or may include structured-based algorithms (e.g., tree-based (e.g., minimal spanning tree (MST)), cluster-based, grid, and / or centripetal-based), unstructured data fusion algorithms, Kalman filter algorithms and / or extended Kalman filtering, fuzzy-based data fusion algorithms, Ant Colony Optimization (ACO) algorithms, fault detection algorithms, Dempster-Shafer (DS) argumentation-based algorithms, Gaussian mixture model algorithms, triangulation-based fusion algorithms, and / or any other similar data fusion algorithms.

[0319] Local perception functions (which may or may not include trajectory prediction applications) 602, 702, 802 are provided by local processing of information collected by local sensors associated with system elements. Local perception (and trajectory prediction) functions 602, 702, 802 consume the output of sensor data fusion applications / functions 604, 704, 804 and supply perception data (and / or trajectory prediction) to ITS-S applications. Local perception (and trajectory prediction) functions 602, 702, 802 detect and characterize objects (stationary and moving) that are likely to cross the trajectory of the moving object under consideration. Infrastructure, particularly road infrastructure 800, may provide services related to VRU support services. The infrastructure has its own sensors to detect the progress of VRUs 116 / 117 and directly or through its own sensors to collaborative perception support services such as CPS (e.g., ETSI TR 103 If the approach of local vehicles is also detected remotely via (see 562), the risk of collision can then be calculated. In addition, since VRU116 / 117s must normally adhere to road markings / signs, road markings (e.g., crossing areas and pedestrian crossings) and vertical signs may also be considered to increase the level of confidence associated with VRU detection and mobility.

[0320] The kinematics prediction functions 603, 703, and the moving object trajectory prediction (at the RSU level) 803 relate to predicting the behavior of the moving object under consideration. The kinematics prediction functions 603 and 703 predict the trajectories of the vehicle 110 and the VRU 116, respectively. The kinematics prediction function 603 may be part of the VRU trajectory and behavior modeling module and the trajectory blockade module of the V-ITS-S110. The kinematics prediction function 703 may be part of the dead reckoning module and / or motion detection module of the VRU ITS-S117. Alternatively, the kinematics prediction functions 603 and 703 may provide motion / movement predictions to the aforementioned modules. In addition, or alternatively, the moving object trajectory prediction 803 predicts the trajectories of the corresponding vehicles 110 and VRU 116, respectively, and these trajectory predictions can be used with VRU trajectory and behavior modeling entities to assist VRU ITS-S117 in performing dead reckoning and / or to assist V-ITS-S110.

[0321] The kinematic prediction includes the moving object trajectory resulting from the progression of a continuous moving position. Changes in the moving object trajectory or moving object velocity (acceleration / deceleration) affect the kinematic prediction. In most cases, when VRU116 / 117 is moving, it still has a large number of possible kinematics with respect to possible trajectories and velocities. This means that kinematic predictions 603, 703, and 803 are used to identify which kinematics will be selected by VRU116 as quickly as possible and whether this selected kinematics is subject to the risk of collision with another VRU or vehicle.

[0322] The kinematics prediction functions 603, 703, and 803 analyze the progression of moving objects and potential intersecting trajectories at a given time to determine the risk of collision between them. The kinematics predictions act on the output of a collaborative perception function that considers the current trajectory of a device (e.g., VRU device 117) for calculating path prediction, the current velocities and past progressions of the moving objects under consideration for calculating velocity progression prediction, and confidence levels that can be associated with these variables. The output of this function is provided to the risk analysis function (see, for example, Figure 2).

[0323] In many cases, acting solely on the output of collaborative perception is insufficient to make reliable predictions due to the uncertainty regarding VRU trajectory selection and velocity. However, complementary functions can help consistently improve the reliability of predictions. For example, the use of a navigation system in a device (e.g., VRU device 117) that assists the user (e.g., VRU 116) in selecting the best trajectory to reach its planned destination. With the development of Mobility as a Service (MaaS), multimodal journey calculations can also assist in indicating hazard areas to VRU 116 and then in providing kinematic predictions at the multimodal journey level offered by the system. In another example, knowledge of the user's (e.g., VRU 116) habits and behaviors may be used additionally or alternatively to improve the consistency and reliability of motion predictions. Some users (e.g., VRU 116 / 117) follow the same journey using similar kinematics when going to major points of interest (POIs) related to the user's main activity (e.g., going to school, work, shopping, going to the nearest public transport station from home, going to a sports center, etc.). A device (e.g., VRU device 117) or a remote service center may learn and remember these habits. Another example is the user's (e.g., VRU 116) instruction of the selected trajectory, particularly when changing the selected trajectory (e.g., using a right-turn or left-turn signal similar to that of a vehicle when instructing a change of direction).

[0324] Vehicle motion control 608 may be included in the computer-assisted vehicle and / or automated vehicle 110. Both the HMI entity 606 and the vehicle motion control entity 608 may be triggered by one or more ITS-S applications. The vehicle motion control entity 608 may be a function under the responsibility of a human driver, or, if the vehicle can be driven in automated mode, under the responsibility of the vehicle itself.

[0325] Human-machine interfaces (HMIs) 606, 706, and 806, if present, enable the configuration of initial data (parameters) in management entities (e.g., VRU profile management) and other functions (e.g., VBS management). HMIs 606, 706, and 806 enable communication of external events related to VBS to the device owner (user), which includes alerting about immediate collision risks (TTC < 2 seconds) detected by at least one element of the system, and alerting about collision risks (e.g., TTC > 2 seconds) detected by at least one element of the system. In the case of a VRU system 117 similar to a vehicle driver (e.g., personal computing system 700), the HMI provides information to the VRU 116, taking its profile into consideration (e.g., in the case of a blind person, the information is presented at a clear voice level using the accessibility capabilities of the specific platform of the personal computing system 700). In various implementations, HMIs 606, 706, and 806 may be part of an alarm system.

[0326] Connected systems 607, 707, and 807 refer to components / devices used to connect a system to one or more other systems. For example, connected systems 607, 707, and 807 may include communication circuits and / or wireless units. A VRU system 700 may be a connected system consisting of up to four different levels of equipment. A VRU system 700 may also be an information system that collects information from events in real time, processes the collected information, and stores it along with the processed results. At each level of the VRU system 700, the collection, processing, and storage of information are related to the functions and data delivery scenarios implemented.

[0327] 5. Computer-assisted and autonomous driving platforms and technologies Apart from the UVCS technology of this disclosure, the in-vehicle system 101 and CA / AD vehicle 110 may be any one of several in-vehicle systems and CA / AD vehicles, ranging from computer-assisted vehicles to partially or fully autonomous vehicles. In addition, the in-vehicle system 101 and CA / AD vehicle 110 may include other components / subsystems not shown in Figure 1, such as elements illustrated and described elsewhere in this specification (see, for example, Figure 12). Other embodiments of the underlying UVCS technology used to implement the in-vehicle system 101 will be further described with reference to the remaining Figures 9 to 11.

[0328] Figure 9 shows the UVCS interface 900. The UVCS interface 900 is a modular system interface designed to connect pluggable computing modules (having computing elements such as CPU, memory, storage, and radio) to a pre-installed on-board computing hub or subsystem (having peripheral components such as power supply, management, I / O devices, automotive interfaces, and thermal solutions) in a vehicle, in order to form an instance of UVCS for a vehicle. Different pluggable computing modules having different computing elements, or computing elements with different functions or capabilities, can be used to mate with the pre-installed on-board computing hub / subsystem in the vehicle, thereby forming different instances of UVCS. Therefore, the computing power of a vehicle with a pre-installed on-board computing hub / subsystem can be upgraded by mating newer, more functional, or more capable pluggable computing modules with the pre-installed on-board computing hub / subsystem, replacing older, less functional, or less capable pluggable computing modules.

[0329] In the example in Figure 9, the UVCS900 includes a fixed section 902 and a configurable section 904. The fixed section 902 includes a dynamic power input interface 912 (also called a dynamic power supply interface) and a management channel interface 914. The configurable section 904 includes several configurable I / O (CIO) blocks 916a to 916n.

[0330] The dynamic power input interface 912 is configured to supply power from the in-vehicle computing hub / subsystem to the computing elements of a pluggable computing module that is plugged into the UVCS interface 900 to mate with the in-vehicle computing hub and form an instance of UVCS. The management channel interface 914 is configured to facilitate the in-vehicle computing hub managing / coordinating the operation of the management channel interface 914 itself and the pluggable computing module plugged into the UVCS interface 900 to form an instance of UVCS. CIO blocks 916a to 916n are configured to facilitate various I / O between the various computing elements of the pluggable computing module and the peripheral components of the in-vehicle computing hub / subsystem that are mated to each other via the UVCS interface 900 to form an instance of UVCS. The I / O between the computing elements of the pluggable computing module and the mated peripheral components of the in-vehicle computing hub / subsystem differs from instance to instance, depending on the computing elements of the pluggable computing module used to mate with the in-vehicle computing hub and form a particular instance of UVCS. At least a portion of the CIO blocks 916a to 916a are arranged to facilitate high-speed interfaces.

[0331] CIO blocks 916a to 916n represent a set of electrically similar high-speed differential serial interfaces, allowing for case-by-case configurations of the interface types and standards actually used. In this way, different UVCS computing hubs can connect different peripherals to the same UVCS interface 900, enabling different peripherals to perform I / O operations with different I / O protocols using the computing elements of the UVCS module.

[0332] The number of CIO blocks 916a–916n may vary depending on the specific use case and / or for different market segments. For example, there may be fewer CIO blocks 916a–916n (e.g., 2–4) for implementations designed for low-cost markets. On the other hand, there may be more CIO blocks 916–916n (e.g., 8–16) for implementations designed for high-cost markets. However, to achieve the best possible interoperability and upgradeability, the number and functionality / configurability of CIO blocks may be kept the same for a given UVCS generation.

[0333] Figure 10 shows an exemplary UVCS1000 formed using a UVCS interface. As shown, the UVCS interface may also be a UVCS interface 900 and is used to facilitate mating between a pluggable UVCS module and a pre-installed UVCS hub in a vehicle to form a UVCS1000 for a vehicle, which may be one of the one or more UVCSs of the in-vehicle system 101 in Figure 1. The UVCS interface, as UVCS interface 900, includes a fixed section and a configurable section. The fixed section includes a dynamic power supply interface (DynPD) 1032 and a management channel (MGMT) interface 1034. The configurable section includes several configurable I / O interfaces (CIOs), PCIe1..x, CIO1..x, CIOy..z, CIOa..b, CIOc..d.

[0334] A pre-configured UVCS hub includes a power supply and a system management controller. Furthermore, the UVCS hub includes a debug interface 1044, an interface device, a level shifter, a power supply as shown in the figure, a system management controller, and several peripheral components 1052 coupled to each other, such as audio and amplifiers, a camera interface, a car network interface, other interfaces, a display interface, a customer-facing interface (e.g., a USB interface), and a communication interface (e.g., Bluetooth® BLE, WiFi, other mobile interfaces, a tuner, a software-defined radio (SDR)). In addition, or alternatively, the UVCS hub may include more, fewer, or different peripheral components.

[0335] The pluggable UVCS module 1006 includes an SoC (e.g., CPU, GPU, FPGA, or other circuitry), memory, power input and supply circuitry, a housekeeping controller, and a CIO multiplexer (MUX). Furthermore, the UVCS module includes hardware accelerators, persistent mass storage, and communication modules (e.g., BT, WiFi, 5G / NR, LTE, and / or other similar interfaces), coupled with the elements listed above as shown in the illustration. In addition, or alternatively, the UVCS module may include more, fewer, or different computing elements.

[0336] The UVCS hub's power supply provides power to the UVCS module's compute elements via the UVCS interface's DynPD1032 and the UVCS module's power input + supply circuit. The UVCS hub's system management controller manages and coordinates its operation and the operation of the UVCS module's compute elements via the UVCS interface's management channel 1034 and the UVCS module's housekeeping controller. The CIO MUX is configurable or operable to provide multiple I / O channels of different I / O protocols between the UVCS module's compute elements and the UVCS hub's peripheral components via the configurable I / O blocks of the UVCS interface, the UVCS hub's interface devices, and level shifters. For example, one of the I / O channels may provide I / O between the UVCS module's compute elements and the UVCS hub's peripheral components according to the PCIe I / O protocol. Another I / O channel may provide I / O between the UVCS module's compute elements and the UVCS hub's peripheral components according to the USB I / O protocol. Furthermore, other I / O channels provide I / O between the computing elements of the UVCS module and the peripheral components of the UVCS hub, according to other high-speed serial or parallel I / O protocols.

[0337] The housekeeping controller can be configured or operated to control power supply to static and dynamic loads, as well as power consumption by static and dynamic loads, based on the vehicle's operating context (e.g., whether the vehicle is in a "cold crank" scenario or a "cold start" scenario). The housekeeping controller can be configured or operated to control power consumption of static and dynamic loads by selectively initiating sleep states, reducing clock frequencies, or turning off power to static and dynamic loads.

[0338] The management channel 1034 may be a small, low-pin serial interface, a general-purpose asynchronous transceiver (UART) interface, a general-purpose synchronous asynchronous transceiver (USART) interface, a USB interface, or any other suitable interface (including any of the other IX technologies discussed herein). In addition, or alternatively, the management channel may be a parallel interface such as an IEEE 1284 interface.

[0339] The CIO blocks of the UVCS interface represent a set of electrically similar high-speed interfaces (e.g., high-speed differential serial interfaces) that allow for case-by-case configuration of the interface types and standards actually used. In particular, the housekeeping controller is arranged to configure the CIO MUX to provide multiple I / O channels via various CIO blocks to facilitate I / O operation in different I / O protocols. In addition, or alternatively, the multiple I / O channels include USB I / O channels, PCIe I / O channels, HDMI® and DP (DDI) I / O channels, as well as Thunderbolt (TBT) I / O channels. The multiple I / O channels may also include other I / O channel types (xyz[1..r]) other than those enumerated.

[0340] In addition, or alternatively, the CIO multiplexer has sufficient circuit paths that can be configured to multiplex any given combination of I / O interfaces indicated by the SoC to the connected CIO block. In addition, or alternatively, the CIO MUX may support limited multiplexing schemes, such as when the CIO block supports a limited number of I / O protocols (e.g., it supports display interfaces and Thunderbolt, but does not provide PCIe support). In some implementations, the CIO MUX may be integrated as part of the SoC.

[0341] The system management controller of the UVCS hub and the housekeeping controller of the UVCS module can be configured or operated to negotiate a power budget or power contract during the initial pairing of the UVCS hub and UVCS module. In addition, or alternatively, the power budget / contract may provide minimum and maximum voltages, current / power requirements of the UVCS module, and current power supply limits of the UVCS interface, if any. This allows for the evaluation of compatibility and operational benefits of given pairs of UCS hubs and modules.

[0342] Figure 11 shows a diagram of the software components of an exemplary in-vehicle system formed with UVCS. As shown, the in-vehicle system 1100 can be formed with UVCS 1000 and includes hardware 1102 and software 1110. The software 1110 includes a hypervisor 1112 that hosts several virtual machines (VMs) 1122-1128. The hypervisor 1112 is configurable or operable to host the execution of VMs 1122-1128. The hypervisor 1112 may also implement some or all of the functions described above for the system management controller of the UVCS module. For example, the hypervisor 1112 may be the KVM hypervisor provided by Citrix Inc., Xen, VMWare provided by VMware Inc., and / or any other suitable hypervisor or VM manager (VMM) technology as discussed herein. VMs 1122-1128 include a service VM 1122 and several user VMs 1124-1128. The service machine 1122 includes a service OS that hosts the execution of several instrument cluster applications 1132. For example, the service OS of service VM 1122 and the user OS of user VMs 1124-1128 may be, for example, Linux® available from Red Hat Enterprise in Raleigh, North Carolina, Android® available from Google® in Mountain View, California, and / or any other suitable OS as discussed herein.

[0343] User VMs 1124-1128 may include a first user VM 1124 having a first user OS hosting the execution of the front-seat infotainment application 1134, a second user VM 1126 having a second user OS hosting the execution of the rear-seat infotainment application 1136, a third user VM 1128 having a third user OS hosting the execution of the ITS-S subsystem 1150, and / or any other suitable OS / applications as discussed herein. In some implementations, VMs 1122-1126 may be or include isolated user-space instances such as containers, partitions, or virtual environments (VEs), and these user-space instances may be implemented using appropriate OS-level virtualization techniques.

[0344] 6. Computing System and Hardware Configuration Figure 12 shows an exemplary edge computing system and environment that can realize any of the compute nodes or devices discussed herein. The edge compute node 1250 may be embodied as one of the devices, appliances, computers, or other “things” that can communicate with other edge components, networking components, or endpoint components. For example, the edge compute device 1250 may be embodied as a smartphone, a mobile compute device, a smart appliance, an in-vehicle compute system (e.g., a navigation system), or any other device or system that can perform the functions described.

[0345] Figure 12 shows an example of components that may be present in an edge computing node 1250 for implementing the technologies described herein (e.g., operations, processes, methods, and methodologies). This edge computing node 1250 provides a more detailed diagram of each component of node 1250 when implemented as or as part of a computing device (e.g., a mobile device, base station, server, gateway, infrastructure equipment, roadside unit (RSU) or R-ITS-S130, radio head, relay station, server, and / or any other element / device discussed herein). The edge computing node 1250 may include any combination of the hardware or logical components referenced herein and may include or be coupled with any device available in an edge communication network or a combination of such networks. The components may be implemented as ICs, parts of ICs, discrete electronic devices, or other modules, instruction sets, programmable logic or algorithms, hardware, hardware accelerators, software, firmware, or combinations thereof adapted to the edge computing node 1250, or as components otherwise integrated into the chassis of a larger system.

[0346] The edge computing node 1250 includes processing circuitry in the form of one or more processors 1252. The processor circuitry 1252 includes one or more processor cores, as well as cache memory, low dropout voltage regulators (LDOs), interrupt controllers, SPI and I 2The processor circuit 1252 may include, but is not limited to, one or more of the following: serial interfaces such as C or Universal Programmable Serial Interface circuits, real-time clocks (RTCs), timer counters including interval timers and watchdog timers, general-purpose I / O, memory card controllers such as Secure Digital / Multimedia Cards (SD / MMC), interfaces, MIPI (Mobile Industry Processor Interface) interfaces, and JTAG (Joint Test Access Group) test access ports. In some implementations, the processor circuit 1252 may include one or more hardware accelerators (e.g., the same as or similar to accelerator circuit 1264), which may be microprocessors, programmable processing devices (e.g., FPGAs, ASICs, etc.). One or more accelerators may include, for example, computer vision accelerators and / or deep learning accelerators. In some implementations, the processor circuit 1252 may include an on-chip memory circuit, which may include any suitable volatile and / or non-volatile memory such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology discussed herein.

[0347] The processor circuit 1252 may include, for example, one or more processor cores (CPUs), application processors, GPUs, RISC processors, Acorn RISC Machine (ARM) processors, CISC processors, one or more DSPs, one or more FPGAs, one or more PLDs, one or more ASICs, one or more baseband processors, one or more radio frequency integrated circuits (RFICs), one or more microprocessors or controllers, multicore processors, multithreaded processors, ultra-low voltage processors, embedded processors, or any other known processing elements, or any suitable combination thereof. The processor (or core) 1252 may be coupled with or include memory / storage and may be configured to execute instructions stored in memory / storage to enable various applications or operating systems to run on node 1250. The processor (or core) 1252 is configured to run application software to provide specific services to users of node 1250. In addition, or alternatively, the processor 1252 may be a dedicated processor / controller configured (or configurable) to operate in accordance with the considerations in Sections 1-4 above.

[0348] The processor 1252 can communicate with system memory 1254 over interconnect (IX) 1256. Any number of memory devices can be used to provide a given amount of system memory. For example, the memory may be random access memory (RAM) designed by the Electronics Technology Council of Japan (JEDEC), such as DDR standards or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In a particular example, the memory components may conform to DRAM standards published by JEDEC, such as JESD79F for DDR SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, JESD79-4A for DDR4 SDRAM, JESD209 for low-power DDR (LPDDR), JESD209-2 for LPDDR2, JESD209-3 for LPDDR3, and JESD209-4 for LPDDR4. Other types of RAM may also be included, such as Dynamic RAM (DRAM) and Synchronous DRAM (SDRAM). Such standards (and similar standards) are sometimes called DDR-based standards, and the communication interface of a memory device implementing such a standard may be called a DDR-based interface. In various implementations, individual memory devices may be of any number of different package types, such as single-die packages (SDP), dual-die packages (DDP), and quad-die packages (Q17P). In some examples, these devices may be soldered directly onto the motherboard to provide a low-profile solution, while in other examples, the devices are configured as one or more memory modules coupled to the motherboard by a given connector. Any number of other memory implementations may be used, such as other types of memory modules, including but not limited to different types of dual in-line memory modules (DIMMs), including microDIMM or MiniDIMM.

[0349] To provide persistent storage for information such as data, applications, and operating systems, storage 1258 may also be coupled to processor 1252 via IX 1256. In one example, storage 1258 may be implemented via a solid-state disk drive (SSDD) and / or high-speed electrically erasable memory (commonly referred to as “flash memory”). Other devices that may be used for storage 1258 include flash memory cards such as SD cards, microSD cards, and XD-Picture Cards, and USB flash drives. For example, the memory device may be a memory device using chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single or multi-level phase-change memory (PCM), resistive memory, nanowire memory, ferroelectric transistor random-access memory (FeTRAM), antiferroelectric memory, magnetoresistive random-access memory (MRAM) memory incorporating memristor technology, phase-change RAM (PRAM), resistive memory including metal oxide-based, oxygen-vacancy-based and conductive bridge random-access memory (CB-RAM), or spin-transfer torque (STT)-MRAM, spintronic magnetic junction memory-based devices, magnetic tunneling junction (MTJ)-based devices, domain wall (DW) and spin-orbit transfer (SOT)-based devices, thyristor-based memory devices, or any combination of the above, or other memories, or may include them. Memory circuit 1254 and / or storage circuit 1258 may also incorporate three-dimensional (3D) crosspoint (XPOINT) memory from Intel® and Micron®.

[0350] In low-power implementations, storage 1258 may be on-die memory or registers associated with processor 1252. However, in some examples, storage 1258 may be implemented using a micro hard disk drive (HDD). Furthermore, in addition to or instead of the techniques described, any number of new techniques, particularly resistive random-access memory, phase-change memory, holographic memory, or chemical memory, may be used for storage 1258.

[0351] Memory circuit 1258 stores computation logic 1282 (or “module 1282”) in the form of software, firmware, or hardware commands to implement the techniques described herein. Computation logic 1282 may be used to store working copies and / or persistent copies of computer programs, or data for creating computer programs for the operation of various components of node 1250 (e.g., drivers), the OS of node 1250, and / or one or more applications for performing the functions discussed herein. Computation logic 1282 may be stored or loaded into memory circuit 1254 as data for creating instruction 1282 or instruction 1288 for execution by processor circuit 1252 to provide the functions described herein. Various elements may be implemented by assembler instructions supported by processor circuit 1252, or by a high-level language that can be compiled into such instructions (e.g., instruction 1288, or data for creating instruction 1288). A persistent copy of the programming instructions may be placed in the persistent storage device of the memory circuit 1258 at the factory, or, for example, via a distribution medium (not shown), via a communication interface (e.g., from a distribution server (not shown)), or over-the-air (OTA) at the site.

[0352] In one example, instructions 1283, 1282 provided via memory circuit 1254 and / or storage circuit 1258 in Figure 12 are embodied as one or more non-temporary computer-readable storage media (see, for example, NTCRSM1260) containing program code, computer program products, or data for creating computer programs, to instruct the processor circuit 1252 of node 1250 to perform electronic operations and / or specific sequences or flows of operations in node 1250, using computer programs or data, as described with respect to the operation and function flowcharts and block diagrams illustrated earlier. The processor circuit 1252 accesses one or more non-temporary computer-readable storage media on interconnect 1256.

[0353] In addition, or alternatively, programming instructions (or data for creating instructions) may be located on multiple NTCRSM1260s. In addition, or alternatively, programming instructions (or data for creating instructions) may be located on a computer-readable temporary storage medium such as a signal. Instructions embodied in a machine-readable medium may be further transmitted or received over a communication network using a transmission medium via a network interface device utilizing one of several transfer protocols (e.g., HTTP). Any combination of one or more computer-usable or computer-readable media may be used. Computer-usable or computer-readable media may be, for example, one or more electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or propagation media. For example, NTCRSM1260 may be embodied by the devices described for memory circuit 1258 and / or memory circuit 1254. More specific examples (a non-exclusive list) of computer-readable media include electrical connections with one or more wires, portable computer diskettes, hard disks, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM, flash memory, etc.), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices and / or optical discs, transmission media such as those supporting the internet or intranets, magnetic storage devices, or any number of other hardware devices.It should be noted that a computer-usable medium or computer-readable medium can also be paper or another suitable medium on which the program (or data for creating the program) is printed, for example, by optical scanning of paper or other medium (whether or not it is stored in one or more intermediate storage media), and then compiled, interpreted, or otherwise processed in an appropriate manner as needed, and then stored in computer memory. In the context of this specification, a computer-usable medium or computer-readable medium can be any medium on which a program (or data for creating the program) can be contained, stored, communicated, propagated, or carried for use by or in connection with an instruction execution system, apparatus, or device. A computer-usable medium may include propagated data signals on which computer-usable program code (or data for creating the program code) is embodied, either in baseband or as part of a carrier wave. Computer-usable program code (or data for creating the program) can be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, etc.

[0354] The program code (or data for creating program code) described herein may be stored in one or more of the following formats: compressed format, encrypted format, fragmented format, packaged format, etc. The program code (or data for creating program code) described herein may require one or more of the following processes to make them directly readable and / or executable by computing devices and / or other machines: installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reallocation, etc. For example, the program code (or data for creating program code) may be stored as multiple parts, each individually compressed and encrypted, stored on separate computing devices, which, when decrypted, decompressed, and combined, form a set of executable instructions that implement the program code (data for creating program code as described herein). In another example, the program code (or data for creating program code) may be stored in a state where it can be read by a computer, but requires additional libraries (e.g., dynamic link libraries), software development kits (SDKs), application programming interfaces (APIs), etc., to execute the instructions on a particular computing device or other device. In another example, program code (or data for creating program code) may need to be configured (e.g., storing settings, inputting data, recording network addresses, etc.) before it can be executed / used as a whole or in part. In this example, the program code (or data for creating program code) may be unpacked, configured for proper execution, and stored in a first location, along with configuration instructions located in a second location different from the first location. The configuration instructions may be initiated by an action, trigger, or instruction that is not located in the same storage or execution location as the instructions enabling the technique of disclosure.Therefore, the program code (or data for creating the program code) of the disclosure is intended to encompass such machine-readable instructions and / or programs (or data for creating such machine-readable instructions and / or programs), regardless of the specific format or state of the machine-readable instructions and / or programs when they are stored, or otherwise stationary or in transmission.

[0355] Computer program code for performing the operations of this disclosure (e.g., computation logic 1283, instruction 1282, instruction 1281 above) may be object-oriented programming languages ​​such as Python, Ruby, Scala, Smalltalk®, Java®, C++, C#, procedural programming languages ​​such as the C programming language, Go (or "Golang") programming language, JavaScript®, Server-Side JavaScript (SSJS), jQuery, PHP, Pearl, Python, Ruby on Rails, Accelerated Mobile Pages Script (AMPscript), Mustache Template Language, Handlebars Template Language, Guide Template Language (GTL), PHP, Java and / or Java Server Page (JSP), Node.js, ASP.NET, JAMscript, and other scripting languages, as well as hypertext markup languages ​​(HTML), extended markup languages ​​(XML), JavaScript Object Notion (JSON), Apex®, Cascading Stylesheets (CSS), and JavaServer. The code may be written in any combination of one or more programming languages, including markup languages ​​such as Page (JSP), MessagePack (trademark), Apache (registered trademark) Thrift, Abstract Syntax Notation One (ASN.1), Google (registered trademark) Protocol Buffers (protobuf), proprietary programming languages ​​and / or development tools, or several other suitable programming languages, including any other language tools. Computer program code for performing the operations of the disclosure may also be written in any combination of the programming languages ​​discussed herein.The program code can run entirely on system 1250, partially on system 1250, as a standalone software package, partially on system 1250 and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to system 1250 via any type of network, including a LAN or WAN, or the connection may be made to an external computer (for example, via the Internet using an Internet service provider).

[0356] For example, instruction 1281 on processor circuit 1252 (separately or in combination with instruction 1282 and / or logic / module 1283 stored in a computer-readable storage medium) may constitute the execution or operation of a trusted execution environment (TEE) 1290. The TEE 1290 operates as a protected area accessible to the processor circuit 1252 to enable secure access to data and secure execution of instructions.

[0357] The TEE1290 may be a separate physical hardware device from other components of the System 1250, such as a secure embedded controller, a dedicated SoC, or a tamper-resistant chipset or microcontroller incorporating processing and memory devices.

[0358] The TEE1290 may be implemented as a secure enclave, which is an isolated area of ​​code and / or data within the processor and / or memory / storage circuitry of system 1250. Only code running within the secure enclave can access data within the same secure enclave, and the secure enclave may only be accessible using a secure application (which may be implemented by an application processor or a tamper-resistant microcontroller). Various implementations of the TEE1290, as well as accompanying secure areas within the processor circuitry 1252 or the memory circuitry 1254 and / or storage circuitry 1258, may be provided. Enhanced security, hardware root of trust, and other aspects of trusted or protected operation may be implemented in device 1250 via the TEE1290 and processor circuitry 1252.

[0359] In addition, or alternatively, the memory circuit 1254 and / or the storage circuit 1258 may be divided into isolated user-space instances such as containers, partitions, or virtual environments (VEs). These isolated user-space instances can be implemented using appropriate OS-level virtualization techniques such as containers, zones, virtual private servers, virtual kernels and / or jails, or chroot jails. In some implementations, virtual machines may also be used. In addition, or alternatively, the memory circuit 1254 and / or the storage circuit 1258 may be divided into one or more trusted memory regions for storing applications or software modules of the TEE1290.

[0360] Instruction 1282 is shown as a code block contained in memory circuit 1254, and computation logic 1283 is shown as a code block in memory circuit 1258, but it should be understood that either of the code blocks may be replaced by hardwired circuitry incorporated into, for example, an FPGA, ASIC, or some other suitable circuit. For example, if processor circuit 1252 includes a hardware accelerator (e.g., FPGA-based) and a processor core, the hardware accelerator (e.g., an FPGA cell) may be pre-configured with the computation logic described above (e.g., using a suitable bitstream) to perform some or all of the aforementioned functions (instead of using programming instructions that would be executed by the processor core).

[0361] The memory circuit 1254 and / or the storage circuit 1258 may store program code for an operating system (OS), which may be a general-purpose OS or an OS specifically written and tuned for the computing node 1250. For example, the OS may be any other suitable OS, such as a desktop OS, a netbook OS, a vehicle OS, a mobile OS, a real-time OS (RTOS), and / or any other OS discussed herein.

[0362] The OS may include one or more drivers that operate to control specific devices that are built into, attached to, or otherwise communicatively coupled to node 1250. The drivers may include separate drivers that enable other components of node 1250 to interact with or control various I / O devices that may reside within node 1250 or be connected to the node. For example, the drivers may include a display driver for controlling and allowing access to a display device, a touchscreen driver for controlling and allowing access to the touchscreen interface of node 1250, a sensor driver for obtaining sensor readings from sensor circuit 1272 and controlling and allowing access to sensor circuit 1272, an actuator driver for obtaining the actuator position of actuator 1274 and / or controlling and allowing access to actuator 1274, a camera driver for controlling and allowing access to an embedded imaging device, and an audio driver for controlling and allowing access to one or more audio devices. The OS may also include one or more libraries, drivers, APIs, firmware, middleware, software glue, etc., which provide program code and / or software components for one or more applications to retrieve and use data from a secure execution environment, a trusted execution environment, and / or a management engine of node 1250 (not shown).

[0363] The components of the edge computing device 1250 can communicate on the IX1256. The IX1256 may include any number of bus and / or interconnect (IX) technologies, such as Industry Standard Architecture (ISA), Extended ISA (EISA), Inter-Integrated Circuits (I2C), Serial Peripheral Interface (SPI), Point-to-Point Interface, Power Management Bus (PMBus), Peripheral Interconnect (PCI), PCI Express (PCIe), Ultra Path Interface (UPI), Accelerator Link (IAL), Common Application Programming Interface (CAPI), QuickPath Interconnect (QPI), Ultra Path Interconnect (UPI), OmniPath Architecture (OPA) IX, RapidIO System IX, Cache Coherent Interconnect for Accelerators (CCIA), Gen-z Consortium IX, Open Coherent Accelerator Processor Interface (OpenCAPI) IX, HyperTransport Interconnect, and / or any number of other IX technologies. An IX technology may, for example, be a dedicated bus used in SoC-based systems.

[0364] IX1256 connects the processor 1252 to a communication circuit 1266 for communication with a remote server (not shown) and / or other devices such as a connected edge device 1262. The communication circuit 1266 is a hardware element or set of hardware elements used to communicate over one or more networks (e.g., a cloud 1263) and / or other devices (e.g., an edge device 1262). The modem circuit 126Z can convert data for wireless transmission using one or more radios 126X, 126Y, and can convert received signals from radios 126X, 126Y into digital signals / data for consumption by other elements of the system 1250.

[0365] The transceiver 1266 may use any number of frequencies and protocols, including 2.4 gigahertz (GHz) transmission under the IEEE 802.15.4 standard, particularly using the Bluetooth® Low Energy (BLE) standard or the ZigBee® standard as defined by the Bluetooth® Special Interest Group. Any number of radios 126X, 126Y (or "RAT circuits 126X, 126Y") configured for specific wireless communication protocols may be used to connect to the connected edge device 1262. For example, a wireless local area network (WLAN) circuit 126X may be used to implement WiFi® communication in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. In addition, wireless wide-area communication (e.g., cellular or other wireless wide-area protocols) may also be performed via a wireless wide-area network (WWAN) circuit 126Y.

[0366] A wireless network transceiver 1266 (or multiple transceivers) may communicate using multiple standards or radios to communicate at different ranges. For example, an edge computing node 1250 may communicate with nearby devices, for example, within about 10 meters, using a BLE-based local transceiver or another low-power radio to conserve power. A more distant connected edge device 1262, for example, within about 50 meters, may be reached via a ZigBee® or other intermediate-power radio. Both communication techniques may be performed with a single radio at different power levels, or with separate transceivers, for example, a local transceiver using BLE and separate mesh transceivers using ZigBee®.

[0367] A wireless network transceiver 1266 (e.g., a wireless transceiver) may be included to communicate with devices or services within the edge cloud 1263 via a local area network protocol or a wide area network protocol. The wireless network transceiver 1266 may, in particular, be an LPWA transceiver conforming to the IEEE 802.15.4 or IEEE 802.15.4g standard. The edge computing node 1263 may communicate over a wide area using LoRaWAN® (Long Range Wide Area Network), developed by Semtech and the LoRa Alliance. The technologies described herein are not limited to these technologies and may be used in conjunction with any number of other cloud transceivers that implement long-range, low-bandwidth communication, such as Sigfox, and other technologies. Furthermore, other communication technologies, such as time-slot channel hopping as described in the IEEE 802.15.4e specification, may be used.

[0368] As described herein, in addition to the system described for the wireless network transceiver 1266, any number of other wireless communications and protocols may be used. For example, transceiver 1266 may include a cellular transceiver that uses spread spectrum (SPA / SAS) communication to perform high-speed communication. Furthermore, any number of other protocols may be used, such as WiFi® networks for providing medium-speed and network communications. Transceiver 1266 may include radios 126X, 126Y that are compatible with any number of 3GPP specifications, such as LTE and 5G / NR communication systems, which will be discussed in more detail at the end of this disclosure. A network interface controller (NIC) 1268 may be included to provide wired communication to nodes of the edge cloud 1263 or other devices such as connected edge devices 1262 (e.g., operating in a mesh). Wired communication may provide an Ethernet connection, or may be based on other types of networks, particularly Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway Plus (DH+), PROFIBUS, or PROFINET. Additional NICs 1268 may be included to enable connectivity to a second network, for example, a first NIC 1268 providing communication to the cloud over Ethernet, and a second NIC 1268 providing communication to other devices over another type of network.

[0369] Considering various types of applicable communication from a device to another component or network, an applicable communication circuit used by the device may include or be embodied by one or more of components 1264, 1266, 1268, or 1270. Thus, in various examples, the means of applicable communication (e.g., receiving, transmitting) may be embodied by such a communication circuit.

[0370] The edge computing node 1250 may include or be coupled to an accelerator circuit 1264, which may be embodied by one or more AI accelerators, neural computing sticks, neuromorphic hardware, FPGAs, GPUs, one or more SoCs (including programmable SoCs), one or more CPUs, one or more digital signal processors, dedicated ASICs (including programmable ASICs), PLDs such as CPLDs and HCPLDs, and / or other forms of specialized processors or circuits designed to accomplish one or more specific tasks. These tasks may include AI processing (including machine learning, training, inference, and classification operations), visual data processing, network data processing, object detection, rule analysis, etc. In FPGA-based implementations, the accelerator circuit 1264 may comprise a logic block or logic fabric and other interconnected resources that can be programmed (configured) to perform various functions, such as procedures, methods, and functions as discussed in sections 1-4 above. In such an implementation, the accelerator circuit 1264 may also include memory cells (e.g., EPROM, EEPROM, flash memory, static memory (e.g., SRAM, antifuse, etc.)) used to store logic blocks, logic fabric, data, etc., in a LUT or the like.

[0371] The IX1256 also connects the processor 1252 to a sensor hub or external interface 1270 used to connect additional devices or subsystems. Additional / external devices may include a sensor 1272, an actuator 1274, and a positioning circuit 1245.

[0372] The sensor circuit 1272 includes a device, module, or subsystem intended to detect an event or change in its environment and transmit information about the detected event (sensor data) to some other device, module, subsystem, etc. Examples of such sensors 1272 include, in particular, an inertial measurement unit (IMU) having an accelerometer, gyroscope, and / or magnetometer; a micro-electromechanical system (MEMS) or nano-electromechanical system (NEMS) having a 3-axis accelerometer, 3-axis gyroscope, and / or magnetometer; a level sensor, a flow sensor, a temperature sensor (e.g., a thermistor); a pressure sensor, a barometric pressure sensor; a gravimeter; an altimeter; an imaging device (e.g., a camera); a LiDAR (Light detection and ranging) sensor; a proximity sensor (e.g., an infrared radiation detector); a depth sensor; an ambient light sensor; an optical sensor; an ultrasonic transceiver; a microphone; and the like.

[0373] In addition, or alternatively, some of the sensors 172 may be sensors used in various vehicle control systems, in particular an exhaust sensor including an exhaust oxygen sensor for acquiring oxygen data and a manifold absolute pressure (MAP) sensor for acquiring manifold pressure data, a mass airflow (MAF) sensor for acquiring intake airflow data, an intake air temperature (IAT) sensor for acquiring IAT data, an AAT sensor for acquiring ambient air temperature (AAT) data, an AAP sensor for acquiring ambient air pressure (AAP) data (e.g., tire pressure data), and a catalytic converter sensor including a catalytic converter temperature (CCT) sensor for acquiring catalytic converter temperature (CCT) data and a CCO sensor for acquiring catalytic converter oxygen (CCO) data. Sensor 172 may include, for example, a VSS for acquiring vehicle speed sensor (VSS) data, an EGR sensor including an EGR pressure sensor for acquiring exhaust gas recirculation (EGR) pressure data and an EGR position sensor for acquiring EGR valve pintle position / orientation data, a throttle position sensor (TPS) for acquiring throttle position / orientation / angle data, a crank / cam position sensor for acquiring crank / cam / piston position / orientation / angle data, a coolant temperature sensor, a drivetrain sensor for collecting drivetrain sensor data (e.g., transmission fluid level), and a body sensor for collecting body data (e.g., data associated with buckling of the front grille / fender, side doors, rear fender, rear trunk, etc.). Sensor 172 may also include other sensors such as an accelerator pedal position sensor (APP), an accelerometer, a magnetometer, a level sensor, a flow / fluid sensor, a barometric pressure sensor, and / or any other sensors as discussed herein. Sensor data from the vehicle's sensor 172 may include engine sensor data (e.g., engine temperature, oil pressure, etc.) collected by various engine sensors.

[0374] Actuator 1274 enables node 1250 to change its state, position, and / or orientation, or to move or control a mechanism or system. Actuator 1274 comprises electrical and / or mechanical devices for moving or controlling a mechanism or system, converting energy (e.g., electric current or moving air and / or liquid) into some kind of motion. Actuator 1274 may include one or more electronic (or electrochemical) devices such as piezoelectric bimorphs, solid actuators, solid relays (SSRs), shape memory alloy-based actuators, electroactive polymer-based actuators, and relay driver integrated circuits (ICs). Actuator 1274 may include one or more electromechanical devices such as pneumatic actuators, hydraulic actuators, electromechanical switches including electromechanical relays (EMRs), motors (e.g., DC motors, stepper motors, servo mechanisms, etc.), power switches, valve actuators, wheels, thrusters, propellers, claws, clamps, hooks, audible sound generators, visual warning devices, and / or other similar electromechanical components. Node 1250 may be configured to operate one or more actuators 1274 based on one or more captured events and / or commands or control signals received from a service provider and / or various client systems.

[0375] In addition, or alternatively, the actuator 1274 may be a driving control unit (e.g., DCU174 in Figure 1), and examples of DCU1274 include a drivetrain control unit, engine control unit (ECU), engine control module (ECM), EEMS, powertrain control module (PCM), transmission control module (TCM), brake control module (BCM) including anti-lock braking system (ABS) module and / or electronic stability control (ESC) system, central control module (CCM), central timing module (CTM), general electronic module (GEM), body control module (BCM), suspension control module (SCM), door control unit (DCU), speed control unit (SCU), human-machine interface (HMI) unit, telematics control unit (TTU), battery management system, portable emission measuring system (PEMS), evasive maneuver assistance (EMA) module / system, and / or any other entity or node in the vehicle system. Examples of CSDs that can be generated by the DCU174 may include, but are not limited to, real-time calculated engine load values ​​from the engine control module (ECM), such as the engine revolutions per minute (RPM) of the vehicle's engine; fuel injector timing data for one or more cylinders and / or one or more injectors of the engine; ignition spark timing data for one or more cylinders (e.g., instructions for spark events relative to the crank angle of one or more cylinders); gear ratio data and / or transmission status data (which may be supplied to the ECM by the transmission control unit (TCU)); and others.

[0376] In a vehicle implementation, the actuator / DCU1274 may be provisioned with a Control System Configuration (CSC), which is a collection of software modules, software components, logic blocks, parameters, calibrations, and modifications used to control and / or monitor various systems implemented by node 1250 (for example, if node 1250 is CA / AD vehicle 110). The CSC defines how the DCU1274 should interpret sensor data from sensor 1272 and / or the CSD of other DCU1274 using a multidimensional performance map or lookup table, and how the actuator / component should be adjusted / modified based on the sensor data. The CSC and / or software components to be executed by individual DCU1274 may be developed using any suitable object-oriented programming language (e.g., C, C++, Java, etc.), schema language (e.g., XML schema, AUTomotive Open System Architecture (AUTOSAR) XML schema, etc.), scripting language (VBScript, JavaScript, etc.), etc. The CSC and software components can be defined using hardware description languages ​​(HDL) such as Register Transfer Logic (RTL), Very High Speed ​​Integrated Circuit (VHSIC) HDL (VHDL), or Verilog for the DCU1274 implemented as a field-programmable device (FPD). The CSC and software components can be generated using a modeling environment or model-based development tools. In addition, or alternatively, the CSC may be generated or updated by one or more autonomous software agents and / or AI agents based on learned experience, ODD, and / or other similar parameters.

[0377] The IVS101 and / or DCU1274 can be configured or operated to operate one or more actuators based on one or more captured events (indicated by sensor data captured by sensor 1272) and / or commands or control signals received from user input, signals received wirelessly from a service provider, etc. In addition, one or more DCU1274 may be configured or operated to operate one or more actuators by transmitting commands or control signals to the actuators based on detected events (indicated by sensor data captured by sensor 1272). One or more DCU1274 can read or otherwise acquire sensor data from one or more sensors 1272, process the sensor data to generate control system data (or CSC), and provide the control system data to one or more actuators to control various systems of the vehicle 110. An embedded device / system acting as a central controller or hub may also access control system data for processing using appropriate drivers, APIs, ABIs, libraries, middleware, firmware, etc., and / or the DCU1274 may be configured or operable to provide control system data to the central hub and / or other devices / components periodically or aperiodicly and / or when triggered.

[0378] Various subsystems, including sensor 1272 and / or DCU 1274, may be operated and / or controlled by one or more AI agents. An AI agent is a configurable or operable autonomous entity that observes environmental conditions and determines actions to be taken to advance a specific objective. The specific environmental conditions to be observed and the actions to be taken may be based on an operational design domain (ODD). The ODD includes operating conditions under which a given AI agent or its characteristics are specifically designed to function. The ODD may include environmental, geographical, and temporal constraints, as well as operational constraints such as the presence or absence of specific traffic or road characteristics required.

[0379] Individual AI agents can be configured or operated to control each of the vehicle's control systems, some of which may involve the use of one or more DCUs 1274 and / or one or more sensors 1272. The actions to be taken and the specific goals to be achieved may be unique or individualized based on the control system itself. In addition, some of the actions or goals may be dynamic driving tasks (DDT), object and event detection and response (OEDR) tasks, or other non-vehicle operation-related tasks, depending on the specific context in which the AI ​​agent is implemented. DDT includes all real-time operational and tactical functions necessary to operate the vehicle 110 in road traffic, with the exception of strategic functions (e.g., travel scheduling and destination and waypoint selection). DDT includes tactical and operational tasks such as lateral vehicle motion control by steering (operation), longitudinal vehicle motion control by acceleration and deceleration (operation), monitoring the driving environment by detecting, recognizing, classifying, and preparing responses to objects and events (operation and tactical), executing responses to objects and events (operation and tactical), driving plan (tactical), and improving visibility through lighting, signals, gestures, etc. (tactical). OEDR tasks may be subtasks of DDT, including monitoring the driving environment (e.g., detecting, recognizing, and classifying objects and events and preparing to respond as needed) and executing appropriate responses to such objects and events as needed to complete DDT or fallback tasks, for example.

[0380] To observe environmental conditions, the AI ​​agent can be configured or operated to receive or monitor sensor data from one or more sensors 1272 and to receive control system data (CSD) from one or more DCUs 1274 of the vehicle 110. Monitoring operations may include acquiring CSD and / or sensor data from individual sensors 172 and DCUs 1274. Monitoring may include polling one or more sensors 1272 for sensor data and / or one or more DCUs 1274 for CSD over a specified / selected period (e.g., periodic polling, sequential (roll call) polling, etc.). In addition, or alternatively, monitoring may also include sending requests or commands to request sensor data / CSD in response to external requests for sensor data / CSD. In addition, or alternatively, monitoring may include waiting for sensor data / CSD from various sensors / modules based on triggers or events, such as when the vehicle reaches a predetermined speed and / or distance in a predetermined amount of time (with or without a pause). Events / triggers may be specific to the AI ​​agent and may vary depending on the particular application, use case, implementation, etc. In addition, or alternatively, monitoring may be triggered or activated by the IVS101 application or subsystem, or by remote devices such as compute node 140 and / or server 160.

[0381] One or more of the AI ​​agents may be configured or operable to process sensor data and CSD to identify internal and / or external environmental conditions to act upon. Examples of sensor data may include, but are not limited to, image data from one or more cameras on the vehicle providing forward, rear, and / or side views of the vehicle; sensor data from the vehicle's accelerometer, inertial measurement unit (IMU), and / or gyroscope providing data on the vehicle's speed, acceleration, and tilt; audio data provided by microphones; and control system sensor data provided by one or more control system sensors. In one example, one or more of the AI ​​agents may be configured or operable to process images captured by sensor 1272 (imaging device) and / or evaluate conditions identified by some other subsystem (e.g., EMA subsystem, CAS, and / or CPS entity) to determine the state or conditions of the surrounding area (e.g., potholes, presence of fallen trees / utility poles, damage to roadside guardrails, vehicle debris, etc.). In another example, one or more AI agents may be configured or operable to process CSDs provided by one or more DCU1274s to determine the current emissions or fuel consumption of their vehicle. The AI ​​agents may also be configured or operable to compare sensor data and / or CSDs with training set data to determine or contribute to determining environmental conditions for cont...

Claims

1. A device used to perform Vulnerable Road Users (VRU) Basic Service (VBS) functions, which is included in the Intelligent Transport Systems-S (ITS-S) of non-Vulnerable Road Users (non-VRUs), A means for determining a set of VRUs or VRU clusters to be reported in a VAM, based on at least one of the following: comparing detection results obtained by detecting VRUs around a sensor via a sensor communicably connected to a non-VRU ITS-S with VRU information contained in a known VRU recognition message (VAM); and evaluating changes in the dynamics of the detected VRUs based on the detection results; Means for generating the VAM including a VAM extension container, wherein the VAM extension container includes a first container and a second container, the first container indicating the total number of individual VRUs in the set that were reported, and the second container indicating the total number of VRU clusters in the set that were reported, means for transmitting the generated VAM A device equipped with the following features.

2. The apparatus according to claim 1, wherein the VAM extension container further comprises, for each set of VRUs or VRU clusters subject to reporting, a VRU low-frequency container for carrying static information, a VRU high-frequency container for carrying dynamic information, a cluster information container for carrying information related to each cluster, a cluster operation container for carrying information regarding changes in cluster state and configuration, and a motion prediction container for carrying motion state information.

3. A device used to execute VBS functions, included in a non-VRU ITS-S, A determination unit that determines a set of VRUs or VRU clusters to be reported in the VAM, based on at least one of the following: comparing the detection result obtained by detecting VRUs around a sensor via a sensor that is communicably connected to a non-VRU ITS-S with VRU information contained in a known VRU recognition message (VAM); and evaluating the change in the dynamics of the detected VRUs based on the detection result; A generation unit that generates the VAM including a VAM extension container, wherein the VAM extension container includes a first container and a second container, the first container indicating the total number of individual VRUs in the set that are subject to reporting, and the second container indicating the total number of VRU clusters in the set that are subject to reporting, A transmission unit that transmits the generated VAM A device equipped with the following features.

4. A method for executing VBS functions using a non-VRU ITS-S, A decision step to determine a set of VRUs or VRU clusters to be reported in the VAM, based on at least one of the following: comparing the detection result obtained by detecting VRUs around a sensor via a sensor communicably connected to a non-VRU ITS-S with VRU information contained in a known VRU recognition message (VAM); and evaluating the dynamic changes of the detected VRUs based on the detection result; A generation step of generating the VAM including a VAM extension container, wherein the VAM extension container includes a first container and a second container, the first container indicates the total number of individual VRUs in the set that are subject to reporting, and the second container indicates the total number of VRU clusters in the set that are subject to reporting, The transmission step of transmitting the generated VAM A method that includes [a certain feature].

5. A program for causing a computer to perform the method described in claim 4.

Images