Enhancement of Collective Perception Services in a High-Speed Road Traffic System

Abstract

The present disclosure relates to an intelligent transportation system (ITS), and in particular to a service distribution basic service (SDBS) and / or collective perception service (CPS) of an ITS station (ITS-S). This disclosure provides an implementation of how the SDBS and / or CPS are located within the facility layer of the ITS-S, different conditions for service distribution message (SDM) and / or collective perception message (CPM) distribution, and format and encoding rules for SDM / CPS generation.

Description

Technical Field

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 036,156 (AD0488-Z), filed on Jun. 8, 2020, the content of which is incorporated herein by reference in its entirety.

[0002] Related Applications This disclosure generally relates to the implementation of edge computing, network communications, and communication systems, and more particularly to connected computer-aided (CA) / autonomous driving (AD) vehicles, the Internet of Vehicles (IoV), the Internet of Things (IoT) technology, 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 to enable improvements in traffic safety and efficiency and to reduce emissions and fuel consumption. Various forms of wireless communication and / or radio access technology (RAT) can be used in ITS. These RATs may need to coexist on one or more communication channels, such as those available in the 5.9 gigahertz (GHz) band. Cooperative advanced road traffic systems (C-ITS) have been developed to enable improvements in 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.

Brief Description of the Drawings

[0004] In the drawings which are not necessarily drawn to scale, like reference numerals may describe like components in different views. Like numbers with different subscripts may represent different examples of like components. The accompanying drawings include the following.

[0005]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Modes for Carrying Out the Invention

[0006] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, specific details of particular structures, architectures, interfaces, techniques, etc. are described for purposes of illustration and not limitation. It will be apparent to those skilled in the art having the benefit of this disclosure that modifications can be made without departing from the scope of this disclosure. In some cases, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description with unnecessary detail.

[0007] Vehicle operation and control are becoming increasingly autonomous over time, and most vehicles are likely to become fully autonomous in the future. Vehicles that include some form of autonomy or otherwise assist a human operator may be referred to as "computer-assisted or automated driving" vehicles. Computer-assisted or automated driving (CA / AD) vehicles can include artificial intelligence (AI), machine learning (ML), and / or other similar self-learning systems that enable automated driving. Typically, these systems perceive their environment (e.g., using sensor data) and execute various actions to maximize the likelihood of successful vehicle operation.

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

[0009] One such V2X application includes the Intelligent Transport System (ITS), which is a system that uses information and communication technologies to support the transportation of goods and people in order to use transportation infrastructure and means of transportation (e.g., automobiles, trains, airplanes, ships, etc.) efficiently and safely. The elements of ITS are standardized by various standardization bodies at both the international and regional levels.

[0010] Communications in ITS (ITSC) can utilize various existing and new access technologies (or radio access technologies (RATs)) and ITS applications. Examples of these V2X RATs include Institute of Electrical and Electronics Engineers (IEEE) RAT and 3rd Generation Partnership Project (3GPP®) RAT. IEEE V2X RATs include, for example, Wireless Access in Vehicular Environments (WAVE), Dedicated Short Range Communications (DSRC), Intelligent Transport Systems in the 5 GHz frequency band (ITS-G5), the IEEE 802.11p protocol (which is the layer 1 (L1) and layer 2 (L2) part of WAVE, DSRC, and ITS-G5), and sometimes the IEEE 802.16 protocol, also known as Worldwide Interoperability for Microwave Access (WiMAX®). The term "DSRC" refers to vehicle communications in the 5.9 GHz frequency band commonly used in the United States, and "ITS-G5" refers to vehicle communications in the 5.9 GHz frequency band in Europe. Since there can be any number of different RATs (including IEEE 802.11p-based RATs) that can be used in any geographical or political region, the terms "DSRC" (as used in the United States among other regions) and "ITS-G5" (as used in Europe among other regions) can be used interchangeably throughout this disclosure. 3GPP® V2X RATs include, for example, Cellular V2X (C-V2X) using Long Term Evolution (LTE) technology (sometimes called "LTE-V2X") and / or Cellular V2X (C-V2X) using 5th Generation (5G) technology (sometimes called "5G-V2X" or "NR-V2X"). Other RATs, such as those using Ultra High Frequency (UHF) and Very High Frequency (VHF) frequencies, Global System for Mobile Communications (GSM®), and / or other wireless communication technologies, may also be used for ITS and / or V2X applications.

[0011] This document describes the enhancement of a Collective Perception Service (CPS) to support applications in the field of road and traffic safety. Collective Perception (CP) aims to share information about the current driving environment among ITS-S in ITS. For this purpose, the CPS provides information about the environment of the ITS subsystem, which may include road safety-related objects (e.g., other road participants, obstacles, etc.) detected by local perception sensors and / or free space information. Since other ITS-S contribute context information (e.g., information about the perceived environment), CP reduces the uncertainty of the ITS subsystem regarding its current environment. This includes enhancing and / or updating the syntax and semantics of Collective Perception Messages (CPMs), as well as details of data and message processing, to improve the recognition of the environment in a more collaborative way.

[0012] 1. Composition of the Intelligent Transport System (ITS) Figure 1 shows an overview of environment 100, including 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 vehicle used for the transportation of people or goods, each of which is equipped with a control system used for driving, parking, passenger comfort, and / or safety. Terms such as "motor" and "motorized" used herein refer to a device that converts one form of energy into mechanical energy, including internal combustion engines (ICEs), compression combustion engines (CCEs), electric motors, and hybrids (e.g., including ICE / CCE and electric motors). The multiple vehicles 110 shown in Figure 1 can represent motor vehicles of various manufacturers, models, trims, etc.

[0013] For illustrative purposes, the following description provides a deployment scenario involving vehicle 110 in a 2D freeway / highway / road environment where vehicle 110 is an automobile. However, other types of vehicles are also applicable, such as trucks, buses, motorboats, motorcycles, electric personal transportation devices, and / or any other engine-equipped device capable of transporting people or goods. The 3D deployment scenario is also applicable when part or all of vehicle 110 is implemented as a flying object such as an aircraft, drone, UAV, etc., and / or as any other similar engine-equipped device.

[0014] For illustrative purposes, the following description provides vehicle 110 including an in-vehicle system (IVS) 101, which will be described in more detail below. However, vehicle 110 can include additional or alternative types of computing devices / systems that may be operable to perform the functions described herein, such as smartphones, tablets, wearables, laptops, laptop computers, in-vehicle infotainment systems, in-vehicle entertainment systems, instrument clusters, head-up display (HUD) devices, on-board diagnostic devices, dash-top mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, microcontrollers, control modules, engine management systems, etc. Vehicle 110 including a computing system (e.g., IVS 101) and vehicles referenced throughout this disclosure can be referred to as vehicle user equipment (vUE) 110, vehicle station 110, vehicle ITS station (V-ITS-S) 110, computer-aided (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 (DCU) 174. The IVS 100 includes, for example, several vehicle computing hardware subsystems and / or applications that include various hardware and software elements for implementing the ITS architectures of FIGS. 6-9. The vehicle 110 can employ one or more V2X RATs that enable the vehicles 110 to communicate directly with each other and with infrastructure devices (e.g., network access node (NAN) 130). The V2X RAT can refer to 3GPP (registered trademark) cellular V2X RATs (e.g., LTE, 5G / NR, and beyond), WLAN V2X (W-V2X) RATs (e.g., US DSRC or EU ITS-G5), and / or several other RATs such as those described herein, for example. Some or all of the vehicles 110 can include positioning circuitry for (roughly) determining their respective geographical locations and communicating their current positions to the NAN 130 in a secure and reliable manner. This enables the vehicles 110 to synchronize with each other and / or with the NAN 130. Additionally, some or all of the vehicles 110 can be computer-assisted or autonomous driving (CA / AD) vehicles that can include artificial intelligence (AI) and / or robotics to assist with vehicle operation.

[0016] IVS 101 includes an ITS-S 103 that can be the same as or similar to the ITS-S 901 of FIG. 9. IVS 101 can be or include an upgradeable vehicle computing system (UVCS) as described hereinafter. As described herein, the ITS-S 103 (or the V2X RAT circuit on which the ITS-S 103 operates) can perform channel sensing or medium sensing operations, which utilize at least energy detection (ED) to determine the presence or absence of other signals on the channel to determine whether the channel is occupied or clear. ED can include sensing radio frequency (RF) energy over an intended transmission band, spectrum, or channel over a period of time and comparing the sensed RF energy to a predefined or configured threshold. When the sensed RF energy exceeds the threshold, the intended transmission band, spectrum, or channel can be considered occupied.

[0017] Except for the UVCS technology of the present disclosure, IVS 101 and the CA / AD vehicle 110 can be any one of several in-vehicle systems and CA / AD vehicles, from computer-assisted vehicles to partially or fully autonomous vehicles. Additionally, IVS 101 and the CA / AD vehicle 110 can include other components / subsystems not shown in FIG. 1, such as those elements shown and described throughout the present disclosure. These and other elements of the underlying UVCS technology used to implement IVS 101 are further described with reference to the remaining FIGS. 6-11.

[0018] In addition to the functions described herein, ITS-S 901 (or the V2X RAT circuitry on which ITS-S 901 operates) can measure various signals or determine / identify various signal / channel characteristics. Signal measurements can be performed for cell selection, handover, network connection, testing, and / or other purposes. The measurements / characteristics collected by ITS-S 901 (or the V2X RAT circuitry) can include bandwidth (BW), network or cell load, latency, jitter, round-trip time (RTT), number of interruptions, out-of-order delivery of data packets, 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 and interference ratio (SINR), signal plus noise plus distortion to noise plus distortion (SINAD) ratio, peak-to-average power ratio (PAPR), reference signal received power (RSRP), received signal strength indicator (RSSI), reference signal received quality (RSRQ), GNSS timing of the cell frame for UE positioning for E-UTRAN or 5G / NR (e.g., the timing between the NAN 130 reference time and the GNSS-specific reference time for a given GNSS), GNSS code measurements (e.g., the 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 to the signal, also referred to as the accumulated delta range (ADR)), channel interference measurements, thermal noise power measurements, received interference power measurements, and / or one or more of other similar measurements.RSRP, RSSI, and / or RSRQ measurement values may include RSRP, RSSI, and / or RSRQ measurement values of cell-specific reference signals, channel state information reference signals (CSI-RS), and / or synchronization signals (SS) or SS blocks (e.g., LTE or 5G / NR) for a 3GPP (registered trademark) network, as well as RSRP, RSSI, and / or RSRQ measurement values of various beacons, FILS discovery frames, or probe response frames for an IEEE802.11 WLAN / WiFi network. Additionally or alternatively, other measurement values such as 3GPP (registered trademark) TS 36.214 v15.4.0 (2019-09), 3GPP (registered trademark) 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. The same or similar measurement values may be measured or collected by the NAN 130.

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

[0020] The DCU 174 includes hardware elements that control various systems of the vehicle 110, such as the operation of the engine, transmission, steering, brakes, etc. The DCU 174 is an embedded system or other similar computer device that controls the corresponding systems of the vehicle 110. Each of the DCU 174 may have components the same as or similar to those of the device / system of FIG. 15 described later, or may be any other suitable microcontroller or other similar processor device, memory device, communication interface, etc. The individual DCU 174 can communicate with one or more sensors 172 and actuators (e.g., actuator 1574 of FIG. 15). The sensor 172 is a hardware element that can be configured or operated to detect the environment around the vehicle 110 and / or changes in the environment. The sensor 172 can be configured or operated to provide various sensor data to the DCU 174 and / or one or more AI agents in order 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 1572 of FIG. 15. In particular, the IVS 101 may include or implement a facility layer and may operate one or more facilities within the facility layer.

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

[0022] IVS 101 communicates or interacts with one or more remote / cloud servers 160 via NAN 130, through interface 112 and network 158, either on its own or in response to user interaction. NAN 130 is arranged to provide network connectivity to vehicle 110 via respective interfaces 112 between NAN 130 and individual vehicle 110. NAN 130 may be an ITS-S or include it and may be a roadside ITS-S (R-ITS-S). NAN 130 is a network element that is part of an access network that provides network connectivity to end-user devices (e.g., V-ITS-S 110 and / or VRU ITS-S 117). The access network may be a radio access network (RAN) such as an NG RAN or 5G RAN for a RAN operating in a 5G / NR cellular network, an E-UTRAN for a RAN operating in an LTE or 4G cellular network, or a legacy RAN such as a UTRAN or GERAN for a GSM® or CDMA cellular network. The access network or RAN may be referred to as an access service network for a WiMAX® implementation. All or part of the RAN may be implemented as one or more software entities executed on a server computer as part of a virtual network, which may be referred to as a cloud RAN (CRAN), cognitive radio (CR), virtual baseband unit pool (vBBUP), etc. CRAN, CR, or vBBUP can implement RAN function splitting, where one or more communication protocol layers are operated by CRAN / CR / vBBUP and other communication protocol entities are operated by individual RAN nodes 130. This virtualization framework enables the freed processor cores of NAN 130 to execute other virtualized applications such as virtualized applications for VRU 116 / V-ITS-S 110.

[0023] Environment 100 also includes VRU 116, which includes VRU ITS-S 117. VRU 116 is a road user without an engine and an L-class vehicle (e.g., moped, motorcycle, Segway, etc.) as defined in Annex I of EU Regulation 168 / 2013 (e.g., International Organization for Standardization (ISO), "Road Vehicles - Vehicle Dynamics and Road Holding Capability - Vocabulary", ISO, TC 22, SC 33, Ed.2 (2011-12) ("[ISO-8855:2011]")). SAE International, "Classification and Taxonomy of Electric Micromobility Vehicles", Electric Micromobility Vehicle Committee, SAE Ground Vehicle Standard J3194 (November 20, 2019) ("[SAE-J3194]") also proposes classification and taxonomy of electric micromobility vehicles: electric bicycles (e.g., electric bicycles), electric standing scooters (e.g., Segway (registered trademark)), electric seated scooters, "self-balancing scooters" (e.g., Hoverboard (registered trademark) self-balancing board, and Onewheel (registered trademark) self-balancing single-wheel electric board, which may also be called electric self-balancing boards), electric skateboards, etc. Their main characteristics are curb weight, vehicle width, maximum speed, and power source (electric or combustion). Human-powered micromobility vehicles (bicycles, standing scooters) should also be considered. A transition may occur between engine-driven vehicles and human-powered vehicles, which may change the vehicle's dynamics. Both human power and engine power may occur in parallel and may also affect the vehicle's dynamics.

[0024] The VRU 116 is an actor that interacts with the VRU system 117 in a given use case and behavioral scenario. For example, if the VRU 116 is equipped with a personal device, the VRU 116 can directly interact with other ITS stations and / or other VRUs 116 having VRU devices 117 via the personal device. The VRU ITS-S 117 can be either a pedestrian type VRU (see, e.g., P-ITS-S 1001 in FIG. 10) or a vehicle type (bicycle, motorcycle) VRU. The term "VRU ITS-S" as used herein refers to any type of VRU device or VRU system. Even before a potential VRU 116 is identified as a VRU 116, it can be called a non-VRU and considered to be in an idle or non-active state in the ITS.

[0025] If the VRU 116 is not equipped with a device, the VRU 116 interacts indirectly when it is detected by another ITS station of the VRU system 117 via its sensing devices such as sensors and / or other components. However, such a VRU 116 cannot detect other VRUs 116 (e.g., bicycles). In ETSI TS 103 300-2 V2.1.1 (2020-05) ("[TS103300-2]"), different types of VRUs 116 are classified into various profiles that further define the VRU functional system and communication architecture for the VRU ITS-S 117. To robustly support VRU profile recognition activation, VRU-related functional system requirements, protocols, and message exchange mechanisms (e.g., CPM, VAM, etc.) are provided herein.

[0026] The VRU 116 can comprise a portable device (e.g., device 117). The term "VRU" can be used to refer to both the VRU 116 and its VRU device 117 unless otherwise indicated in context. The VRU device 117 may be initially configured and may evolve during its operation according to context changes that are specified. This particularly applies to the settings of the VRU profile and VRU type that can be achieved automatically upon power-on or via the HMI. Changes in the vulnerable state of a road user need to be provided also to activate the VRU basic service when the road user becomes vulnerable or to stop it when entering a protected area. The initial configuration can be set automatically when the device is powered on. This can be the case for VRU device types that can be VRU-Tx with only the communication ability to broadcast messages and comply with channel congestion control rules, VRU-Rx with only the communication ability to receive messages, and / or VRU-St with full-duplex communication ability. During operation, the VRU profile can also change due to some clustering or reverse assembly. As a result, the role of the VRU device can evolve according to changes in the VRU profile.

[0027] (e.g., VRU ITS-S 117) The "VRU system" comprises ITS artifacts related to VRU use cases and scenarios as described herein, including the main components and their configuration, actors and their devices, the associated traffic situations, and the operating environment. The terms "VRU device", "VRU equipment", and "VRU system" refer to a portable device (e.g., a mobile station such as a smartphone, tablet, wearable device, fitness tracker, etc.) or an IoT device (e.g., a traffic control device) used by the VRU 116 integrating ITS-S technology, and thus the VRU ITS-S 117 can include or refer to the "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 with a VRU application. The ITS-S can be a vehicle ITS-station or a roadside ITS-station that processes VRU application logic based on the lower communication layer (facility, network and transport as well as the access layer (see, e.g., ETSI EN 302 665 V1.1.1 (2010-09) (“[EN302665]”)), the associated hardware components, other in-station services, and the services provided by the sensor subsystem. The VRU system can be extended with other VRUs involved in scenarios such as vehicles, motorcycles, bicycles, and pedestrians, other ITS-Ss, and other road users. The VRUs can be equipped with the ITS-S, or with different technologies (e.g., IoT) that enable them to send or receive warnings. Thus, the VRU system considered is a heterogeneous system. The definition of the VRU system is used to identify the system components that actively participate in the use case and behavior scenarios. The active system components are equipped with the ITS station and all other components are passive and form part of the environment of the VRU system.

[0029] The VRU ITS-S 117 can operate one or more VRU applications. The VRU applications are applications that extend the recognition of VRUs and / or VRU clusters within or around other road users and / or. The VRU applications can be present in any ITS-S, i.e., the VRU applications can be found either in the VRU itself or in a non-VRU ITS station, such as a car, truck, bus, roadside station or central station. These applications aim to provide VRU-related information directly to actors such as humans or to automated systems. The VRU applications can enhance the recognition of vulnerable road users, provide VRU collision risk warnings to any other road users, or trigger automated actions of vehicles. The VRU applications can utilize data received from other ITS-S via the C-ITS network and use additional information provided by the ITS-S's own sensor system and other integrated services.

[0030] Generally, there are four types of VRU devices 117, including an unarmed VRU (e.g., VRU 116 without a device), VRU-Tx (e.g., VRU 116 with an ITS-S 117 that has only the transmission (Tx) ability to broadcast recognition messages or beacons related to VRU 116 but does not have the reception (Rx) ability), VRU-Rx (e.g., VRU 116 equipped with an ITS-S 117 that has only the Rx (but not Tx) ability to receive broadcast recognition messages or beacons related to other VRU 116 or other non-VRU ITS-S), and VRU-St (e.g., VRU 116 equipped with an ITS-S 117 that includes VRU-Tx and VRU-Rx functions). Use cases and behavior scenarios consider a wide set of configurations of the VRU system 117 based on the presence or absence of devices in VRU 116 and V-ITS-S 110 and / or R-ITS-S 130 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 designated for VRU 116 / 117 is the VRU Awareness Message (VAM). The VAM is a message sent from VRU ITS 117 to create and maintain the awareness of VRU 116 participating in the VRU / ITS system. The VAM is maximally harmonized with the existing Cooperative Awareness Message (CAM) defined in [EN302637-2]. The transmission of the VAM is limited to the VRU profile specified in Clause 6.1 of [TS103300-2]. The VAM contains all the necessary data according to the VRU profile and the actual environmental conditions. The VAM includes the status and attribute information of the transmitting VRU ITS-S 117. The content may vary according to the profile of VRU ITS-S 117. Typical status information includes time, location, movement state, cluster status, etc. Typical attribute information includes data related to the VRU profile, type, dimensions, etc. The generation, transmission, and reception of the VAM are managed by the VRU Basic Service (VBS), which is a facility layer entity that operates the VAM protocol. The VBS provides the following services, namely, the processing of the role of the VRU to enhance VRU safety, and the transmission and reception of the VAM. The VBS also designates and / or manages VRU clustering in the presence of a high VRU 116 / 117 density to reduce the VAM communication overhead. In VRU clustering, closely located VRUs with coherent speed and direction of travel form a facility layer VRU cluster, and only the cluster head VRU 116 / 117 transmits the VAM. The other VRUs 116 / 117 in the cluster skip VAM transmission. Active VRUs 116 / 117 (e.g., VRUs 116 / 117 not in a VRU cluster) transmit individual VAMs (referred to as single VRU VAMs, etc.). An "individual VAM" is a VAM that contains information about an individual VRU 116 / 117. Ineligible VAMs can be either cluster VAMs or individual VAMs. Other details regarding VRUs and VAMs are described in ETSI TS 103 300-3 V0.1.11 (2020-05) ( "[TS103300-3]" ).

[0032] The radio access technologies (RATs) employed by NAN 130, V-ITS-S 110, and VRU ITS-S 117 can include one or more V2X RATs that enable V-ITS-S 110 to communicate directly with each other, with infrastructure devices (e.g., NAN 130), and with VRU devices 117. In the example of FIG. 1, any number of V2X RATs can be used for V2X communication. In one example, at least two separate V2X RATs can be used, including IEEE V2X technologies (e.g., DSRC in the United States and ITS-G5 in Europe) and WLAN V2X (W-V2X) RATs based on 3GPP® C-V2X RATs (e.g., LTE, 5G / NR, and beyond). 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, "[EN302663]"), which describes the access layer of the ITS-S reference architecture (e.g., see FIG. 6). The ITS-G5 access layer comprises the IEEE802.11-2016 (hereinafter, "[IEEE80211]") and IEEE802.2 logical link control (LLC) (hereinafter, "[IEEE8022]") protocols. The access layer of the interface based on 3GPP® LTE-V2X is outlined, inter alia, in ETSI EN 303 613 V1.1.1 (2020-01), 3GPP® TS 23.285 v16.2.0 (2019-12), and 3GPP® 5G / NR-V2X is outlined, inter alia, in 3GPP® TR 23.786 v16.1.0 (2019-06) and 3GPP® TS 23.287 v16.2.0 (2020-03). NAN 130 or edge computing node 140 can provide one or more services / capabilities 180.

[0033] In a V2X scenario, the V-ITS-S 110 or NAN 130 can be, or function as, an RSU or R-ITS-S 130 that refers to any traffic infrastructure entity used for V2X communication. In this example, the RSU 130 can be a fixed RSU such as a gNB / eNB type RSU or other similar infrastructure, or a relatively fixed UE. Additionally or alternatively, the RSU 130 can be a mobile RSU or UE type RSU implemented by a vehicle (e.g., V-ITS-S 110), a pedestrian, or any other device with such capabilities. In these cases, mobility issues can be managed to ensure appropriate wireless coverage of the conversion entity.

[0034] In an exemplary implementation, the RSU 130 is a computing device coupled to a radio frequency circuit disposed on the roadside that provides connection support for passing through the V-ITS-S 110. The RSU 130 can also include an internal data storage circuit for storing intersection map shapes, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU 130 provides various services / capabilities 180 such as ultra-low latency communication required for high-speed events such as collision avoidance and traffic warnings. Additionally or alternatively, the RSU 130 can provide other services / capabilities 180 such as cellular / WLAN communication services. In some implementations, the components of the RSU 130 can be packaged in a weather-resistant enclosure suitable for outdoor installation and can include a network interface controller for providing a wired connection (e.g., Ethernet (registered trademark)) to a traffic signal controller and / or a backhaul network. Further, the RSU 130 can include a wired or wireless interface for communicating with other RSU 130s (not shown in FIG. 1).

[0035] In configuration 100, V-ITS-S 110a may be equipped with a first V2X RAT communication system (e.g., C-V2X), and V-ITS-S 110b may be equipped with a second V2X RAT communication system (e.g., W-V2X which may be DSRC, ITS-G5, etc.). Additionally or alternatively, each of V-ITS-S 110a and / or V-ITS-S 110b may be employed with one or more V2X RAT communication systems. The RSU 130 can provide a V2X RAT conversion service between one or more services / abilities 180 so that individual V-ITS-S 110s can communicate with each other even when the V-ITS-S 110s implement different V2X RATs. The RSU 130 (or edge computing node 140) can provide a VRU service between one or more services / abilities 180 where the RSU 130 shares CPM, MCM, VAM, DENM, CAM, etc. with the V-ITS-S 110 and / or VRU for VRU safety purposes including RSS purposes. The V-ITS-S 110s may also share such messages with each other, with the RSU 130, and / or with the VRU. These messages can include various data elements and / or data fields as described herein.

[0036] In this example, NAN 130 may be a fixed RSU such as an RSU of the gNB / eNB type or other similar infrastructure. Additionally or alternatively, NAN 130 may be a mobile RSU or a UE-type RSU that can be implemented by a vehicle, a pedestrian, or some other device with such capabilities. In these cases, mobility issues can be managed to ensure appropriate wireless coverage of the conversion entity. NAN 130 that enables connection 112 may be referred to as a "RAN node" or the like. The RAN node 130 can comprise a terrestrial station (e.g., a terrestrial access point) or a satellite station that provides coverage within a geographical area (e.g., a cell). The RAN node 130 can be implemented as one or more of dedicated physical devices such as a macrocell base station and / or a femtocell, picocell, or other similar cell that has a smaller coverage area, a smaller user capacity, or a higher bandwidth compared to a macrocell, or a low-power base station for providing such cells. In this example, the RAN node 130 is embodied as a Node B, evolved Node B (eNB), or next-generation Node B (gNB), one or more relay nodes, a distributed unit, or a roadside unit (RSU). Any other type of NAN can be used. Additionally, the RAN node 130 can perform various logical functions for the RAN, including but not limited to RAN functions such as radio resource management, admission control, dynamic resource allocation for uplink and downlink, radio bearer management, data packet scheduling (e.g., radio network controller (RNC) functions and / or NG-RAN functions).

[0037] Network 158 can represent a network such as the Internet, a wireless local area network (WLAN), or a wireless wide area network (WWAN) including a dedicated and / or enterprise network 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 some other type of core network), a cloud computing architecture / platform that provides one or more cloud computing services, and / or combinations thereof. By way of example, network 158 and / or access technology can include cellular technologies such as LTE, MuLTE Fire, and / or NR / 5G (e.g., as provided by radio access network (RAN) node 130), WLAN (e.g., WiFi (R)) technology (e.g., as provided by access point (AP) 130), and the like. Different technologies exhibit advantages and limitations in different scenarios, and application performance in different scenarios will come to depend on the selection of the access network (e.g., WiFi, LTE, etc.) as well as the network and transport protocols used (e.g., transmission control protocol (TCP), virtual private network (VPN), multipath TCP (MPTCP), generic routing encapsulation (GRE), etc.).

[0038] Additionally or alternatively, CPM is exchanged in ITS network 100 among ITS-S 110, 130, 116 / 117, etc. to share information about the perceived environment of the ITS subsystem, such as the presence of road users and other objects detected and recognized by the ITS subsystem. These detected road users or objects potentially do not have ITS-S itself equipped. Such non-ITS-S equipped objects cannot make other ITS-S recognize their presence and current state, and thus cannot contribute to cooperative recognition. CPM includes the status and attribute information of these non-ITS-S equipped users and objects detected by the transmitting ITS subsystem. The content of CPM is not limited to non-ITS-S equipped objects and may also include measured status information about ITS-S equipped road users. The content may vary depending on the type of road user or object and the detection capabilities of the transmitting ITS subsystem. In the case of vehicle objects, the status information is expected to include at least the actual time, location, and movement state. Additional attributes such as dimensions, vehicle type, and role in road traffic can be provided.

[0039] CPM complements Cooperative Awareness Messages (CAMs) in order to establish and enhance cooperative awareness. CPM contains externally observable information regarding detected road users or objects and / or free spaces. The CP service may include means to reduce the duplication of CPMs transmitted by different ITS-Ss by checking the CPMs transmitted by other stations. When receiving a CPM, the receiving ITS-S becomes aware of the presence, type, and status of the recognized road users or objects detected by the transmitting (Tx) ITS-S. The received information can be used by the receiving ITS-S to support ITS applications to enhance the safety situation and improve traffic efficiency or travel time. For example, by comparing the status of the detected road users or received object information, the receiving ITS-S subsystem can estimate the risk of collision with such road users or objects and notify the user via the HMI of the receiving ITS subsystem or take corrective actions automatically. Thereby, multiple ITS applications may depend on the data provided by the CP service. This is assigned to the domain application support facility of [TS102894-1]. Furthermore, [TR103562] provides an analysis of the CPS together with further information and simulation results.

[0040] The Remote / Cloud Server 160 can 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 can include any one of a number of services and capabilities 180 such as, for example, ITS-related applications and services, driving assistance (e.g., mapping / navigation), content provision (e.g., multimedia infotainment streaming).

[0041] Additionally, the NAN 130 can be co-located with an edge computing node 140 (or a set of edge computing nodes 140) that can provide any number of services / capabilities 180, such as ITS services / applications, driving assistance, and / or content providing services 180, to the vehicle 110. The edge computing node 140 can include or be part of an edge network or "edge cloud". The edge computing node 140 may also be referred to as an "edge host 140", "edge server 140", or "computing platform 140". The edge computing node 140 can partition resources (e.g., memory, CPU, GPU, interrupt controller, I / O controller, memory controller, bus controller, network connection or session, etc.), and each partition can include security and / or integrity protection capabilities. The edge node can also provide orchestration of multiple applications through separated user space instances such as containers, partitions, virtual environments (VEs), virtual machines (VMs), servlets, servers, and / or other similar computing abstractions. The edge computing node 140 can be implemented in a data center or cloud installation, a designated edge node server, an enterprise server, a roadside server, a telecommunications central office, or a local or peer edge device consuming an edge service and providing a service. The edge computing node 140 can provide any number of driving assistance and / or content providing services 180 to the vehicle 110. The edge computing node 140 can be implemented in a data center or cloud installation, a designated edge node server, an enterprise server, a roadside server, a telecommunications central office, or a local or peer edge device consuming an edge service and providing a service.Examples of edge computing nodes 140 and / or other edge computing / networking technologies that can implement an edge computing network / cloud include multi-access edge computing (MEC), content delivery networks (CDNs) (also referred to as "content delivery networks" etc.), mobility service provider (MSP) edge computing and / or mobility as a service (MaaS) provider systems (e.g., those used in the AECC architecture), nebula edge cloud systems, fog computing systems, cloudlet edge cloud systems, mobile cloud computing (MCC) systems, central offices reconfigured as data centers (CORD), mobile CORD (M-CORD) and / or converged multi-access and core (COMAC) systems, etc. Further, the techniques disclosed herein may relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures may also be used to implement the techniques herein.

[0042] 2. Enhancement of Collective Perception Services CPS supports ITS applications in the field of road and traffic safety by facilitating information sharing between ITS-S. Since other ITS-S contribute context information, the CP reduces the uncertainty around the ITS-S regarding its current environment. By reducing the surrounding uncertainty, the efficiency and safety of ITS are improved. Current CPS provides the syntax and semantics of CPM, as well as the specifications for data and message processing, to enhance the awareness of the environment in a cooperative manner.

[0043] According to the current CPS specification, each perceived object (e.g., a road user) is reported as a separate object, which can be very inefficient in certain scenarios such as the presence of a large number of objects in ITS-S, or overlapping views of objects, or occlusion of objects in the sensor's field of view (FOV). For example, reporting individual perceived objects when the perceived object is large creates a large amount of communication. In the case of overlapping views of objects or occlusion of objects in the sensor's FOV, the perception of all objects is itself a difficult task. In such situations, a CP based on a hierarchical cost map or occupancy grid can be bandwidth and computationally efficient. A CPS based on hierarchical cost map sharing is described in International Application No. PCT / US2020 / 038723 ( "[AC3302]" ) filed on June 19, 2020, the content of which is hereby incorporated by reference in its entirety. In [AC3302], the sharing of hierarchical cost maps is used to achieve bandwidth and computational efficiency in congested scenarios with a large number of obstacles and / or other objects. The hierarchical cost map (LCM) container can replace or complement the perceived object container and / or the free space addition container, thereby saving significant communication overhead.

[0044] Recently, in the ETSI ITS WG1, there has been a discussion about how efficient a CPM based on a hierarchical cost map can be in terms of message size compared to a CPM based on a perceived object container and a free space addition container. Since the message size is important for transmission over the air interface, the present disclosure provides a size-optimized, hierarchical cost map container for reducing the message size and / or reducing the signaling overhead.

[0045] Vulnerable Road Users (VRUs) 116 are a special class of perceived objects that require special safety treatment for safe and secure ITS (see, for example, [TS103300-2]). Details of the various classes of VRUs and VRU clusters (groups of nearby VRUs with similar direction of travel and speed) can be found in [AC3302].

[0046] There is ongoing work at ETSI to enable CPS for Advanced Road Traffic Systems. It provides basic functions for sharing sensing capabilities and perceived objects among nearby vehicles (see, for example, error! Reference source not found [TS103324]). Current work provides broadcast-based CPM sharing, which can be costly in terms of network overhead, especially for scenarios such as the presence of a large number of objects, or overlapping views of objects, or occlusion of objects in the FOV of sensors in ITS-S, and can be further optimized for CP.

[0047] In existing CPS specifications, each of the perceived objects is reported as an individual object, which can be very inefficient in scenarios such as the presence of a large number of objects in ITS-S, or overlapping views of objects, or occlusion of objects in the FOV of sensors, for several of the reasons mentioned above. For example, reporting each individual perceived object in the case of a large perceived object generates a large amount of communication, and since each CPM message can only contain a limited number of perceived objects due to CPM size constraints, it takes longer to report all the perceived objects. In the case of overlapping views of objects or occlusion of objects in the FOV of sensors, the perception of all objects is itself a difficult task. Existing CPS still lacks a way to report the perceived environment in a more efficient way with respect to communication overhead.

[0048] As will be described in more detail below, the VRU 116 and VRU clusters are reported as a separate cost map layer called the "VRU layer". The data elements (DEs) and / or data fields (DFs) of the LCM container enable reporting of VRUs and VRU clusters as individual cost map layers. Since the VRU 116 can have a higher safety priority compared to other perceived objects, the LCM container enables frequent sharing of the VRU layer compared to the aggregated perceived obstacle layer.

[0049] The transmitting ITS-S shares cost values at the reliability level of each grid cell for each layer of the reported grid area based on the presence of obstacles / objects in the cell. The ITS-S may not be able to determine the cost values of some grid cells at a sufficient reliability level due to obstructions in the FoV of these cells, etc. In such cases, support is requested from adjacent ITS-Ss to obtain the cost values of these cells and increase the reliability level.

[0050] The present disclosure also includes further enhancements to the LCM container to enable such collaboration requests in an effective and flexible manner. Procedures for indicating and resolving discrepancies in grid cell cost values between proximities (e.g., when one or more received values differ from the cost value of the node itself) are also described herein. The present disclosure also provides DE / DFs that enable such discrepancy handling efficiently. The present disclosure also includes the following. · Size-optimized hierarchical cost map container options for effectively sharing environmental perception - The message size of the container can be optimized based on the number of cost map layers that need to be transmitted, situations such as access layer congestion, etc. · New cost map layers, as well as the DE / DFs required for the hierarchical cost map container to enable reporting of VRUs and VRU clusters as separate cost map layers. · The ability of a hierarchical cost map container (such as new DE / DF) to enable collaboration requests in an effective and flexible way by querying the cost values of selected grid cells when the self ITS-S cannot determine the cost values of these grid cells (due to obstructions in the FoV of these cells, etc.) with a sufficient level of reliability. · Enhancement of the ability of a hierarchical cost map container (such as new DE / DF) to enable the resolution of discrepancies in grid cell cost values between adjacent grid cells in an effective and flexible way.

[0051] Existing CPSs are extended to enable hierarchical cost map sharing. This can be beneficial in scenarios that include the presence of a large number of objects in the FOV of sensors in ITS-S, overlapping views of objects, and / or occlusion of objects. The LCM container is included in the CPMs that are exchanged between various V-ITS-S 110, R-ITS-S 130, and / or VRU ITS-S 117. Various standards such as ETSI and / or 3GPP (registered trademark) can adopt and specify various aspects of these messages and message exchange mechanisms. In these ways, the CP between adjacent (proximate) ITS-Ss becomes safer for a more collaborative driving environment, and the signaling efficiency is improved.

[0052] In some implementations, these safety / efficiency services are implemented in a Multi-Access Edge Computing (MEC) network / framework and can be easily scaled across a city or geographical area. In these implementations, one or more MEC apps can provide CPS. In various implementations, Open Visual Inference and Neural Network Optimization (OpenVINO), OpenNESS, and / or other edge computing frameworks (e.g., Intel® Smart Edge, etc.) can be used to provide CPS. In some implementations, the R-ITS-S 130 uses sensors to collect semantic information about the environment, fuse them together, and generate ITS messages for the ITS-S of the environment. This architecture can be easily implemented using the aforementioned edge computing platform and machine learning framework.

[0053] 2.1. Collective Perception Message (CPM) Container Figures 2 and 3 show the structures of CPM 200 and 300, respectively, which enable ITS-S to share sensor information, a list of perceived objects, free space addition, and a hierarchical cost map. CPM 200, 300 include a common ITS PDU header and a plurality of containers, which together constitute CPM 200, 300. Each container includes a series of optional or mandatory data elements (DE) and / or data frames (DF). The DE and DF included in the CPM format are based on the ETSI Common Data Dictionary (CDD) (see, for example, ETSI TS 102 894-2 v1.3.1 (2018-08) (“[TS102894-2]”)) and / or utilize specific elements defined in the “Use of V2I and I2V for Applications Related to Installed Signals for Advanced Road Traffic Systems - Cooperative ITS” of the International Organization for Standardization (ISO) Technical Committee (TC) 204, Ed. 2 (2019-06) (“[ISO / TS19091]”).

[0054] CPM 200 and 300 can be distributed by either a mobile ITS-S such as V-ITS-S 110 or a fixed ITS-S such as R-ITS-S 130. Using the ASN.1 extensibility feature, support for other types of ITS-S can be added later.

[0055] 2.1.1. ITS PDU Header CPM 200 and 300 include an ITS PDU header. The ITS PDU header is a common header that contains information about the protocol version, message type, and the ITS-S identifier (ID) of the transmitting ITS-S. The ITS PDU header is included as specified in [TS102894-2]. The detailed data presentation rules for the ITS PDU header in the context of CPM 200 and 300 are as specified in Annex A of [TS103324].

[0056] 2.1.2. CPM Management Container Regardless of which type of ITS-S distributes CPM 200 and 300, the (CPM) management container provides information about the ITS-S type and the reference position of the ITS-S. The management container provides basic information about the transmitting ITS-S, regardless of whether it is a V-ITS-S 110 or an R-ITS-S 130. This container includes, as part of the messageSegmentInfo, optional information about the ITS-S type, reference position, and the current message segment. Message segmentation is managed according to Clause 6.1.4 of [TS103324]. The reference position is used to reference an object relative to the provided global position. The provided reference points are detailed in [EN302890-2]. In the case of V-ITS-S 110, the reference point refers to the ground position at the center of the front face of the bounding box of the V-ITS-S 110. In the case of R-ITS-S 130, the reference point refers to any position on the road segment or intersection. This point is used to determine the offset to other data points.

[0057] 2.1.3. Station Data Container To enable simplified future extensibility of CPM 200 and 300, the ASN.1 information object class is adopted for station data and perception data containers.

[0058] When CPM 200 and 300 are generated by V-ITS-S 110, there is a station data container of type CpmStationDataContainer that includes the information object OriginatingVehicleITSSContainer, which contains the dynamic information of the originating ITS-S.

[0059] The originating vehicle ITS-S container includes information regarding the dynamics of the vehicle ITS subsystem that distributes CPM 200 and 300. This is included in all CPM 200 and 300 transmitted by V-ITS-S 110. Such information is required to transform the objects described in the perceived object container of the same CPM 200 and 300 into a target reference frame such as the vehicle-centered coordinate system.

[0060] The originating vehicle ITS-S container is encoded as specified in Annex A of [TS103324]. More specifically, the following rules apply. The vehicle azimuth provides means for transmitting the actual orientation of the vehicle opposite to the vehicle's travel direction that refers only to the direction of the magnitude of the provided velocity vector. The container also provides means for including a description of a trailer attached to a towing vehicle (e.g., for trucks). Different layouts of the attached trailer are possible. It is necessary to provide TrailerData to convert the objects detected by sensors attached to the trailer into the reference frame of the receiving ITS-S. All trailers added to the vehicle description consist of TrailerData containers that can be added up to two times. Each TrailerData provides a new reference point ID that increments from 1. The reference point ID 0 always refers to the reference point of the towing vehicle. An offset from the reference point of the towing vehicle to the longitudinal hitch point is provided according to [ISO-8855:2011]. The dimensions of the trailer are provided by defining the front and rear overhangs of the trailer with respect to the hitch point of the trailer as shown in the figure. The width of the trailer may optionally be provided. The hitch angle is also optionally available. Further configurations for providing reference points for ITS-S can be found in [EN302890-2].

[0061] When CPM 200 and 300 are generated by R-ITS-S 130, there may be an originating roadside ITS-S container of type CpmStationDataContainer that includes the information object OriginatingRoadsideITSSContainer. If it exists, it provides a reference to an identification number provided by a MAP message (see, for example, [ISO / TS19091]) distributed by the same R-ITS-S 130. The originating roadside ITS-S container includes two parameters for referring to information received by a MAP message (see, for example, [ISO / TS19091]) distributed by the same roadside ITS-S. Either IntersectionReferenceID or RoadSegmentID can be used to refer to the road infrastructure provided by the road lane topology service. If OriginatingRoadsideITSSContainer is included, R-ITS-S 130 also transmits a MAP message. In the case of R-ITS-S 130 that distributes CPM 200 and 300, the reference position refers to the reference position defined in [ISO / TS19091] (for example, any point on the intersection).

[0062] 2.1.4. Sensor Information Container A sensor information container (or "sensor information (Info) container") of type CpmPerceptionDataContainer that includes the information object SensorInformationContainer may exist to provide information about the sensing capabilities available to the ITS subsystem. Different container specifications are available for encoding the characteristics of the sensors depending on the ITS-S type of the originating ITS-S. The sensor information container is attached at a lower frequency than other containers, as described below and / or as defined in clause 6.1.3.3 of [TS103324].

[0063] The sensor information container lists information about the individual sensors whose data is made available to the ITS-S it distributes, resulting in the generation of perceived objects, a hierarchical cost map, and / or a free space container. The sensor information container is a type CpmPerceptionDataContainer that includes the information object sensorInformationCpmContainer.

[0064] The sensor information container is encoded as specified in Annex A of [TS103324]. More specifically, the following rules apply. This container type offers the possibility of providing descriptive information about the sensing characteristics that are available to the distributed ITS-S. An ID is assigned to all sensors described, which is used in the perceived object container to associate the measured object information with a specific sensor. Additionally, each sensor information DF provided is accompanied by a sensor classification to indicate the type of perception system. This can range from a system that provides fused object information from multiple sensors to a specific sensor type such as a radar or lidar sensor. Since different sensor types can be attached to the ITS-S (e.g., radar, LIDAR, composite sensor fusion systems, etc.), this container offers different possibilities for describing the characteristics of the sensor system.

[0065] Two types of descriptions are distinguished, i.e., sensors attached to the vehicle are described using the vehicleSensor description DF. Sensors that are stationary (e.g., because they are attached to roadside infrastructure) are described using the stationarySensor variant DF. The vehicleSensor description DF also indicates the assignment of sensors to stations. The perception area of the perception system can be inferred on the receiving ITS-S from the data provided in the SensorInformationContainer.

[0066] Any of the deformation forms is used to describe the sensing capabilities of the distributed ITS-S. This can be the actual parameters of the perception system (e.g., its actual perception range) or the applicable perception area of the perception system (e.g., the area where an object is detected by the perception system).

[0067] The vehicleSensor type description provides information about sensors attached to a vehicle. The characteristics of these perception systems are defined by providing the mounting position of the sensor relative to a specific reference point on the vehicle. The range and horizontal as well as optional vertical aperture angles are provided to describe the frustum of the sensor. If the sensor has multiple detection areas, up to 10 perception areas of the sensor can be encoded. The provided offset from the reference point on the vehicle functions as the origin of the sensor-specific local Cartesian coordinate system.

[0068] For a perception system attached to roadside infrastructure, the stationarySensorRadial DF provides a similar concept for describing the sensing capabilities of the roadside system. The position provided by the offset from the reference point functions as the origin of the sensor-specific local Cartesian coordinate system. For CPM 200, 300 receivers, since the sensor position and aperture angle are provided, the sensor measurement area can be determined by projecting the area defined by the aperture angle onto the ground.

[0069] For stationary sensors, when the origin of the sensor system should or can be made explicit, an alternative DF is provided for describing the perceived area of the perception system. This is particularly useful, however, when the perception area is generated by combining several separate systems that function as one sensor. The geographical representation of the perception area of the system can be represented in terms of circular, rectangular, elliptical, or polygonal areas. These types are only applicable to stationary sensors for the purpose of geographical reference of the reference point.

[0070] FreeSpaceConfidence DE may be used to provide information that a particular sensor can provide verified measurements regarding the detected free space. The display presents an assumed isotropic confidence level for the entire detection area. FreeSpaceConfidence is used to indicate corresponding confidence values (e.g., the confidence of objects and free space).

[0071] In combination with the received objects, the receiver can calculate the resulting free space by adopting a free space confidence display and applying, for example, a ray-tracing algorithm. The illustrated perception area can be assumed to be isotropic and free.

[0072] FreeSpaceConfidence generated by DetectionArea DF. Not all objects known to the transmitter are reported by all CPM 200, 300. Therefore, the receiver needs to ensure that appropriate tracking and prediction mechanisms for previously transmitted objects are adopted to update the shadowed areas accordingly.

[0073] Using the geometric extension of the received PerceivedObject, the resulting shadowed area of each object can be calculated. For this purpose, a simple ray-tracing technique can be utilized. Thereby, the ray connects from the origin of a particular sensor to the outermost corner points of the received object geometry and extends to the perception range of the particular sensor. The area behind the object from the perspective of the sensor mounting point is considered to be "shadowed". Behind the shadowing object, a display regarding the confidence of the free space cannot be given. A three-dimensional description may be applicable. When the object is detected by a sensor at a certain height from the ground (e.g., a signage gantry), the same ray-tracing technique is adopted for the three-dimensional representation.

[0074] When the shadowing model is not applicable, the shadowingApplies DE of SensorInformation is set to False, indicating that the shadowing model cannot be calculated on the receiving side of this sensor. In some implementations, a flag can be added to simplify the description of the free space of sensors for which shadowing should not be calculated (e.g., fusion of multiple sensors).

[0075] When LayeredCostMapContainer is included in CPM 200, 300, the receiver can calculate the resulting free space by adopting the free space reliability indication provided by the grid values of the cost map. The transmitter (e.g., the distributed ITS-S) does not report a layered cost map of the same rectangular grid for each of CPM 200, 300. Therefore, the receiver needs to ensure that an appropriate tracking and prediction mechanism for the previously transmitted layered cost map is adopted to update the calculated free area accordingly.

[0076] 2.1.5. Perceived Object Container The perceived object container of type CpmPerceptionDataContainer containing the information object PerceivedObjectContainer may exist for objects perceived by the ITS subsystem. It provides information about the objects detected with respect to the distributed ITS-S. It can also provide classification and position matching the road data. This container is added only for objects detected in accordance with the inclusion rules defined in Clause 6.1.3.2 of [TS103324].

[0077] The perceived object container is added to CPM 200, 300 for each detected object as defined in Clause 6.1.3.2 of [TS103324]. The perceived object container is a type CpmPerceptionDataContainer that includes the information object PerceivedObjectContainer.

[0078] The total number of perceived objects is provided by the variable numberOfPerceivedObjects of PerceivedObjectContainer. According to the message generation rules specified in Clause 6.1.3 of [TS103324] and the related object inclusion scheme, the number of included objects may not be equal to the numberOfPerceivedObjects of the received CPM 200, 300.

[0079] The receiving ITS-S does not assume that the received PerceivedObjects of the perceived object container represent all the objects known to the transmitter. The receiver needs to listen for further CPM 200, 300 from the same transmitter for at least 1 second until all objects are received. The container enables a detailed description of the dynamic state and characteristics of the detected objects. Information regarding the position and dynamic state of the perceived objects is provided in the coordinate system specified by [ISO-8855:2011]. The coordinate system is used in the description of the state variables of the object in the case of vehicles sharing information regarding the detected objects.

[0080] In the case of R-ITS-S 130 distributing CPM 200, 300, the reference position refers to the reference position defined in [ISO / TS19091]. In one example, the reference position is an arbitrary point within / on the intersection.

[0081] All objects are described by providing at least the distance and speed in the x / y plane of their respective coordinate systems with respect to the reference point of ITS-S. The reference point of the measurement is also provided as part of the message (e.g., CPM 200, 300).

[0082] The perceived object container is encoded as specified in Annex A of [TS103324]. More specifically, the following rules apply. Each detected object is assigned an objectID. This ID is obtained from a range of monotonically increasing numbers and is maintained for each object as long as the object is perceived and new sensor measurements are assigned to the object. The permitted range of objectIDs is between 0 and 255. As soon as objectID 255 is assigned to an object, the next object is assigned the next free ID starting from ID 0 in a round-robin fashion.

[0083] For each object, the time of measurement (ToM) is provided as the time difference between the provided measurement information and the generation delta time specified in the management container. The time corresponding to the interpretation of ToM for the GenerationDeltaTime encoded in the message and the availability of the state space information regarding the detected object. GenerationDeltaTime always corresponds to the latest time at which the latest reference position is available on the Tx side. When receiving a message, the receiver calculates its own local GenerationDeltaTime based on its current absolute timestamp. The difference between the received encoded GenerationDeltaTime of CPM 200, 300 and the local GenerationDeltaTime represents the age of CPM 200, 300. Then, the received encoded ToM is added to the age of CPM 200, 300 to calculate the age of the encoded object. Thereby, a positive ToM indicates that the state space of the object was created before the transmitter's GenerationDeltaTime and is therefore older, so the receiver side needs to add ToM to the message age. A negative time value indicates that the state space of the object described after the transmitter's GenerationDeltaTime was determined, so ToM needs to be subtracted from the age of CPM 200, 300. ToM includes any processing time of the sensor or the data fusion system. When the fused object state information is transmitted, ToM refers to the time point at which the state space was predicted.

[0084] 2.1.6. Free Space Addendum Container There may be a free space addendum container of type CpmPerceptionDataContainer that includes the information object FreeSpaceAddendumContainer to describe changes to the calculated free space description.

[0085] The free space addition container may be attached to represent different reliability levels for a specific area within the DetectionArea of a specific sensor. The free space addition container is a type CpmPerceptionDataContainer that includes the information object FreeSpaceAddendumContainer.

[0086] In the context of CPM 200, 300, the free space addition container is encoded as specified in Annex A of [TS103324]. More specifically, the following rules apply. This container is only added if there is a need to change the reliability display with respect to the isotropic reliability level display provided by the SensorInformationContainer. Whether or not to include the FreeSpaceAddendum DF to the FreeSpaceAddendumContainer for this free space depends on the ITS-S implementation when the free space is within the reported cost map grid area specified by the LayeredCostMapContainer. Thus, the free space addition container can be interpreted even if the received CPM 200, 300 does not include the SensorInformationContainer. This can be the case when the sensor cannot utilize its entire DetectionArea to reliably provide a free space display, or when the shadowing model detailed in clause 7.5 of [TS103324] does not apply to a specific object (e.g., in the case of a radar sensor measuring two vehicles driving behind each other).

[0087] The free space addendum container has two possible uses, namely, the isotropic free space reliability provided by the SensorInformationContainer at level l1 does not apply to the entire DetectionArea of the sensor. Instead, a portion of the calculated shadowing area behind one of the objects has a different free space reliability at level l2 (e.g., as a result of the sensor fusion process). This area is described by providing the FreeSpaceArea DF as part of the FreeSpaceAddendum container. Additionally, the sensor system can only provide a free space reliability indication for a limited area within its DetectionArea. Different reliability levels l3 apply to the illustrated gray areas, represented as additional FreeSpaceAddendum containers.

[0088] The shadowingApplies DE of the FreeSpaceAddendum container is used to indicate whether a simple tracking method for calculating the shadowing area behind an object also applies to the area described in the FreeSpaceAddendum container.

[0089] If the transmitter also provides its own dimensions, the area occupied by the Tx ITS-S is also considered to be occupied.

[0090] Information regarding the geometric dimensions of the Tx ITS-S may be provided in additional transmission messages such as CPM 200, 300, or CAM.

[0091] For each sensor of one or several messages, the order given by the freeSpaceID of the FreeSpaceAddendum container provided overwrites, in ascending order, the reliability level indications of duplicate FreeSpaceAddendum containers for the same sensor. The reliability level indication l3 with freeSpaceID 2 overlaps with the reliability level l1 (from the SensorInformationContainer) and the reliability level l2 (from the first FreeSpace Addendum container with freeSpaceID 1), and thus represents the dominant reliability level indication within a given area. In some cases, FreeSpaceAddendum may be added with another CPM 200, 300. In these cases, the duplicate CPMs 200, 300 can be managed by numbering each freeSpace using the same freeSpaceID and describing the overlapping order between freeSpaces.

[0092] The FreeSpaceAddendumContainer may be placed outside a part of the detectionArea. Additionally or alternatively, the simplification of the shape description may be effective for reliability levels higher than 0. By providing the FreeSpaceAddendum container outside the detectionArea, a simpler shape of the FreeSpaceArea can be utilized to reduce the message size.

[0093] The mandatory freeSpaceConfidence DE of the FreeSpaceAddendum container represents the free space reliability applied to the area provided in the freeSpaceArea DF.

[0094] An optional list of sensorIds may be provided to link to the corresponding SensorInformationContainer and indicate which sensors provided the corresponding free space reliability indication.

[0095] 2.1.7. Hierarchical Cost Map (LCM) Container As shown in Figure 3, the CPM 300 includes a hierarchical cost map container. The hierarchical cost map container of type CpmPerceptionDataContainer, which includes the information object LayeredCostMapContainer, can exist to share the environment perceived by the ITS-S as a cost-based occupancy grid. It provides information about the perceived environment for the distributed ITS-S regarding the rectangular area around the distributed ITS-S. The hierarchical cost map container can be more efficient in certain situations such as the presence of a large number of objects in the FOV of the sensor in the ITS-S, or overlapping views of objects, or occlusion of objects. In some implementations, this container is added only to the selected cost map layers according to the inclusion rules defined in Clause 6.1.3.5 of [TS103324].

[0096] The hierarchical cost map container can be added to the CPM 300 to share the environment perceived by the Tx ITS-S as a cost-based occupancy grid with the corresponding confidence values. The hierarchical cost map container is a type CpmPerceptionDataContainer that includes the information object LayeredCostMapContainer. The hierarchical cost map container is added only to the selected cost map layers according to the inclusion rules described below and / or as defined in Clause 6.1.3.5 of [TS103324]. The hierarchical cost map container provides information about the overall environment perceived for the distributed ITS-S regarding the area (e.g., rectangular area) around the distributed ITS-S.

[0097] The container takes into account the grid-based representation of the cost map, and each cell carries the cost (e.g., indicating safe / cautious / fatal for driving through the cell) or occupancy indication that a particular type of obstacle / object / VRU 116 is present in the cell with a corresponding reliability level. All vehicles 110 can follow a global grid with the same size of cell representation (or hierarchical grid size).

[0098] The hierarchical cost map container is encoded as specified in Annex A of [TS103324]. More specifically, the following rules apply. Each ITS-S prepares a cost map for an area of the specified dimensions of its FOV (e.g., a rectangular area), and shares it with the neighbors where the area (e.g., a rectangular area) is further divided into smaller cells (e.g., rectangular cells where the rectangular area is divided into n cells by m cells, and n and m are numbers). This area (e.g., a rectangular area) is described by providing the ReportedCostMapGridArea DF as part of the LayeredCostMapContainer. The dimensions of each cell are described by GridCellSizeX and GridCellSizeY DE. The center of the reported grid area (e.g., a rectangular grid area) is specified relative to the reference position of the distributing ITS-S. One or more layers of the cost map can be included in the LayeredCostMapContainer. The number of cost map layers included in the LayeredCostMapContainer is specified by NumberOfLayeredCostMap DF. All reported cost map layers are prepared for the same grid area (e.g., a rectangular grid area) specified by the ReportedCostMapGridArea DF. The information of each reported cost map layer is provided by including one LayeredCostMap DF for each reported cost map layer.

[0099] The cost of each cell for each cost map layer is calculated by the distributed ITS-S based on its local sensor, information shared by neighbors (e.g., perceived objects shared by neighbors via CPM 200, 300), and the static map available to the transmitter. The cost of each cell for each cost map layer is specified together with a reliability level. The cost and reliability level of a cell can be specified in different formats, and the formats are specified by PerGridCellCostValueConfigType and PerGridCellConfidenceLevelConfigType DF for cost and reliability level respectively. For example, the cost value can be a 1-bit flag or indicator (e.g., occupied, not occupied), or several bits specifying the probability that an object / obstacle exists in the cell. Similarly, the reliability level can be a 1-bit indicator or flag (e.g., belowAThreshold, aboveOrEqualToAThreshold), or several bits specifying the reliability level (e.g., in the range from 0 to oneHundredPercent). Different cost map layers reported in the same LayeredCostMapContainer can have different cost and reliability level formats to optimize the size of CPM 300.

[0100] The Tx ITS-S can maintain a cost map layer of a different size (usually a larger size) for its own use compared to the size of the cost map layer prepared for sharing with neighbors. Additionally or alternatively, the Tx ITS-S may select a larger cost map cell size to reduce the size of the LayeredCostMapContainer in case of network congestion. The Tx ITS-S can also select a size optimization format (requiring fewer bits per cell) for the cost and reliability levels of one or more reported cost map layers in case of network congestion. An exemplary LayeredCostMapContainer in ASN.1 format is shown below.

Number

Number

Number

Number

Number

Number

Number

Number

[0101] 2.2. Hierarchical Cost Map Figures 4 and 5 show the hierarchical cost maps (LCM) 400 and 500 for CP. A cost map (or "costmap") is a data structure that includes a 2D grid of costs (or "cost values") used for path planning. In other words, the cost map represents the planned search space around V-ITS-S 110, VRU 116 / 117, robots, drones, or other movable objects. The grid or cell values of the cost map are the cost values associated with entering or moving to each grid or cell. The cost map is used to navigate or otherwise move in a dynamic environment where objects are dense. In many use cases, such as CA / AD vehicles and / or (semi-)autonomous robots, the movement path depends not only on considering the start and end destinations but also on having additional information about the larger context. The information about the environment used by the path planner is stored in the cost map. Conventional cost maps (also called "monolithic cost maps") store all data (costs) in a single grid. LCMs 400, 500 maintain an ordered list of layers, and each layer tracks data related to a specific function and / or sensor type. Then, the data from each layer is accumulated in an aggregation layer 410 (sometimes called the "master cost map 410").

[0102] As described above, reporting each of the perceived objects as an individual object can be very inefficient in scenarios such as when there are a large number of objects, when there are overlapping views of objects, and / or when there is occlusion of an object in the FOV of the sensor. A new container called "LayeredCostMapContainer" is added to CPMs 200, 300 to share LCM 400, enabling a compact and efficient sharing of the perceived environment among the proximity ITS-Ss under CPS.

[0103] To share the overall dynamic environment perceived by the Tx ITS-S as a cost-based occupancy grid, a hierarchical cost map container of type PerceptionData (LayeredCostMapContainer) is added to the CPM 200, 300.

[0104] The "cost" or cost value of each cell in the cost map represents the cost of navigating that grid cell. The LayeredCostMapContainer takes into account a grid-based representation of the cost map where each cell carries a cost (or cost value), or the probability that a particular type of obstacle, object, and / or VRU 116 / 117 is present in the cell. In some implementations, the state of each grid cell is one of free, occupied, or unknown. In these implementations, the cost value refers to the probability or likelihood that a given cell is free (unoccupied), occupied by an object, or unknown. In some implementations, the state of each grid cell can be one of safe, cautious, or lethal for driving through the cell. In these implementations, the cost value refers to the probability or likelihood that a given cell is safe to drive through, lethal to drive through, or somewhere in between safe and lethal (e.g., cautious). Additionally, the "cost" of the cost map can be the cost perceived by the station at the current time and / or the cost predicted for a particular future time (e.g., a future point in time when the station attempts to move into a new lane under a lane change operation). The ITS-S can follow a global grid with the same size cell representation and / or a hierarchical grid size of the cell representation. For the hierarchical cell size, the cell sizes are integer multiples of each other.

[0105] As shown in FIGS. 4 and 5, each ITS-S prepares and updates a plurality of layers or types of cost maps. The distributed ITS-S may prepare a plurality of layers or types (e.g., up to 8) of cost maps as shown in FIGS. 4 and 5. The LCM 400 maintains an ordered list of layers, each of which tracks data related to a specific function and / or sensor type, and the data of each layer is then accumulated in the aggregated cost map layer 410. Different layers have different rates of change, and thus, different layers are updated at different frequencies based on factors such as the speed of the vehicle, weather, environmental conditions, etc.

[0106] As shown in FIGS. 4 and 5, the aggregated layer 410 is prepared from other cost map layers (static layer 401, perceived object layer 402, inflation layer 403, and collective perception (CP) layer 404). The layers are updated upward from the "static map layer" 401 in the order shown in FIGS. 4 and 5 while preparing or updating the aggregated cost map layer 410. That is, the information of the static cost map layer 401 is first incorporated into the aggregated cost map layer 410, and then the information from the perceived object layer 402, inflation layer 403, and CP layer 404 is added.

[0107] The static cost map layer 401 maintains information about static or quasi-static objects and roadside infrastructure, while the other layers of the cost maps 400, 500 maintain information about dynamic objects and the costs resulting from the safety requirements of these objects. For example, the occupancy grid of the static map layer 401 represents roads and roadside permanent structures, the occupancy grid of the perceived object layer 402 represents roads and roadside obstacles (dynamic / static) perceived by local sensors, the occupancy grid of the inflation layer 403 represents the buffer area around obstacles or permanent structures, the occupancy grid of the CP layer 404 represents the perceived objects received from one or more neighbors, the occupancy grid of the inconsistency processing layer 405 indicates grid cells where there is an inconsistency between the cost value received for the grid cell and its own cost value or reliability level, and the occupancy grid of the collaboration request layer 406 indicates grid cells where the ego ITS-S was unable to determine perception at the required reliability level.

[0108] The static map layer 401 includes a static map of various static and / or quasi-static objects (e.g., roadside infrastructure, buildings, etc.) used for global planning. The static map 401 is an occupancy grid representing the permanent structure of the road / roadside. The static map layer 401 is pre-determined based on the static structure of the road and / or roadside.

[0109] The static map 401 can be generated using a simultaneous localization and mapping (SLAM) algorithm in advance or created from the architecture diagram. Since the static map is the bottom layer of the global LCM, the values of the static map may be directly copied to the aggregated cost map. If a station or robot is performing SLAM while using the generated map for navigation, the LCM approach allows the static map layer to be updated without losing information from other layers. In a monolithic cost map, the entire cost map is overwritten. The other layers of the LCM maintain information about dynamic objects and the costs due to the safety and privacy requirements of these objects.

[0110] The perceived object (obstacle) layer 402 includes determining the perceived objects that are obstacles to be considered during driving. The perceived object (obstacle) layer 402 collects data from high-precision sensors such as lasers (e.g., LiDAR), red-green-blue and depth (RGB-D) cameras, and arranges the collected high-precision sensor data into its own 2D grid. In some implementations, the space between sensors and sensor readings is marked as "free", and the positions of sensor readings are marked as "occupied". The method used to combine the values of the perceived obstacle layer with what is already in the cost map can vary depending on the desired level of confidence in the sensor data. In some implementations, the static map data may be overwritten using the collected sensor data, which can be beneficial in scenarios where the static map may be inaccurate. In other implementations, the obstacle layer can be configured to add only critical obstacles or VRU-related obstacles to the aggregated cost map.

[0111] The inflation layer 403 performs an inflation process that inserts a buffer region around critical obstacles and / or objects that may be moving. Positions where the VDU may definitely collide are marked with a critical cost, and the surrounding areas immediately have a small non-critical cost. These values ensure that the VDU does not collide with critical obstacles and attempts to avoid such objects. The updateBounds method increases the previous bounding box to ensure that new critical obstacles are inflated, and old critical obstacles outside the previous bounding box that may inflate within the bounding box are inflated as well.

[0112] The collective perception layer 404 includes the cumulative cost map / occupancy grid received from one or more neighboring ITS-Ss, and determines the cost of a cell based on the perceived objects indicated by the CPMs 200, 300 received from neighboring stations. The collective perception layer enables the ITS-S to update its cost map for areas where its (on-board) sensors may not have a "good" view or any view at all.

[0113] The collaboration request cost map layer 406 and the inconsistency handling cost map layer 405 enable collaboration between neighbors to achieve a better and more reliable cost map layer. The inconsistency handling layer 405 indicates and enables the resolution of perception inconsistencies between adjacent ITS-Ss. The inconsistency handling layer 405 designates cells for which the on-board sensors cannot determine the perception using a reliability level higher than a threshold. In some implementations, a majority voting mechanism may be used for this purpose, and the cost value of each cell is agreed upon by a majority vote among the participating ITS-Ss.

[0114] The collaboration request layer 406 enables the Tx ITS-S to request neighbors to help increase the cost of some cells for which the Tx ITS-S does not have a high enough reliability level to determine the value. The collaboration request layer 406 determines and designates the inconsistencies between the cost map received from neighboring ITS-Ss and the cost map perceived by local sensors. The collaboration request layer 406 designates cells for which the on-board sensors cannot determine the perception using a reliability level higher than and / or a threshold.

[0115] In some cases, neighboring vehicles may observe different cost values for some cells (e.g., due to sensing errors at one or more stations, different levels of field of view angles of sensors on vehicles for these cells, etc.). In such scenarios, the CP can help correct any discrepancies in the cost map. The discrepancy processing layer 405 is for indicating the discrepancies between neighboring cost values. After receiving the indication of the discrepancy in such a discrepancy processing layer 405, the node can re-evaluate the sensing and cost map calculations for these cells and share them among neighbors.

[0116] The collaboration request layer 406 enables a station to request from neighbors to help increase the cost of some cells for which the station may not have a high reliability level in determining the cost value. One or more neighbors can include the cost values perceived by their CPMs 200, 300 (and other information such as objects perceived in these cells). If available, the neighbor can, in this case, respond by sending unicast CPMs 200, 300.

[0117] Additionally or alternatively, a proxy layer (not shown in FIG. 4) may be included and used to detect objects and / or the space around individual objects. The proxy layer can also collect data from high-precision sensors such as lasers (e.g., LiDAR), RGB-D cameras. In some implementations, the proxy layer can use low-precision cameras or other similar sensors. The proxy layer can use the same or different sensor data or sensor types as the perceived obstacle layer. The proxy layer uses the position / location and velocity of the detected objects (e.g., extracted from sensor data representing individual VRUs) to write values to the cost map of the proxy layer, which are then added to the aggregated cost map along with the cost map values of other layers. In some implementations, the proxy layer uses a mixture of Gaussian distribution models and writes the Gaussian values of each object to the private cost map of the proxy layer. In some implementations, the generated values may be scaled according to amplitude, variance, and / or some other appropriate parameters.

[0118] The aggregated cost map layer 410 is updated periodically at a period T_Agg_CML_Update. T_Aggregated_CML_Update is selected to be shorter than or equal to the CPM generation event period (T_GenCpm). The static cost map layer 401 is updated immediately whenever a change in static or quasi-static objects and roadside infrastructure is identified. The CP layer 404 is updated whenever a new cost map layer or a new detected object is received from one or more neighbors. The CP layer 404 is also updated periodically to remove old information such as an object that is no longer reported by a neighbor. The inflated cost map layer 403 is updated whenever an object is detected by a local sensor or received from neighboring CPMs 200, 300, and the object requires a buffer region around it for safe driving. Periodic updates of the inflated cost map layer can be performed to reduce stale entries. The collaboration request cost map layer 406 and the inconsistency handling cost map layer 405 are not maintained in the ITS-S and are created on demand whenever selected to be included in the CPMs 200, 300. The ITS-S can check the need for the collaboration request cost map layer 406 and the inconsistency handling cost map layer 405 at each opportunity to include the LayeredCostMapContainer in the CPMs 200, 300.

[0119] The distributed ITS-S can share the aggregated cost map layer 410 and can share one or more of the other layers depending on the bandwidth or access layer congestion information. Each shared cost map layer type is specified by the CostMapLayerType DF. The collaboration request cost map layer 406 enables the distributed ITS-S to request neighboring ITS-Ss to help increase the reliability of some cells for which the distributed ITS-S does not have a high reliability level in order to determine values. The inconsistency handling cost map layer 405 indicates and enables the resolution of perception inconsistencies between neighbors.

[0120] Majority voting is one option where the cost value of each cell is agreed upon by majority voting. That is, the cost indicated by the majority of neighbors (or the average of nearby majority costs) is considered correct / agreed upon. Such agreement is performed for each cell that is individually inconsistent. All neighbors update the correct / agreed upon cost. Here, the votes of neighbors can be skewed based on their reliability and / or based on other criteria / parameters. Additionally or alternatively, more weight can be given to neighbors with better viewing angles, data quality, etc. to select the correct / agreed upon cost of the cell. In case of a mismatch in the cost map between neighbors, how the neighbor cost map reports are utilized depends on the ITS-S fusion algorithm implementation.

[0121] 2.2.1. Size Optimization of LCM Container Recently, in ETSI ITS WG1, there has been a discussion about how efficient CPM 200 and 300 based on a hierarchical cost map can be in terms of message size compared to CPM 200 and 300 based on perceived object containers and free space addition containers. New capabilities (e.g., DE / DF) are included in the hierarchical cost map container that provides a size-optimized hierarchical cost map container option to reduce the message size for transmission via the air interface, thereby reducing signaling overhead and saving resources.

[0122] (Of LayeredCostMap) DE perGridCellCostValueConfigType and perGridCellConfidenceLevelConfigType are added to enable a reduced size configuration of the hierarchical cost map container. For example, CostMapGridValueConfig2 and CostMapGridValueConfidenceConfig2 can be used to specify the cost value and confidence level of each grid cell of the reported rectangular grid area with fewer bits. [Number] [Number]

[0123] These DEs make it possible to optimize the size of the hierarchical cost map container based on the situation. For example, if the access layer indicates congestion (e.g., when access layer congestion is detected), a reduced size configuration of the hierarchical cost map container (e.g., CostMapGridValueConfig2 and CostMapGridValueConfidenceConfig2) can be selected to reduce the message overhead in the access layer.

[0124] Additionally or alternatively, when smaller-sized grid cells are reported, more cells are reported to cover the total grid area being reported. In such cases, a reduced size configuration of the hierarchical cost map container (e.g., CostMapGridValueConfig2 and CostMapGridValueConfidenceConfig2) can be used. The larger the size of the grid cell, the fewer the number of cells reported. Therefore, a normal size configuration of the hierarchical cost map container (e.g., CostMapGridValueConfig1 and CostMapGridValueConfidenceConfig1) can be selected.

[0125] Additionally or alternatively, if only one cost map layer (e.g., the aggregated cost map layer 410) is reported, the normal size configuration of the hierarchical cost map container (e.g., CostMapGridValueConfig1 and CostMapGridValueConfidenceConfig1) can be selected. If multiple layers of the cost map are reported, the reduced size configuration of the hierarchical cost map container (e.g., CostMapGridValueConfig2 and CostMapGridValueConfidenceConfig2) can be used.

[0126] In some cases, selecting the normal size configuration (e.g., CostMapGridValueConfig1 and CostMapGridValueConfidenceConfig1) for the hierarchical cost map container may result in a larger-sized hierarchical cost map container that requires segmentation of the CPM 200, 300. In such cases, to avoid segmentation or to reduce the number of segments of the CPM 200, 300, the reduced size configuration of the hierarchical cost map container (e.g., CostMapGridValueConfig2 and CostMapGridValueConfidenceConfig2) can be selected.

[0127] Flexibility also allows different layers of the cost map to use different configurations to optimize the overall hierarchical cost map container size. For example, the aggregated layer can be reported using the normal size configuration (e.g., CostMapGridValueConfig1 and CostMapGridValueConfidenceConfig1) to provide more detailed cost values. Other layers can be reported using the reduced size configuration (e.g., CostMapGridValueConfig2 and CostMapGridValueConfidenceConfig2).

[0128] The ranges of the gridCellSizeX and gridCellSizeY values are also optimized to reduce the message size.

Number

[0129] The reported length of the grid area is related to the number of cells reported vertically (or as an integer multiple of gridCellSizeX), and the reported width of the grid area is related to the number of cells reported horizontally (e.g., as an integer multiple of gridCellSizeY) to reduce the number of bits required to represent the cells. Absolute units for specifying the reported length and width of the grid area require more bits. Further, the reported length and width of the rectangular grid area are expected to be integer multiples of the cell size.

Number

[0130] A predefined grid cell count criterion in the specification for skipping reporting in the hierarchical cost map container. This provides the starting point of the cells to count and the direction to count the cells of the grid. For example, one way to predefine the grid cell count criterion could be as follows: the predefined starting point of the cells is cell #1 of the grid area of the reported cost map, the bottomLeft cell, and / or the predefined count direction is from left to right along the x-axis in the direction of the vehicle, and then move to the leftmost cell of the next row of the y-axis (going from bottom to top).

Number

[0131] 2.2.2. Reporting of the VRU cost map layer as a separate layer of the hierarchical cost map container The VRU 116 is a special class of perceived objects that require special safety measures for safe and secure ITS. Details of the VRU 116 and the various classes of VRU clusters (groups of adjacent VRUs with similar directions of travel and speeds) can be found in [AC3302] Error! Reference source not found. and [TS103300-3].

[0132] Figure 5 shows a modified hierarchical cost map 500 that includes the various layers described above with respect to Figure 4 and also includes a separate layer 502 for detected VRU and / or VRU cluster reports. Here, the detected VRUs and VRU clusters are reported as separate cost map layers 502 with the DE / DF of the hierarchical cost map container to enable reporting of VRUs and VRU clusters as separate cost layers. Since the VRU 116 can have a higher priority with respect to safety compared to other perceived objects, the VRU layer can be shared more frequently than the aggregated perceived obstacle layer and / or other layers of the cost maps 400, 500.

[0133] Changes to the hierarchical cost map container for the VRU layer are shown below in the ASN.1 encoding format defined in [SAE-J2735]. In this example, vruCostMapLayer is added to CostMapLayerType to indicate the VRU cost map layer.

Number

[0134] Two new cost configuration types, DF PerGridCellCostVruOccupancyConfig1 and DF PerGridCellCostVruOccupancyConfig2 of DF PerGridCellCostValue, are defined to specify the presence of various types of VRUs and / or VRU clusters within a grid cell.

Number

Number

[0135] 2.2.3. Hierarchical Cost Map Container CP Requirements and Cost Value Discrepancy Handling In a hierarchical cost map, the transmitting node shares the reliability level and cost value of each grid cell in the reported grid area based on the presence of obstacles / objects in the cell. ITS-S may not be able to determine the cost values of some grid cells with a sufficient reliability level (e.g., due to obstruction of the FoV of these cells). In such a case, ITS-S can obtain the cost values of these cells and request assistance from adjacent ITS-S to increase the reliability level. The hierarchical cost map container is further enhanced to enable such collaboration requests to be made more accurately and effectively. ITS-S indicates and resolves discrepancies in grid cell cost values among neighbors (e.g., when one or more received values differ from the node's own cost value). New DE / DF are provided herein to enable such discrepancy handling efficiently.

[0136] Optionally or additionally, a new PerGridCellCostValue type by providing a DF PerGridCellCostCollaborationRequest for effective collaboration requests. The collaboration request shall indicate at least the grid cell for which the self-node requests assistance to obtain a cost value, and the cost map layer for which such a request is made. A node can request collaboration for one or more cost map layers (e.g., aggregation layer, VRU layer, inflation layer, etc.). If no cost map type is specified, it is assumed to be for the aggregated cost map layer 410. Additionally, the DF enables the self-node to send its current determination of the cost value with its reliability level for these requested grid cells. The additional information reduces the number of responses from neighbors. For example, only neighbors with a higher reliability level for the cost values of these grid cells should respond.

[0137] The PerGridCellCostValue type is provided by the PerGridCellCostDiscripancyReport DF to effectively handle cost value discrepancies between neighboring ITS-Ss. The discrepancy report shall indicate at least the grid cell for which the self-node reports a discrepancy with the neighbor-reported cost value, and the cost map layer for which such a report is sent. A node can request discrepancy handling for one or more cost map layers (e.g., aggregation layer, VRU layer, inflation layer, etc.). If no cost map type is specified, it is assumed to be for the aggregated cost map layer 410. Additionally, the new DF enables the self-node to send the IDs of neighbor self-nodes that have a discrepancy with the cost value of at least one reported grid cell. The additional information can trigger the indicated neighbors to re-evaluate and / or update the cost values of these grid cells.

Number

Number

Number

[0138] When the cost map value of the cell corresponding to the cell where Tx ITS-S exceeds x% of its current cost map cells is different from the value reported by the neighbor by more than the threshold, and such a discrepancy has not been reported by the neighbor since the last CPM 200, 300 transmission of Tx ITS-S, if it is identified, ITS-S shall transmit the discrepancy handling cost map layer at the current CPM 200, 300.

[0139] When the cost map value of the cell corresponding to the VRU (e.g., person or animal) detected by the perception system of Tx ITS-S is different from the value reported by the neighbor by more than the threshold, and such a discrepancy has not been reported by the neighbor since the last CPM 200, 300 transmission of Tx ITS-S, if it is identified, ITS-S shall transmit the discrepancy handling cost map layer at the current CPM 200, 300.

[0140] When the on-board sensor of Tx ITS-S does not determine the perception using a reliability level higher than the threshold by more than y% of its current cost map cells, and Tx ITS-S did not include the collaboration request cost map layer in its last CPM 200, 300 transmission, ITS-S shall transmit the collaboration request cost map layer at the current CPM 200, 300.

[0141] If the neighbor requests assistance in determining the cost values of some cells of a specific cost map layer by transmitting the "collaboration request cost map layer" after the last CPM 200, 300 transmission of Tx ITS-S, ITS-S has the values of some or all of the requested cells, and the reliability level of these cost values is higher than any other response from other neighbors to this collaboration request, and ITS-S shall include that specific cost map layer in the current CPM 200, 300. The continuous inclusion of one or more layered cost maps (or cost map layers) into the LayeredCostMapContainer of CPM 200 and 300 can be performed when one or more of the following conditions are met.

[0142] 1. The LayeredCostMapContainer DF is added to the current CPM 200 and 300 when the difference between the current Euclidean distance of the NodeCenterPoint of the reported rectangular cost map grid area and the Euclidean distance of the NodeCenterPoint of the same reported rectangular cost map grid area that was last included in CPM 200 and 300 exceeds a predefined or configured threshold (e.g., 4 meters (m), etc.). 2. The LayeredCostMapContainer DF is added to the current CPM 200 and 300 when the difference between the current SemiRangeLength of the reported rectangular cost map grid area and the SemiRangeLength of the same reported rectangular cost map grid area that was last included in CPM 200 and 300 exceeds a predefined or configured threshold (e.g., 4 m, etc.). 3. The LayeredCostMapContainer DF is added to the current CPM 200 and 300 when the difference between the current semiMajorRangeOrientation of the reported rectangular cost map grid area and the semiMajorRangeOrientation of the same reported rectangular cost map grid area that was last included in CPM 200 and 300 exceeds a predefined or configured threshold (e.g., 4 degrees, etc.).

[0143] 2.2.4. CPM Segmentation and Inclusion Priority of CPM Segments in the Layered Cost Map Container If the size of the ASN.1 UPER encoded CPMs 200, 300 including all the perceived objects and cost map layer candidates selected for transmission exceeds the MTU_CPM, message segmentation may be performed. Each message segment should be interpretable without the need to receive all segments. Currently, the selected perceived object candidates are included in the CPM segments in descending order of the product of the object's reliability (if available) and speed. If the object reliability is not available, only the object speed is used for sorting in descending order.

[0144] When cost map sharing is enabled, the provisions for including the perceived objects and cost map layer candidates in the CPM segments may be as follows. i. The aggregated cost map layer 410 is selected to be included in the first segment, ii. Next, the perceived object candidates are included in descending order of the product of the object's reliability (if available) and speed, based on the existing provisions, iii. When all the selected objects are included in the segment, the remaining cost map layers are included, iv. If the size is acceptable, the remaining cost map layers are included in the last segment with the perceived objects, and if not, one or more new segments are generated to include all the remaining cost map layers, and v. The order of cost map layer inclusion in the segment is in descending order of the following priorities, i.e., the aggregated cost map layer 410, the perceived object (obstacle) cost map layer 402, the inflated cost map layer 403, the inconsistency cost map layer 405, the collaboration request cost map layer 406, the CP cost map layer 402, and the static cost map layer 401.

[0145] Additionally or alternatively, if CPM segmentation needs to include all the perceived objects and cost map layer candidates, one or more of the following actions are taken.

[0146] Additionally or alternatively, only the aggregated cost map layer 410 is included in the CPMs 200, 300 without segmentation. The perceived objects and the remaining cost map layer candidates are excluded from transmission. The Tx ITS-S may need to select a larger cost map cell size in order to reduce the size of the aggregated cost map layer 410 to fit the CPMs 200, 300.

[0147] Additionally or alternatively, all cost map layer candidates are included in the CPMs 200, 300 with a minimum number of CPM segments. The perceived object candidates are excluded from transmission. Note that the cost map layer must be fully contained within a segment (e.g., the cost map layer cannot be split into two CPM segments) so that each segment can be self - interpretable. If size permits, more than one cost map layer can be included in the same segment. The Tx ITS-S may need to select a larger cost map cell size in order to reduce the size of the cost map layer to fit a single CPM segment. Each CPM segment must be self - interpretable without the need to receive all or other segments.

[0148] 2.3. Implementation of ASN.1 LayeredCostMapContainer The following layered cost map DFs and DEs in the CPMs 200, 300 based on the format defined in 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]").

[0149] The first CPMs 200, 300 with DE and DF for a hierarchical cost map container for optimizing the size of this container are provided below.

Number

Number

Number

Number

Number

Number

Number

Number

Number

Number

[0150] Alternatively, the CPM DE and DF of a hierarchical cost map container with a separate VRU cost map layer 502, and the purpose of optimizing the size of the hierarchical cost map container are provided below.

Number

Number

Number

Number

Number

Number

Number

Number

Number

Number

Number

[0151] Another hierarchical cost map container is provided below that provides a perception of the cost value mismatch between neighbors and a collaboration request for efficient processing.

Number

Number

Number

Number

Number

Number

Number

Number

Number

Number

Number

Number

Number

[0152] 2.4.CPM Distribution The point-to-point communication specified in ETSI EN 302 636-3 V1.1.2 (2014-03) is used to transmit CPM 200 and 300.

[0153] 2.4.1.CPM Generation 2.4.1.1.CPM Generation Frequency Management The CPM generation event results in the generation of one CPM 200 or 300. The generated CPM 200 or 300 may be segmented according to Clause 6.1.4 of [TS103324] and / or modified as described herein. The minimum elapsed time between the starts of consecutive CPM generation events is greater than or equal to T_GenCpm. T_GenCpm is restricted to T_GenCpmMin ≤ T_GenCpm ≤ T_GenCpmMax, where T_GenCpmMin = 100 ms and T_GenCpmMax = 1000 ms.

[0154] In the case of ITS-G5, T_GenCpm should be managed according to the channel usage requirements of decentralized congestion control (DCC) as specified in ETSI TS 102 724. The parameter T_GenCpm should be provided by the management entity in milliseconds. If the management entity provides a value for this parameter that exceeds T_GenCpmMax, T_GenCpm should be set to T_GenCpmMax, and if the value is below T_GenCpmMin, or if this parameter is not provided, T_GenCpm should be set to T_GenCpmMin. The parameter T_GenCpm represents the currently effective lower limit of the elapsed time between consecutive CPM generation events. T_GenCpm represents the minimum time elapsed between two transmission events

[0155] In the case of LTE-V2X PC5, T_GenCpm is managed according to the congestion control mechanism defined by the access stratum in ETSI TS 103 574 2.4.1.2. Inclusion Management of Perceived Object Containers

[0156] The CPMs 200, 300 generated as part of the generation event include information about the perceived objects currently known to Tx ITS-S by adding the PerceivedObject DF to the PerceivedObjectContainer. If the object meets any of the following conditions, an object with a sufficient reliability level and not subject to redundancy reduction techniques is selected from the object list for transmission as a result of the current CPM generation event

[0157] 1. When the most highly reliability-assigned object class does not correspond to either the class of person or animal: a. The object has been first detected by the perception system after the last CPM generation event b. The Euclidean absolute distance between the current estimated position of the reference point of the object and the estimated position of the reference point of this object last included in CPM 200, 300 exceeds the minReferencePointPositionChangeThreshold. c. The difference between the current estimated ground speed of the reference point of the object and the estimated absolute speed of the reference point of this object last included in CPM 200, 300 exceeds the minGroundSpeedChangeThreshold. The difference between the vector direction of the current estimated ground speed of the reference point of the object and the estimated direction of the vector of the ground speed of the reference point of this object last included in CPM 200, 300 exceeds the minGroundVelocityOrientationChangeThreshold. d. The time elapsed since the object was last included in CPM 200, 300 exceeds T_GenCpmMax.

[0158] 2. When the most highly reliability-assigned object class corresponds to either the human or animal class: a. A new object (of the class human or animal) is detected after the last CPM generation event. b. If the object list contains at least one object of the class human or animal that was not included in CPM 200, 300 for a predefined or configured amount of time (e.g., the past 500 ms), then all objects of the class human or animal should be included in the currently generated CPM 200, 300.

[0159] The generation rules for objects of the class human or animal ensure that there is no individual inclusion cycle for the previously included objects of these two classes in order to reduce the message generation frequency.

[0160] To further reduce the number of messages generated, in each message generation event, objects that do not belong to any of the classes of people or animals included in CPM 200 and 300 in the next generation event (i.e., after T_GenCpm) may already be included in the currently generated CPM 200 and 300. For this purpose, assuming a constant speed model, for example, objects not selected for transmission in the currently generated CP messages can be predicted for the next CP message generation event (i.e., after T_GenCpm). Following this prediction, it is also possible to select all objects that need to be included in CPM 200 and 300 in the next generation event to be included in the currently generated CPM 200 and 300.

[0161] To further optimize the size of CPM 200 and 300 and the number of CPM message segments, CPM 200 and 300 are generated as part of the generation event that includes a hierarchical cost map by adding a LayeredCostMapContainer. Whether to include the perceivedObjectContainer or the LayeredCostMapContainer or both depends on the ITS-S implementation.

[0162] 2.4.1.3. Inclusion Management of Sensor Information Container CPM 200 and 300 generated as part of the generation event include a SensorInformationContainer every time the elapsed time since the last time CPM 200 and 300 were greater than or equal to T_AddSensorInformation elapses, where T_AddSensorInformation is some predefined or configured value (e.g., T_AddSensorInformation = 1000 ms).

[0163] 2.4.1.4. Inclusion Management of Free Space Addition Container The identified free space in CPM 200, 300 can be shown as part of the SensorInformationContainer. Clause 7.7 of [TS103324] details how the combination with the object described as free space indication (FreeSpaceConfidence DE of SensorInformationContainer) is combined to derive free space by using tracking and shadowing techniques. When LayeredCostMapContainer is included in CPM 200, 300, as described in clause 7.7 of [TS103324], the cost map grid values are also considered to derive free space. The FreeSpaceAddendumContainer is added whenever the free space area calculated at the receiving side using the simple tracking techniques detailed in clauses 7.5 and 7.7 of [TS103324] does not reflect the detected free space of the ITS subsystem that generates CPM 200, 300.

[0164] In the case of static information such as permanently shadowed areas, each time the SensorInformationContainer is added to the currently generated CPM 200, 300, the FreeSpaceAddendumContainer is added. Whether to include the FreeSpaceAddendum DF for that free space in the FreeSpaceAddendumContainer depends on the ITS-S implementation when the free space is within the reported cost map grid of the LayeredCostMapContainer.

[0165] CPM 200, 300 generated as part of a generation event can include additional information regarding the monitored free space known to the Tx ITS-S by adding the FreeSpaceAddendum DF to the freeSpaceAddendumContainer.

[0166] If a simple tracking method for calculating the free space of the receiving ITS-S does not match the representation of the detected free space of the Tx ITS-S, a specific FreeSpaceAddendum is added to CPM 200, 300. Successive inclusion of FreeSpaceAddendum in CPM 200, 300 is subject to the following.

[0167] 1. If a specific FreeSpaceAddendum DF adopts AreaPolygon DF, i.e., the Euclidean relative distance of any OffsetPoint of the polygon to the corresponding OffsetPoint of the polygon last included in CPM 200, 300 exceeds the minOffsetPointPositionChangeThreshold, or the number of OffsetPoints for describing the polygon changes, the FreeSpaceAddendum DF is added to the current CPM 200, 300. 2. When a specific FreeSpaceAddendum DF adopts AreaCircular DF, AreaEllipse DF, or AreaRectangle DF: a. If the difference between the current Euclidean distance of the NodeCenterPoint of the described free space area and the Euclidean distance of the NodeCenterPoint of the same described free space area last included in CPM 200, 300 exceeds the minNodeCenterPointPositionChangeThreshold, the FreeSpaceAddendum DF is added to the current CPM 200, 300. b. If the difference between the current radius or SemiRangeLength of the described free space area and the radius or SemiRangeLength of the same described free space area last included in CPM 200, 300 exceeds the minRadiusOrSemiRangeLengthChangeThreshold, the FreeSpaceAddendum DF is added to the current CPM 200, 300.

[0168] If the difference between the current semiMajorRangeOrientation of the described free space area and the semiMajorRangeOrientation of the same described free space area last included in CPMs 200, 300 exceeds the minSemiMajorRangeOrientationChangeThreshold, a FreeSpaceAddendum DF is added to the current CPMs 200, 300.

[0169] 2.4.1.5. Inclusion Management of Hierarchical Cost Map Containers CPMs 200, 300 are generated as part of a generation event and can include an updated hierarchical cost map available in Tx ITS-S by adding a LayeredCostMapContainer. The aggregated cost map layer 410 is included with zero or more other cost map layers such as the static cost map layer 401, the perceived object cost map layer 402, the inflated cost map layer 403, the CP cost map layer 404, the inconsistency handling cost map layer 405, and / or the collaboration request cost map layer 406 of the LayeredCostMapContainer of CPMs 200, 300.

[0170] The aggregated cost map layer 410 is selected for transmission as a result of the current CPM generation event under one or more of the following conditions. 1. The aggregated cost map layer 410 is added to the current CPMs 200, 300 if the grid cell cost value or grid cell confidence level, or both, of the cells changes by more than the minPercentageOfCellsWithAggregatedCostOrConfidenceChangeThreshold of the total cells in the ReportedCostMapGridArea compared to the grid cell cost value or grid cell confidence level last reported in CPMs 200, 300. 2. If the difference between the current Euclidean distance of the NodeCenterPoint of the reported rectangular cost map grid area and the Euclidean distance of the NodeCenterPoint of the reported rectangular cost map grid area last included in CPM 200, 300 exceeds minNodeCenterPointOfCostMapGridAreaPositionChangeThreshold, a LayeredCostMapContainer DF with an aggregated cost map layer 410 is added to the current CPM 200, 300. 3. If the difference between the current length (or width) of the reported rectangular cost map grid area and the length (or width) of the reported rectangular cost map grid area last included in CPM 200, 300 exceeds minLengthOrWidthChangeThreshold, a LayeredCostMapContainer DF with an aggregated cost map layer 410 is added to the current CPM 200, 300. 4. If the difference between the current orientation (semiMajorRangeOrientation) of the reported rectangular cost map grid area and the semiMajorRangeOrientation of the reported rectangular cost map grid area last included in CPM 200, 300 exceeds minSemiMajorRangeOfCostMapGridAreaOrientationChangeThreshold, a LayeredCostMapContainer DF with an aggregated cost map layer 410 is added to the current CPM 200, 300. 5. If the time elapsed since the aggregated cost map layer 410 was last included in CPM 200, 300 exceeds T_GenCpmMax, the aggregated cost map layer 410 is added to the current CPM 200, 300.

[0171] The inconsistency handling cost map layer 405 and / or the collaboration request cost map layer 406 are selected for transmission as a result of the current CPM generation event under one or more of the following conditions. 1. If the Tx ITS-S identifies that the grid cell cost value or the grid cell confidence level, or both, of the total cells in the reported cost map grid area exceeds the minPercentageOfCellsWithCostOrConfidenceDiscrepancyThreshold and is different from the grid cell cost value or the grid cell confidence level reported by the neighbors for the same cost map grid area, and such a discrepancy has not been reported by the neighbors since the last CPM 200, 300 transmission by this ITS-S, the ITS-S can send the discrepancy handling cost map layer 405 in the current CPM 200, 300. 2. If the on-board sensor in the Tx ITS-S cannot determine the perception using a confidence level higher than the minConfidenceLevelThreshold for more than the minPercentageOfCellsWithLowConfidenceLevelForCollaborationRequestThreshold of the total cells in its current aggregated cost map layer 410, and the Tx ITS-S did not include the collaboration request cost map layer 406 in its last CPM 200, 300 transmission, the ITS-S can send the collaboration request cost map layer 406 in the current CPM 200, 300.

[0172] Other cost map layers (e.g., the static cost map layer 401, the perceived object cost map layer 402, the inflated cost map layer 403, and / or the CP cost map layer 404 as described in section 7.8 of [TS103324] and / or) are optionally selected for transmission as a result of the current CPM 200, 300 generation event under one or more of the following conditions. 1. The cost map layer (e.g., the static cost map layer 401, the perceived object cost map layer 402, the inflated cost map layer 403, and / or the CP cost map layer 404 as described in section 7.8 of [TS103324] and / or) is added to the current CPM 200, 300 if the cost value or the confidence level, or both, of the cells of the cost map layer changes by more than the minPercentageOfCellsWithCostOrConfidenceChangeThreshold of the total cells of the ReportedCostMapGridArea compared to the grid cell cost value or grid cell confidence level last reported by the CPM 200, 300 of the same cost map layer. 2. If the time elapsed since the cost map layer was last included in the CPM 200, 300 exceeds the maxTimesSkipCostMapTransmission times T_GenCpmMax, the cost map layer is added to the current CPM 200, 300.

[0173] 2.4.2. CPM Segmentation The size of the generated CPM 200, 300 must not exceed the MTU_CPM supported by the CPS via the NF-SAP. The parameter of MTU_CPM (e.g., size) depends on the MTU of the access layer technology (MTU_AL) through which the CPM 200, 300 is transmitted. MTU_CPM must be less than or equal to MTU_AL minus the header size of the facility layer protocol (HD_CPM) and the header sizes of the networking and transport layer protocols (HD_NT), i.e., MTU_CPM ≦ MTU_AL - HD_CPM - HD_NT.

[0174] The MTU_AL technology for each access layer is defined in [EN302663], ETSI TS 103 613, and their references. The headers of the networking and transport layer protocols include the BTP header and the geonetworking header. The size of the BTP header is defined in ETSI EN 302 636-5-1, and the size of the geonetworking protocol header for each intended packet transport type is defined in ETSI EN 302 636-4-1.

[0175] Message segmentation occurs when the size of the ASN.1 UPER encoded CPM 200, 300, which includes all perceived objects and cost map layer candidates selected for transmission, exceeds the MTU_CPM. The order including the hierarchical cost map container and the perceived object container remains as per the ITS-S implementation. The selected perceived object candidates are included in the CPM 200, 300 segments in descending order of the object utility function defined as the sum of the following parameters for each object. ·p conf : 0 if the object reliability is unknown, unavailable, or equal to the minimum object reliability level, 1 if it is 100%, and linear interpolation between the minimum object reliability level and 100%. ·p pos : 0 if the Euclidean absolute distance between the current estimated position of the object's reference point and the estimated position of this object's reference point last included in the CPM 200, 300 is 0 m, 1 if it is 8 m or more, and linear interpolation between 0 and 8 m. p speed : 0 if the difference between the current estimated ground speed of the object's reference point and the estimated absolute speed of this object's reference point last included in the CPM 200, 300 is 0 m / s, 1 if it is 1 m / s or more, and linear interpolation between 0 and 1 m / s. ·p head: 0 if the difference between the direction of the vector of the current estimated ground speed of the reference point of the object and the estimated direction of the vector of the ground speed of the reference point of this object last included in CPM 200, 300 is 0 degrees, 1 if it is 8 degrees or more, and linear interpolation between 0 and 8 degrees. ·p time : 0 if the time elapsed since the object was last included in CPM 200, 300 is 0.1 s or less, 1 if it is 0.1 s or more, and linear interpolation between 0 and 1 s.

[0176] The selected cost map layer candidates are included in the CPM segment in descending order of the aggregated cost map layer 410, the perceived object cost map layer 402, the inflated cost map layer 403, the inconsistency handling cost map layer 405, the cooperation request cost map layer 406, the CP cost map layer 404, and the static cost map layer 401.

[0177] The segment should be input using the selected object as long as the size of the resulting ASN.1 UPER encoded message as a result of the segment to be generated does not exceed MTU_CPM. The segment is generated in this way until all selected perceived objects and selected cost map layers are included in the CPM segment. Each segment is transmitted at the next transmission opportunity.

[0178] If the SensorInformationContainer also needs to be transmitted and the size of the resulting ASN.1 UPER encoded CPM segment does not exceed MTU_CPM, it should be added to the CPM segment.

[0179] By this procedure, a CPM segment containing only the SensorInformationContainer can be generated. Message segmentation is indicated by inputting into the perceivedObjectContainerSegmentInfo DF. All message segments should indicate the same generationDeltaTime DE. The message segments should be transmitted in the same order in which they are generated. This is to ensure that segments containing higher priority objects are not deferred by the lower layer mechanisms for segments containing lower priority objects.

[0180] 2.4.3 CPM Time Requirements 2.4.3.1 CPM Generation Time In addition to the CPM generation frequency, the time required for CPM generation and the timeliness of the data for message construction are critical for the applicability of the data at the receiving ITS-S. To ensure proper interpretation of the received CPMs 200, 300, each CPM 200, 300 is time-stamped. Acceptable time synchronization between different ITS-Ss is expected.

[0181] The time required for CPM generation is less than 50 ms. The time required for CPM generation refers to the time difference between the time when CPM generation is triggered and the time when the CPMs 200, 300 are delivered to the network and transport layers.

[0182] 2.4.3.2 CPM Time Stamp The reference time stamp provided to the CPMs 200, 300 distributed by the ITS-S corresponds to the time when the reference position of the transmitting ITS-S provided to the CpmManagementContainer DF is determined. The format and range of the time stamp are defined in Clause B.3 of ETSI EN 302 637-2.

[0183] The difference between the CPM generation time and the reference timestamp must be less than 32,767 ms. The selection of the reference timestamp may depend on the architecture of the roadside equipment. For example, the reference timestamp can be selected by the sensor fusion system before requesting the generation of CPM 200, 300. This requirement is set to avoid the complexity of timestamp wraparound.

[0184] 2.4.4. Distribution Constraints of CPM 2.4.4.1. General Reliability Constraints Some data elements of CPM 200, 300 may vary with respect to accuracy and reliability. For these data elements, a data frame that provides the data elements together with reliability information is specified.

[0185] 2.4.4.2. Security Constraints The security mechanism of ITS considers the authentication of messages transferred between ITS-Ss using certificates. The certificate indicates the permission of its owner to send a specific set of messages and the optional privileges for specific DEs within these messages. The format of the certificate is specified in ETSI TS 103 097.

[0186] Within the certificate, the permission and privileges are indicated by a pair of identifiers, ITS-AID and SSP.

[0187] The ITS application identifier (ITS-AID) as given in ETSI TR 102 965 indicates the overall type of permission granted. For example, there is an ITS-AID indicating that the sender has the right to send CPM 200, 300.

[0188] The service specific permission (SSP) is a field that indicates a specific set of permissions within the overall permission indicated by the ITS-AID. For example, there may be an SSP value associated with the ITS-AID of CPM 200, 300 indicating that the sender has the right to send CPM 200, 300 in a specific role.

[0189] The received signed CPMs 200, 300 are accepted by the receiver if the certificate is valid and the CPMs 200, 300 match the ITS-AID and SSP of that certificate.

[0190] 2.4.4.3. General priority constraints The priority constraints are given by the traffic class as specified in ETSI EN 302 636-4-1.

[0191] 2.4.4.4. Indication of the quality and reliability of the data provided 2.4.4.4.1. Inclusion and reliability of objects The objects to be included in the CP message should be shared with other ITS-S for the purpose of enhancing traffic safety. Therefore, the shared objects are used by the safety application when receiving the ITS-S. Objects related to traffic safety are either static, i.e., not moving but located on the driving lane, or dynamic, i.e., moving or having the ability to move.

[0192] The purpose of the objects transmitted as part of the CP message is not to share traffic control information such as traffic signs and signal information, but to compare. Instead, data on objects that are not available to other ITS-S because their existence is temporary (e.g., traffic participants or temporary obstacles) should be prioritized.

[0193] The objects need to be placed on or adjacent to the driving lane (e.g., for pedestrians walking). To determine whether an object is located on the lane, the map matching algorithm on the distributed ITS-S can be used.

[0194] The methodology for calculating object reliability is consistent between Tx ITS-Ss to ensure that reliability indications can be clearly interpreted upon reception of CPM 200, 300. In sensor fusion systems, reliability calculations are usually implementation-specific and thus conflict with the requirements when sharing sensor data. Therefore, an appropriate reliability metric should be identified to provide a harmonized explanation (e.g., ISO / AUTOSAR).

[0195] 2.4.4.4.2. Free Space Reliability The receiver (Rx ITS-S) can derive the free space between objects by combining the reported detection area of the SensorInformationContainer and the reported objects. The optional freeSpaceConfidence DE of a specific SensorInformation should be used to notify that the Tx ITS-S can provide measurements regarding the actual verified free space that the receiving moving ITS-S can drive through.

[0196] The semantic segmentation process is an important step in identifying objects and free space within the purview of sensors Schumann et al., "Semantic Segmentation on Radar Point Clouds," 21st International Conference on Information Fusion (FUSION) (July 10, 2018) ("[Schumann]"), Yuan Wang et al., "PointSeg: Real-Time Semantic Segmentation Based on 3D LiDAR Point Clouds," arXiv:1807.06288v8 (September 25, 2018) ("[Yuan Wang]"). Depending on the sensor measurements and object fusion principles employed, the detected objects can be described using bounding boxes of a fixed size. By combining the sensing capabilities of the Tx ITS-S, i.e., the knowledge regarding its detection area, with the detected objects, the free space can be calculated by the receiving ITS-S. When classifying objects and free space, the applicable reliability levels should be determined using applicable methodologies (e.g., AI / ML techniques, see, e.g., Brotcm et al., "Determining the Reliability Level of Sensor Output Using Neural Networks," Department of Electrical Engineering, University of Saskatchwan, available at https: / / inis.iaea.org / collection / NCLCollectionStore / _Public / 28 / 075 / 28075825.pdf (1995)).

[0197] The reliability level of the free space can be defined as the ratio of the number of detected evidences of the free space to the total number of detection trials within a specified time period such as T_GenCpmMax. Specific techniques for semantic segmentation, multi-sensor data fusion, and reliability level calculation of objects / free space are outside the scope of this document, and any executable technique should be used.

[0198] 2.4.4.5. Redundancy Reduction Techniques Various redundancy techniques as discussed in ETSI TS 103 324 V0.0.17 (2020-04) (「[TS103324]」) and / or ETSI TR 103 562 V2.1.1 (2019-12) (「[TR103562]」) can be used.

[0199] 2.5. CPM Parameter Values The values used for the parameters described in this specification are provided by Tables 5 and 6.

[0200] Table 5 shows the parameters for CPM generation. The parameters may be set for an individual device or the entire system, may depend on external conditions, or may be independent of them. Table 5: Parameters for CPM Generation

Table 1-1

Table 1-2

Table 1-3

Table 1-4

[0201] The parameters in Table 6 manage ITS-S decisions for updating various cost map layers. The parameters may be set for an individual station or the entire system, may depend on external conditions, or may be independent of them. Table 6: Parameters for Cost Map Layer Update

Table 2

[0202] 3. Configuration and Arrangement of ITS Stations FIG. 6 shows the ITS-S reference architecture 600. Some or all of the components illustrated by FIG. 6 comply with the ITSC protocol based on the principles of the OSI model for a hierarchical communication protocol extended for ITS applications. The ITSC 600 includes an access layer 604 corresponding to OSI layers 1 and 2, a networking and transport (N&T) layer 603 corresponding to OSI layers 3 and 4, a facilities layer corresponding to at least some of the functions of OSI layers 5, 6, and OSI layer 7, and an application layer 601 corresponding to some or all of OSI layer 7. Each of these layers is interconnected via respective interfaces, SAPs, APIs, and / or other similar connectors or interfaces.

[0203] The application layer 601 provides ITS services, and ITS applications are defined within the application layer 601. An ITS application is an application layer entity that implements logic to fulfill one or more ITS use cases. ITS applications utilize the underlying facilities and communication capacity provided by ITS-S. Each application can be assigned to one of three identified application classes, namely, road safety, traffic efficiency, and other applications (see, e.g., [EN302663]), ETSI TR 102 638V1.1.1 (2009-06) (hereinafter "[TR102638]"). Examples of ITS applications can include driving assistance applications (e.g., for cooperative awareness and road hazard warning) such as AEB, EMA, and FCW applications, speed management applications, mapping and / or navigation applications (e.g., turn-by-turn navigation and cooperative navigation), applications that provide location-based services, as well as applications that provide networking services (e.g., global Internet services and ITS-S lifecycle management services). V-ITS-S 110 provides ITS applications to vehicle drivers and / or passengers and may require an interface to access in-vehicle data from the in-vehicle network or in-vehicle system. Due to deployment and performance requirements, a particular instance of V-ITS-S 110 can include a group of applications and / or facilities.

[0204] The facility layer 602 includes middleware, software connectors, software groups, etc., which contain a plurality of 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, and encryption), and the OSI session layer (e.g., host-to-host communication). A facility is a component that provides functions, information, and / or services to an application in the application layer and exchanges data with the lower layers to communicate its data with other ITS-Ss. Exemplary facilities include Cooperative Perception Service (CPS), Device Data Provider (DDP), Position and Time Management (POTI), Local Dynamic Map (LDM), Cooperative Awareness Basic Service (CABS) and / or Cooperative Awareness Basic Service (CABS), Signal Phase and Timing Service (SPATS), Vulnerable Road User Basic Service (VBS), Distributed Environment Notification (DEN) Basic Service, Manoeuvre Coordination Service (MCS), etc. In the case of V-ITS-S 110, the DDP is connected to the in-vehicle network and provides vehicle state information. The POTI entity provides the position and time information of the ITS-S. A list of common facilities is provided in ETSI TS 102 894-1 V1.1.1 (2013-08) (hereinafter "[TS102894-1]").

[0205] The CP service (CPS) (also called "CP basic service", etc.) is a facility layer entity in the ITS-S architecture as defined in [EN302665]. The CPS can interface with other entities in the facility layer and ITS applications in order to collect relevant information for CPM generation and transfer the received CPM 200, 300 content for further processing. FIG. 6 illustrates the CPS within the ITS-S architecture along with the logical interfaces to other layers and entities within the facility layer.

[0206] Collective Perception (CP) is a concept that shares the perceived environment of ITS-S based on perception sensors. In contrast to Cooperative Awareness (CA), ITS-S broadcasts information about its current (e.g., driving) environment rather than information about its current state. Thus, CP is a concept that actively exchanges locally perceived objects between different ITS-Ss by means of V2X communication technology (or V2X RAT). CP reduces the uncertainty around ITS-S by providing information within each other's fields of view. CPM 200, 300 enables ITS-S to share information about surrounding objects detected by sensors, cameras, or other information sources attached to or accessible by the Tx ITS-S.

[0207] CPS focuses on Tx data regarding the perceived environment rather than Tx data regarding the current state of the distributed ITS-S, and thus is fundamentally different from CA basic services (see, for example, ETSI EN 302 637-2 V1.4.1 (2019-04) (“[EN302637-2]”)). To avoid broadcasting CPM 200, 300 for the same object by multiple ITS-Ss, the CP service can filter the detected objects included in CPM 200, 300 (see, for example, clause 6.1 of [TS103324]).

[0208] Figure 6 shows CPS-specific functions, including interfaces mapped to the ITS-S architecture. The functions specific to CPS center around the CPS basic service 621 located in the facility layer. The CP basic service 621 is a facility of the ITS-S facility layer 602 that can be configured or operated to generate, receive, and process CPM.

[0209] CP basic service 621 can operate the CPM protocol, which is an ITS facility layer protocol for the operation of CPM 200 and 300 transmission (Tx) and reception (Rx). CPM 200 and 300 are CP basic service PDUs that include CPM data and ITS PDU headers. CPM data includes partial or complete CPM payloads and can include various data containers and related values / parameters as described herein. CPS basic service 621 consumes data from other services located in the facility layer and is linked to other application support facilities. CPS basic service 621 is responsible for the Tx of CPM 200 and 300.

[0210] Entities for collecting data for generating CPM 200 and 300 include device data provider (DDP) 624, PoTi 622, and LDM 623. In the case of the subsystem of V-ITS-S 110, DDP 624 is connected to the in-vehicle network and provides vehicle state information. In the case of the subsystem of R-ITS-S 130, DDP 624 is connected to sensors attached to roadside infrastructure such as poles, gantries, gates, and signage.

[0211] PoTi 622 provides the position and time information of ITS-S. LDM 623 is the database of ITS-S and can be updated with the received CAM and CPM data (see, for example, ETSI TR 102 863 v1.1.1 (2011-06)) in addition to the on-board sensor data. The ITS application can retrieve information from LDM 623 for further processing. CPS 621 also interfaces with the service announcement (SA) service 627 to generate CPM 200, 300 and can indicate the capabilities of ITS-S that provide details about the communication technology (e.g., RAT) used. Information specific to message distribution related to the current channel utilization is received by interfacing with the DCC-Fac entity 625. DCC-FAC 625 provides the congestion information of the access network to CPS 621.

[0212] Although not shown, CPS 621 can interface with other facility layer functions (or simply "facilities") such as MCS to coordinate their respective services / data with other layers. As examples, other facilities / services can include Cooperative Awareness Basic Service (CABS) and / or Cooperative Awareness Basic Service (CABS), Signal Phase and Timing Service (SPATS), Vulnerable Road User Basic Service (VBS), Distributed Environment Notification (DEN) Basic Service, Manoeuvre Coordination Service (MCS), etc. CPS 621 can also interact with the CPS profile management entity of the management layer for CPS-related purposes.

[0213] CPS 621 interfaces with the N&T layer 603 through the Network-Transport / Facility (NF)-Service Access Point (SAP) to exchange with other ITS-S and CPM 200, 300. The CPS interfaces with the security entity through the Security-Facility (SF)-SAP to access the security services of CPM 200, 300 Tx and CPM 200, 300 Rx. When the received CPM data is directly provided to the application, the CPS interfaces with the management entity through the Management-Facility (MF)-SAP and with the application layer through the Facility-Application (FA)-SAP. Each of the aforementioned interfaces / SAPs can provide full-duplex exchange of data with the facility layer and can implement appropriate APIs to enable communication between various entities / elements.

[0214] CPS 621 resides or operates in the facility layer 602, generates CPS rules, checks related services / messages, coordinates the transmission of CPM 200, 300 with other ITS service messages generated by other facilities and / or other entities within the ITS-S, and is then passed to the N&T layer 603 and the access layer 604 for transmission to other neighboring ITS-S. CPM 200, 300 is included in the ITS packet, which is a facility layer PDU passed to the access layer 604 via the N&T layer 603 or passed to the application layer 601 for consumption by one or more ITS applications. In this way, the CPM format is designed to enable the sharing of CPM 200, 300 without depending on the underlying access layer 604 and regardless of the underlying access technology / RAT.

[0215] Each of the aforementioned interfaces / Service Access Points (SAPs) can provide full-duplex exchange of data with the facility layer and can implement appropriate APIs to enable communication between various entities / elements.

[0216] In the case of V-ITS-S 110, the facility layer 602 is connected to the in-vehicle network via the in-vehicle data gateway as shown and described in [TS102894-1]. The facilities and applications of V-ITS-S 110 construct messages (e.g., CSM, VAM, CAM, DENM, MCM, and / or CPM 200, 300) and receive the necessary in-vehicle data from the data gateway for using the applications. To transmit and receive CAMs, the CA-BS includes the following entities, namely, an encoded CAM entity, a decoded CAM entity, a CAM transmission management entity, and a CAM reception management entity. To transmit and receive DENMs, the DEN-BS includes the following entities, namely, an encoded DENM entity, a decoded DENM entity, a DENM transmission management entity, a DENM reception management entity, and a DENM keep-alive transfer (KAF) entity. The CAM / DENM transmission management entity performs the protocol operations of the transmitting ITS-S, including activation and termination of the CAM / DENM transmission operation, determination of the CAM / DENM generation frequency, and triggering of the generation of CAM / DENM. The CAM / DENM reception management entity performs the protocol operations of the receiving ITS-S, including triggering the decoded CAM / DENM entity upon reception of CAM / DENM, provisioning the received CAM / DENM data to the LDM, facility, or application of the receiving ITS-S, discarding invalid CAM / DENM, and checking the information of the received CAM / DENM. The DENM KAF entity KAF stores the DENMs received during its validity period, transfers the DENMs when applicable, and the usage conditions of the DENM KAF can be defined by either the ITS application requirements or the cross-layer functions of the ITSC management entity 606. The encoded CAM / DENM entity constructs (encodes) the CAM / DENM to include various things, and the object list can include a list of DEs and / or DFs included in the ITS data dictionary.

[0217] The ITS station type / capability facility provides information that describes the profile of the ITS-S used in the application and facility layers. This profile indicates the ITS-S type (e.g., V-ITS-S 110, R-ITS-S 130, P-ITS-S, or central ITS-S), the role of the ITS-S, and the detection capabilities and status (e.g., the positioning ability, sensing ability, etc. of the ITS-S). The station type / capability facility can store the sensor capabilities of various connected / linked sensors and the sensor data obtained from such sensors.

[0218] The Position and Time Management Entity (PoTi) 622 manages the position and time information used by the ITS application, facility, network, management, and security layers. For this purpose, PoTi 622 obtains information from subsystem entities such as GNSS, sensors, and other subsystems of ITS-S. PoTi 622 ensures the ITS time synchronization among ITS-Ss in the ITS constellation, maintains data quality (e.g., by monitoring time deviation), and manages the updates of position (e.g., kinematic and attitude states) and time. The ITS constellation is a group of ITS-Ss that exchange ITS data among them. The PoTi entity 622 can include enhanced services for improving the accuracy, integrity, and reliability of position and time. Among these methods, communication technologies can be used to provide positioning assistance from mobile ITS-S to mobile ITS-S and infrastructure to mobile ITS-S. Considering the ITS application requirements regarding position and time accuracy, PoTi 622 can use enhanced services to improve position and time accuracy. Various enhancement methods can be applied. PoTi 622 can support these enhanced services by providing a message service that broadcasts enhanced data. For example, R-ITS-S 130 can broadcast correction information for GNSS to the opposing V-ITS-S 110, and the ITS-Ss can exchange raw GPS data or exchange terrestrial radio position and time-related information. PoTi 622 maintains and provides position and time reference information according to the application and facility and other layer service requirements in ITS-S. In the context of ITS, "position" includes attitude and movement parameters including speed, direction of travel, horizontal speed, and optionally others. The kinematic and attitude states of a rigid body included in ITS-S include position, speed, acceleration, orientation, angular velocity, and possibly other movement-related information. The position information at a specific instant is called the attitude state including the kinematics and time of the rigid body.In addition to the kinematic and pose states, the PoTi 622 should also maintain information regarding the reliability of the kinematic and pose state variables.

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

[0220] Local perception is provided by collecting 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, radars, LIDAR, etc.). Remote perception is provided by providing perception data via C-ITS (mainly V2X communication). Existing basic services such as cooperative awareness (CA), or more recent services such as collective perception service (CPS), can be used to transfer remote perception.

[0221] Subsequently, cooperative perception functions can be achieved using several perception sources. The consistency of these sources may be verified at a predefined instant, and if not consistent, the CP function may select the best according to the reliability levels associated with each perception variable. The results of CP should conform to the required accuracy levels specified by the PoTi. The relevant reliability levels may be necessary to construct CP resulting from fusion in case of differences between local and remote perception. They may also be necessary for exploitation by other functions of the CP results (e.g., risk analysis).

[0222] The perception function from device local sensor processing at the coordinated perception level to the final result may present a significant latency of several hundred milliseconds. To characterize the VRU trajectory and its speed development, a specific number of vehicle position measurements and speed measurements are required, thus increasing the overall latency of perception. As a result, it is necessary to estimate the overall latency of this function in order to take this into account when selecting a collision avoidance strategy.

[0223] Additionally or alternatively, in the context of CPS 621, existing infrastructure services as described herein can be used. For example, the broadcast of signal phase and timing (SPAT) and SPAT-related delimited areas (MAP) are already standardized and used by vehicles at the intersection level. In principle, they protect the 116 / 117 intersecting VRUs. However, there may be signal violation warnings, which can be detected and signaled using DENM. This signal violation indication using DENM is highly relevant to the VRU device 117 as indicating an increased risk of collision with a vehicle that has violated the signal. When using a local captor or detecting and analyzing the VAM, the signal controller can delay the change from the red phase to green to enable the VRU 116 / 117 to safely complete crossing the road. The context speed limit using in-vehicle information (IVI) can be adapted when a large cluster of VRUs 116 / 117 is detected (for example, limiting the speed of the vehicle to 30 km / h). At such low speeds, the vehicle 110 can operate efficiently when perceiving the VRU by its own local perception system.

[0224] The ITS management (mgmnt) layer includes the VRU profile mgmnt entity. The VRU profile management function is an important support element for the VBS 621 as it manages the VRU profile during a VRU active session. Profile management is part of the ITS-S configuration management and is then initialized with the values of typical parameters necessary to enable its operation. Also, the ITS-S configuration management is responsible for the updates required throughout the system's life cycle (e.g., new standard versions).

[0225] Referring back to FIG. 6, the N&T layer 603 provides the functions of the OSI network layer and the OSI transport layer and includes one or more networking protocols, one or more transport protocols, and network and transport layer management. Additionally, the sensor interface and the communication interface may be part of the N&T layer 603 and the access layer 604. The networking protocols can include, among others, IPv4, IPv6, IPv6 networking with mobility support, IPv6 over ZigBee networking, the CALM FAST protocol, etc. The transport protocols can include, among others, BOSH, BTP, GRE, ZigBee networking 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 a corresponding transport protocol.

[0226] The access layer includes a physical layer (PHY) 604 that physically connects to a communication medium, a data link layer (DLL) that can be subdivided into a media access control sublayer (MAC) that manages access to the communication medium, a logical link control sublayer (LLC), a management adaptation entity (MAE) for directly managing the PHY 604 and DLL, and a security adaptation 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. The CI is an instantiation of a specific access layer technology or radio access technology (RAT) and protocol, such as 3GPP (registered trademark) LTE, 3GPP (registered trademark) 5G / NR, C-V2X (e.g., based on 3GPP (registered trademark) LTE and / or 5G / NR), WiFi, W-V2X (e.g., including ITS-G5 and / or DSRC), DSL, Ethernet (registered trademark), Bluetooth (registered trademark), and / or any other RAT and / or communication protocol described herein, or combinations thereof. The CI provides the functionality of one or more logical channels (LCH), and the mapping of the LCH to a physical channel is specified by the standards of the associated specific access technology. As mentioned, the V2X RAT may include ITS-G5 / DSRC and 3GPP (registered trademark) C-V2X. Additionally or alternatively, other access layer technologies (V2X RAT) may be used in various other implementations.

[0227] The ITS-S reference architecture 600 may be applicable to the elements of FIGS. 9 and 11. The ITS-S gateways 911, 1111 (see, e.g., FIGS. 9 and 11) interconnect the OSI protocol stacks of OSI layers 5 through 7 in the facility layer. The OSI protocol stack is typically connected to a system (e.g., a vehicle system or a roadside system) network, and the ITSC protocol stack is connected to an ITS station internal network. The ITS-S gateways 911, 1111 (see, e.g., FIGS. 9 and 11) can convert protocols. Thereby, ITS-S can communicate with external elements of the system in which it is implemented. The ITS-S routers 911, 1111 provide the functions of the ITS-S reference architecture 600 except for the application layer and the facility layer. The ITS-S routers 911, 1111 interconnect two different ITS protocol stacks at layer 3. The ITS-S routers 911, 1111 can convert protocols. One of these protocol stacks is typically connected to an ITS station internal network. The ITS-S border router 1114 (see, e.g., FIG. 11) provides the same functions as the ITS-S routers 911, 1111 but includes a protocol stack related to an external network that may not follow the management and security principles of ITS (e.g., the ITS Mgmnt and ITS security layers of FIG. 6).

[0228] Additionally, 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 movement control for computer-assisted vehicles and / or automated vehicles when ITS-S is a vehicle (both the HMI and the vehicle movement control entity can be triggered by an ITS-S application), local device sensor systems and IoT platforms that collect and share IoT data, local device sensor fusion and actuator applications that include ML / AI and can aggregate data flows issued by the sensor system, local perception and trajectory prediction applications that consume the output of the fusion application and supply it to the ITS-S application, and related ITS-S. The sensor system can include one or more cameras, radars, LIDAR, etc. in V-ITS-S 110 or R-ITS-S 130. At the central station, the sensor system can be located roadside, but includes sensors that report their data directly to the central station without the involvement of V-ITS-S 110 or R-ITS-S 130. Optionally, the sensor system can further include gyroscopes, accelerometers, etc. (e.g., see sensor circuit 1572 in FIG. 15). These elements are described in more detail below with respect to FIGS. 9, 10, and 11.

[0229] FIG. 7 shows an exemplary CPS service function architecture. CPS is part of the application support domain of the facility layer according to [TS102894-1]. FIG. 7 also shows CPS and interfaces to other facilities and layers. To transmit and receive CPMs 200, 300, CPS includes an encoded CPM sub-function, a decoded CPM sub-function, a CPM transmission management sub-function, and a CPM reception management sub-function.

[0230] The symbolized CPM sub-function constructs CPM 200 and 300 according to the format specified in Annex A of [TS103324]. The latest abstract CP object information, sensor information, and free space information data are included in CPM 200 and 300. The decoded CPM sub-function decodes the received CPM 200 and 300.

[0231] The CPM transmission management sub-function performs protocol operations of the transmitting ITS-S, such as activating and terminating the CPM Tx operation, determining the CPM generation frequency, and triggering the generation of CPM 200 and 300.

[0232] The CPM reception management sub-function triggers the decoding of the CPM when receiving an incoming CPM, provisions the received CPM 200 and 300 to the Rx ITS-S's LDM and / or ITS application, and / or checks the validity of the information of the received CPM 200 and 300 (for details on checking the validity of the received CPM information, see, for example, ETSI TR 103 460), etc., and performs protocol operations of the receiving ITS-S.

[0233] Figure 8 shows an exemplary object data extraction level of the CP basic service. Part (a) of Figure 8 illustrates an implementation where sensor data is processed as part of a low-level data management entity. Subsequently, the CP basic service selects object candidates to be transmitted, as defined in Clause 4.3 of [TS103324] and [TR103562]. Since the task of high-level fusion is performed by the receiving ITS-S, part (a) is likely to avoid a filter cascade. Part (b) of Figure 8 illustrates an implementation where the CP basic service selects an object to be transmitted as part of CPM 200 and 300 from a high-level fusion object list according to Clause 4.3 of [TS103324] and [TR103562], thereby abstracting the original sensor measurements used in the fusion process. CPM 200 and 300 provide a data field indicating the source of the object.

[0234] Raw sensor data refers to low-level data generated by local perception sensors that are attached to or accessible by a vehicle or RSU. This data is specific to the sensor type (e.g., reflection, time-of-flight, point cloud, camera image, etc.). In the context of environmental perception, this data is typically analyzed and subjected to sensor-specific analysis processes to detect and calculate the mathematical representation of objects detected from the raw sensor data. IST-S sensors can provide raw sensor data as a result of their measurements, which is then used by sensor-specific low-level object fusion systems (e.g., sensor hubs, dedicated processors, etc.) to provide a list of objects detected by the sensor's measurements. The detection mechanisms and data processing capabilities are specific to each sensor and / or hardware configuration.

[0235] This means that the definition and mathematical representation of an object can change. The mathematical representation of an object is called a state space representation. Depending on the sensor type, the state space representation can include multiple dimensions (e.g., relative distance components of features to the sensor, speed of features, geometric dimensions, etc.). A state space is generated for each detected object of a particular measurement. Depending on the sensor type, measurements are performed periodically, regularly, and / or based on some defined trigger condition. After each measurement, the calculated state space of each detected object is provided to an object list specific to the timestamp of the measurement.

[0236] The object (data) fusion system maintains one or more lists of objects currently perceived by the ITS-S. The object fusion mechanism makes predictions for each object for time stamps when sensor measurements are not available, associates objects from other potential sensors attached to the station or received from other ITS-Ss with the objects in the tracking list, and merges the object predictions with the updated measurements. At each point in time, the data fusion mechanism can provide an updated object list based on continuous measurements from multiple sensors (possibly) including the state space of all tracked objects. V2X information from other vehicles (e.g., CAM, DENM, CPM 200, 300, etc.) may be additionally fused with the locally perceived information. Other approaches additionally provide alternative representations of processed sensor data such as occupancy grids.

[0237] The data fusion mechanism also performs various housekeeping tasks such as, for example, adding a state space to the list of objects currently perceived by the ITS-S when a new object is detected by a sensor, updating an object already being tracked by the data fusion system with new measurements that should be associated with the already tracked object, and removing an object from the list of tracked objects if the new measurements should not be associated with an already tracked object. Depending on the capabilities of the fusion system, objects can also be classified (e.g., some sensor systems can classify detected objects as specific road users, others can simply provide distance measurements to objects within the perception range). These tasks of object fusion can be performed by individual sensors or by a high-level data fusion system or process.

[0238] FIG. 9 illustrates an exemplary vehicle computing system 900. In this example, the vehicle computing system 900 includes a V-ITS-S 901 and an electronic control unit (ECU) 905. The V-ITS-S 901 includes a V-ITS-S gateway 911, an ITS-S host 912, and an ITS-S router 913. The vehicle ITS-S gateway 911 provides a function of connecting components of an in-vehicle network (e.g., ECU 905) to an ITS station internal network. Interfaces to in-vehicle components (e.g., ECU 905) may be the same as or similar to those described herein (e.g., refer to IX 1556 in FIG. 15), and / or may be unique interfaces / interconnections. Access to components (e.g., ECU 905) may be implementation-specific. The ECU 905 may be the same as or similar to the driving control unit (DCU) 174 described above with respect to FIG. 1. The ITS station is connected to an ITS ad-hoc network via the ITS-S router 913.

[0239] FIG. 10 illustrates an exemplary personal computing system 1000. The personal ITS subsystem 1000 provides ITSC applications and communication functions in mobile devices such as smartphones, tablet computers, wearable devices, PDAs, portable media players, laptops, and / or other mobile devices. The personal ITS subsystem 1000 includes a personal ITS station (P-ITS-S) 1001 and various other entities not included in the P-ITS-S 1001, which will be described in more detail below. The device used as the personal ITS station may also execute an HMI function as part of another ITS subsystem that connects to other ITS subsystems via an ITS station internal network (not shown). For the purposes of the present disclosure, the personal ITS subsystem 1000 may be used as a VRU ITS-S 117.

[0240] FIG. 11 illustrates an exemplary roadside infrastructure system 1100. In this example, the roadside infrastructure system 1100 includes an R-ITS-S 1101, an output device 1105, sensors 1108, and one or more radio units (RUs) 1110. The R-ITS-S 1101 includes an R-ITS-S gateway 1111, an ITS-S host 1112, an ITS-S router 1113, and an ITS-S border router 1114. The ITS station is connected to the ITS ad-hoc network and / or the ITS access network via the ITS-S router 1113. The R-ITS-S gateway 911 provides a function of connecting components of the roadside system (e.g., the output device 1105 and the sensors 1108) in the roadside network to the ITS station internal network. The interface to in-vehicle components (e.g., the ECU 905) may be the same as or similar to those described herein (e.g., see IX 1556 in FIG. 15), and / or may be a unique interface / interconnection. The access to components (e.g., the ECU 905) may be implementation-specific. The sensors 1108 can be induction loops and / or sensors that are the same as or similar to the sensors 172 described below with respect to FIG. 1 and / or the sensor circuit 1572 described below with respect to FIG. 15.

[0241] Actuator 1113 is a device responsible for the movement and control of a mechanism or system. Actuator 1113 is used to change the operating state (e.g., on / off, zoom, or focus, etc.), position, and / or orientation of sensor 1108. Actuator 1113 is used to change the operating state of several other roadside devices such as gates, signal lights, digital signage, or variable message signs (VMS). Actuator 1113 is configured to receive a control signal from R-ITS-S 1101 via the roadside network and convert the signal energy (or some other energy) into electrical and / or mechanical movement. The control signal may be a relatively low energy voltage or current. Actuator 1113 includes an electromechanical relay and / or a solid state relay, which is configured to switch the on / off of an electronic device and / or control a motor, and / or may be the same or similar or an actuator 1574 described below with respect to FIG. 15.

[0242] Each of FIGS. 9, 10, and 11 also shows entities not included in ITS-S that operate at the same level but include the associated HMIs 906, 1006, and 1106, vehicle movement control 908 (vehicle level only), local device sensor systems and IoT platforms 905, 1005, and 1105, local device sensor fusion and actuator applications 904, 1004, and 1104, local perception and trajectory prediction applications 902, 1002, and 1102, movement prediction 903 and 1003, or mobile object trajectory prediction 1103 (at the RSU level), and connected systems 907, 1007, and 1107.

[0243] Local device sensor systems and IoT platforms 905, 1005, and 1105 collect and share IoT data. The VRU sensor system and IoT platform 1005 are at least composed of PoTi management functions (see, for example, ETSI EN 302 890-2 (“[EN302890-2]”)) present in each ITS-S of the system. The PoTi entity provides a global time common to all system elements and the real-time position of mobile elements. Local sensors may also be incorporated into other mobile elements as well as road infrastructure (e.g., cameras of smart traffic lights, electronic signage, etc.). The IoT platform, which can be distributed across system elements, can contribute to providing additional information related to the environment surrounding the VRU system 1000. The sensor system can include one or more cameras, radars, LiDARs, and / or other sensors (see, for example, 1522 in FIG. 15) in the V-ITS-S 110 or R-ITS-S 130. In the VRU device 117 / 1000, the sensor system can include a gyroscope, an accelerometer, etc. (see, for example, 1522 in FIG. 15). At a central station (not shown), the sensor system can be located roadside, but includes sensors that report their data directly to the central station without the involvement of the V-ITS-S 110 or R-ITS-S 130.

[0244] (Local) sensor data fusion functionality and / or actuator applications 904, 1004, and 1104 provide fusion of local perception data obtained from a VRU sensor system and / or different local sensors. This can include aggregating data flows issued by the sensor system and / or different local sensors. Local sensor fusion and actuator applications can include machine learning (ML) / artificial intelligence (AI) algorithms and / or models. Sensor data fusion typically depends on the consistency of its inputs and then the consistency of their timestamps corresponding to a common given time. As described herein, sensor data fusion and / or ML / AL techniques can be used to determine the occupancy value of a DCROM.

[0245] Various ML / AI techniques can be used to perform sensor data fusion and / or can be used for other purposes such as a DCROM as described herein. If applications 904, 1004, and 1104 are (or include) AI / ML functions, applications 904, 1004, and 1104 can include an AI / ML model having the ability to learn useful information from input data (e.g., context information, etc.) according to supervised learning, unsupervised learning, reinforcement learning (RL), and / or neural network (NN). Separately trained AI / ML models can also be chained together in an AI / ML pipeline during inference or prediction generation.

[0246] The input data may include AI / ML training information and / or AI / ML model inference information. The training information includes, in addition to the input (training) data, data of an ML model including labels for supervised training, hyperparameters, parameters, probability distribution data, and other information necessary for training a specific AI / ML model. The model inference information is any information or data required as input to an AI / ML model for inference generation (or prediction). The data used by an AI / ML model for training and inference may largely overlap, but these types of information refer to different concepts. The input data is called training data and has known labels or results.

[0247] Supervised learning is an ML task aimed at learning the mapping function from input to output when a labeled dataset is given. Examples of supervised learning include regression algorithms (e.g., linear regression, logistic regression, etc.), instance-based algorithms (e.g., k-nearest neighbor, etc.), decision tree algorithms (e.g., classification and regression tree (CART), Iterative Dichotomiser 3 (ID3), C4.5, Chi-squared Automatic Interaction Detection (CHAID), etc.), fuzzy decision trees (FDT), etc.), support vector machines (SVM), Bayesian algorithms (e.g., Bayesian network (BN), dynamic BN (DBN), naive Bayes, etc.), and ensemble algorithms (e.g., extreme gradient boosting, voting ensemble, bagging (bootstrap aggregation), random forest, etc.). Supervised learning can be further grouped into regression and classification problems. Classification is related to the prediction of labels, and regression is related to the prediction of quantities. In the case of unsupervised learning, the input data is not labeled and has no known results. Unsupervised learning is an ML task aimed at learning the 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 (NN) are usually used in supervised learning but can also be used in unsupervised learning. Examples of NN include deep NN (DNN), feedforward NN (FFN), deep FNN (DFF), convolutional NN (CNN), deep CNN (DCN), deconvolutional NN (DNN), deep belief NN, perceptron NN, recurrent NN (RNN) (including, for example, long short-term memory (LSTM) algorithm, gated recurrent unit (GRU), etc.), deep stacking network (DSN). Reinforcement learning (RL) is goal-directed 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-armed bandit learning, and deep RL.

[0248] In one example, ML / AI technology is used for object tracking. Object tracking and / or computer vision technology can include, for example, edge detection, corner detection, blob detection, Kalman filters, mixture of Gaussians models, particle filters, kernel tracking based on mean shift, ML object detection techniques (such as Viola-Jones object detection framework, scale-invariant feature transform (SIFT), histogram of oriented gradients (HOG), etc.), deep learning object detection techniques (such as fully convolutional neural network (FCNN), region proposal convolutional neural network (R-CNN), single-shot multibox detector, "you only look once" (YOLO) algorithm, etc.).

[0249] In another example, the ML / AI technology is used for motion detection based on y sensor data obtained from one or more sensors. Additionally or alternatively, the ML / AI technology is used for object detection and / or classification. An object detection or recognition model can include a registration phase and an evaluation phase. During the registration phase, one or more features are extracted from the sensor data (e.g., image or video data). A feature is an individual measurable property or characteristic. In the context of object detection, object features can include object size, color, shape, relationship to other objects, and / or any region or part of an image such as edges, protrusions, corners, blobs, and / or some defined regions of interest (ROIs). The features used can be implementation-specific and can be based, for example, on the objects to be detected and the model to be developed and / or used. The evaluation phase includes identifying or classifying an object by comparing the acquired image data with an existing object model created during the registration phase. During the evaluation phase, the features extracted from the image data are compared with the object identification model using appropriate pattern recognition techniques. The object model can be a qualitative or functional description, geometric surface information, and / or an abstract feature vector, and can be stored in an appropriate database organized using a certain type of indexing scheme to facilitate the elimination of unlikely object candidates from consideration.

[0250] Composite information can be generated using any suitable data fusion or data integration technique. For example, the data fusion technique may be a direct fusion technique or an indirect fusion technique. Direct fusion combines data directly obtained 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 vUE or sensor types, historical data, etc.). Indirect fusion utilizes historical data and / or known characteristics of the environment and / or human input to generate an improved data set. Additionally, the data fusion technique can include one or more fusion algorithms such as a smoothing algorithm (e.g., estimating a value using multiple measurements either in real-time or not in real-time), a filtering algorithm (e.g., estimating the state of an entity using current and past measurements in real-time), and / or a predictive state estimation algorithm (e.g., analyzing historical data (e.g., geographical location, speed, direction, and signal measurements) in real-time to predict a state (e.g., future signal strength / quality at a specific geographical location coordinate)). By way of example, the data fusion algorithm can be a structure-based algorithm (e.g., tree-based (e.g., minimum spanning tree (MST)), cluster-based, grid and / or centralized-based), a structure-free data fusion algorithm, a Kalman filter algorithm and / or an extended Kalman filtering, a fuzzy-based data fusion algorithm, an ant colony optimization (ACO) algorithm, a fault detection algorithm, a Dempster-Shafer (D-S) evidence-based algorithm, a Gaussian mixture model algorithm, a fusion algorithm based on triangulation, and / or any other similar data fusion algorithm, or can include them.

[0251] The local perception functions (which may or may not include the trajectory prediction application) 902, 1002, and 1102 are provided by local processing of information collected by local sensors associated with the system elements. The local perception (and trajectory prediction) functions 902, 1002, and 1102 consume the outputs of the sensor data fusion applications / functions 904, 1004, and 1104 and supply perception data (and / or trajectory prediction) to the ITS-S applications. The local perception (and trajectory prediction) functions 902, 1002, and 1102 detect and characterize objects (stationary and mobile) that are likely to cross the trajectories of the moving objects under consideration. The infrastructure, particularly the road infrastructure 1100, can provide services related to the VRU support service. The infrastructure can have its own sensors to detect the development of VRUs 116 / 117 directly via its own sensors or remotely via cooperative perception support services such as CPS (see, for example, [TR103562]) and then calculate the risk of collision if it also detects the development of local vehicles. Additionally, since VRUs 116 / 117 typically have to comply with these markings / signs, the reliability levels associated with VRU detection and mobility can be increased by considering road markings (e.g., zebra areas or crosswalks) and vertical signs.

[0252] The movement dynamic prediction functions 903 and 1003, and the mobile object trajectory prediction 1103 (at the RSU level) are related to predicting the behavior of the mobile objects to be considered. The movement dynamic prediction functions 903 and 1003 predict the trajectories of the vehicle 110 and the VRU 116, respectively. The movement dynamic prediction function 903 may be part of the VRU trajectory and behavior modeling module and the trajectory blocking module of the V-ITS-S 110. The movement dynamic prediction function 1003 may be part of the dead reckoning module and / or the movement detection module of the VRU ITS-S 117. Alternatively, the movement dynamic prediction functions 903 and 1003 can provide movement / motion prediction to the aforementioned modules. Additionally or alternatively, the mobile object trajectory prediction 1103 predicts the respective trajectories of the corresponding vehicle 110 and VRU 116, which can be used to assist the VRU ITS-S 117 and / or the V-ITS-S 110 when performing dead reckoning using the VRU trajectory and behavior modeling entity.

[0253] Movement dynamic prediction includes the mobile object trajectory resulting from the development of successive mobile positions. Changes in the mobile object trajectory or the mobile object speed (acceleration / deceleration) affect the movement dynamic prediction. Most of the time, when the VRUs 116 / 117 are moving, they still have a large number of possible kinematics regarding possible trajectories and speeds. This means that the movement dynamic predictions 903, 1003, 1103 are used to identify which kinematics are selected as quickly as possible by the VRU 116 and whether this selected kinematics is at risk of collision with another VRU or vehicle.

[0254] The movement dynamic prediction functions 903, 1003, 1103 analyze the development of mobile objects and the potential trajectories that may intersect at a given time to determine the risk of collision between them. Movement dynamic prediction acts on the output of cooperative perception considering the current trajectory of the devices (e.g., VRU device 117) being considered, for the calculation of route prediction, the current speed of the mobile considered for the calculation of speed development prediction and their past development, and the level of reliability that can be associated with these variables. The output of this function is provided to the risk analysis function.

[0255] Often, due to the uncertainties that exist regarding VRU trajectory selection and its speed, acting only on the output of cooperative perception is not sufficient to make reliable predictions. However, complementary functions can assist in consistently enhancing the reliability of the prediction. For example, the use of a device (e.g., VRU device 117) navigation system that provides assistance to the user (e.g., VRU 116) to select the best trajectory to reach the planned destination. The development of Mobility as a Service (MaaS) as a service can also indicate danger areas to the VRU 116 and then assist in movement dynamic prediction at the level of the multi-modal journey provided by the system. In another example, knowledge of the user's (e.g., VRU 116) habits and behavior can be additionally or alternatively used to improve the consistency and reliability of movement prediction. Some users (e.g., VRU 116 / 117) follow the same journey using similar dynamics, for example, when going to a main Point of Interest (POI), which is related to the user's main activities (e.g., going to school, going to work, shopping, going to the nearest public transport station from home, going to the sports center, etc.). A device (e.g., VRU device 117) or a remote service center can learn and remember these habits. In another example, the display by the user (e.g., VRU 116) itself of the selected trajectory, especially when changing the selected trajectory (e.g., using a right or left turn signal similar to a vehicle when indicating a direction change).

[0256] The vehicle motion control 908 may be included in the computer-assisted vehicle and / or the automated vehicle 110. Both the HMI entity 906 and the vehicle motion control entity 908 may be triggered by one or more ITS-S applications. The vehicle motion control entity 908 may be a function under the responsibility of a human driver or the vehicle when it can operate in an automatic mode.

[0257] The human-machine interfaces (HMIs) 906, 1006, and 1106, when present, enable the configuration of initial data (parameters) in management entities (e.g., VRU profile management) and other functions (e.g., VBS management). The HMIs 906, 1006, and 1106 enable communication to the device owner (user) of external events related to the VBS, including warning about an immediate risk of collision (TTC < 2 s) detected by at least one element of the system and signaling a risk of collision (e.g., TTC > 2 s) detected by at least one element of the system. In the case of a VRU system 117 similar to a vehicle driver (e.g., a personal computing system 1000), the HMI provides information to the VRU 116 taking into account its profile (e.g., in the case of a visually impaired person, the information is presented at a clear voice level using the accessibility capabilities of a specific platform of the personal computing system 1000). In various implementations, the HMIs 906, 1006, and 1106 may be part of an alarm system.

[0258] The connected systems 907, 1007, and 1107 refer to components / devices used to connect a system to one or more other systems. By way of example, the connected systems 907, 1007, and 1107 can include communication circuits and / or wireless units. The VRU system 1000 may be a connected system composed of up to four different levels of devices. The VRU system 1000 may also be an information system that collects information resulting from events in real time, processes the collected information, and stores them together with the processed results. At each level of the VRU system 1000, information collection, processing, and storage are related to the functions being performed and the data delivery scenarios.

[0259] 4. Computer-Assisted Autonomous Driving Platforms and Technologies Except for the UVCS technology of the present disclosure, the vehicle-mounted system 101 and the CA / AD vehicle 110 may be any one of several vehicle-mounted systems and CA / AD vehicles, from computer-assisted vehicles to partially or fully autonomous vehicles. Additionally, the vehicle-mounted system 101 and the CA / AD vehicle 110 can include other components / subsystems not shown in FIG. 1, such as those shown and described elsewhere in this specification (see, e.g., FIG. 15). These and other elements of the underlying UVCS technology used to implement the vehicle-mounted system 101 are further described with reference to the remaining FIGS. 12-14.

[0260] FIG. 12 shows an exemplary UVCS interface 1200. The UVCS interface 1200 is a modular system interface designed to couple a pluggable computing module (having computing elements such as a CPU, memory, storage, radio, etc.) to an in-vehicle computing hub or subsystem (having peripheral components such as power, management, I / O devices, automotive interface, thermal solution, etc.) pre-deployed in a vehicle to form an instance of the UVCS for the vehicle. Different computing elements, or different pluggable computing modules having different functions or capabilities, can be employed to mate with the in-vehicle computing hub / subsystem pre-deployed in the vehicle to form different instances of the UVCS. Thus, the computing capability of a vehicle having an in-vehicle computing hub / subsystem pre-deployed can be upgraded by mating it with a newer, more functional, or more capable pluggable computing module pre-deployed in the in-vehicle computing hub / subsystem and replacing the previous old, less functional, or less capable pluggable computing module.

[0261] In the example of FIG. 12, the UVCS 1200 includes a fixed section 1202 and a configurable section 1204. The fixed section 1202 includes a dynamic power input interface 1212 (also called a dynamic power supply interface) and a management channel interface 1214. The configurable section 1204 includes several configurable I / O (CIO) blocks 1216a - 1216n.

[0262] The dynamic power input interface 1212 is arranged to supply power from the in-vehicle computing hub / subsystem to the computing elements of the pluggable computing module plugged into the UVCS interface 1200 in order to mate with the in-vehicle computing hub to form an instance of the UVCS. The management channel interface 1214 is arranged to facilitate the in-vehicle computing hub when managing / adjusting the operation of itself and the pluggable computing module plugged into the UVCS interface 1200 to form an instance of the UVCS. The CIO blocks 1216a - 1216n are arranged to facilitate various I / Os between the various computing elements of the pluggable computing module and the peripheral components of the in-vehicle computing hub / subsystem mated with each other through the UVCS interface 1200 to form an instance of the UVCS. The I / O between the computing elements of the pluggable computing module and the peripheral components of the in-vehicle computing hub / subsystem mated therewith varies for each instance according to the computing elements of the pluggable computing module used to mate with the in-vehicle computing hub to form a particular instance of the UVCS. At least some of the CIO blocks 1216a - 1216a are arranged to facilitate high-speed interfaces.

[0263] The CIO blocks 1216a - 1216n represent a set of electrically similar high-speed differential serial interfaces, enabling a configuration of interface types and specifications that may actually be used. In this way, different UVCS computing hubs can connect different peripheral devices to the same UVCS interface 1200, enabling different peripheral devices to perform I / O operations with different I / O protocols using the computing elements of the UVCS module.

[0264] The number of CIO blocks 1216a to 1216n may depend on the use cases and / or implementations of different market segments. For example, for an implementation designed for the low-end market, there may be fewer CIO blocks 1216a to 1216n (e.g., 2 to 4). On the other hand, for an implementation designed for a more high-end market, there may be more CIO blocks 1216 to 1216n (e.g., 8 to 16). However, to achieve the best possible interoperability and upgradeability, for a given UVCS generation, the number and functionality / configurability of the CIO blocks may remain the same.

[0265] Figure 13 shows an exemplary UVCS 1300 formed using a UVCS interface. As shown, the UVCS interface, which may be the UVCS interface 1200 and which may be one of one or more UVCSs of the in-vehicle system 101 of FIG. 1, is used to facilitate the mating of a UVCS module that can be plug-connected to a pre-deployed UVCS hub in the vehicle to form a UVCS 1300 for the vehicle. The UVCS interface, as the UVCS interface 1200, includes a fixed section and a configurable section. The fixed section includes a dynamic power supply interface (DynPD) 1332 and a management channel (MGMT) interface 1334. The configurable section includes several configurable I / O interfaces (CIO), PCIe1..x, CIO1..x, CIOy..z, CIOa..b, CIOc..d.

[0266] The pre-configured UVCS hub includes a power supply and a system management controller. Further, the UVCS hub includes a debug interface 1344, interface devices, level shifters, a power supply, a system management controller, and several peripheral components 1352 such as an audio and amplifier, 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, software-defined radio (SDR)), as shown and coupled to each other. Additionally or alternatively, the UVCS hub may include more or fewer, or different, peripheral elements.

[0267] The pluggable UVCS module 1306 includes a SoC (e.g., a CPU, a GPU, an FPGA, or other circuitry), memory, a power input + supply circuit, a housekeeping controller, and a CIO multiplexer (MUX). Further, the UVCS module includes a hardware accelerator, a persistent mass storage, and a communication module (e.g., BT, WiFi, 5G / NR, LTE, and / or other similar interfaces) as enumerated above and coupled to each other as shown. Additionally or alternatively, the UVCS module may include more or fewer, or different, computing elements.

[0268] The power supply of the UVCS hub supplies power to the computing elements of the UVCS module via the DynPD 1332 of the UVCS interface and the power input + supply circuit of the UVCS module. The system management controller of the UVCS hub manages and adjusts its operation and the operation of the computing elements of the UVCS module via the management channel 1334 of the UVCS interface and the housekeeping controller of the UVCS module. The CIO MUX is configurable or operable to provide multiple I / O channels of different I / O protocols between the computing elements of the UVCS module and the peripheral components of the UVCS hub via the UVCS interface, interface devices, and configurable I / O blocks of the level shifter of the UVCS hub. For example, one of the I / O channels can provide I / O between the computing elements of the UVCS module and the peripheral components of the UVCS hub according to the PCIe I / O protocol. Another I / O channel can provide I / O between the computing elements of the UVCS module and the peripheral components of the UVCS hub according to the USB I / O protocol. Still 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.

[0269] The housekeeping controller is configurable or operable to control power supply in the supply of power to static and dynamic loads and the consumption of power by static and dynamic loads based on the operating context of the vehicle (e.g., whether the vehicle is in a "cold crank" or "cold start" scenario). The housekeeping controller is configurable or operable to control the power consumption of static and dynamic loads by selectively initiating a sleep state, reducing the clock frequency, or turning off static and dynamic loads.

[0270] The management channel 1334 can be a small form factor low pin count serial interface, a universal asynchronous receiver-transmitter (UART) interface, a universal synchronous and asynchronous receiver-transmitter (USART) interface, a USB interface, or some other suitable interface (including any of the other IX technologies described herein). Additionally or alternatively, the management channel may be a parallel interface such as an IEEE 1284 interface.

[0271] The CIO block of the UVCS interface represents a set of electrically similar high-speed interfaces (e.g., high-speed differential serial interfaces) and enables the configuration of the type and standard of the interface actually used in some cases. In particular, the housekeeping controller is arranged to configure the CIO MUX to provide multiple I / O channels through various CIO blocks to facilitate I / O operations in different I / O protocols. Additionally or alternatively, the multiple I / O channels include USB I / O channels, PCIe I / O channels, HDMI (registered trademark) and DP (DDI) I / O channels, as well as Thunderbolt (TBT) I / O channels. The multiple I / O channels can also include other I / O channel types (xyz [1..r]) in addition to the enumerated I / O channel types.

[0272] Additionally or alternatively, the CIO multiplexer has sufficient circuit paths configurable to multiplex any given combination of the I / O interfaces exposed by the SoC to any of the connected CIO blocks. Additionally or alternatively, the CIO MUX can support a limited multiplexing scheme, such as when the CIO block supports a limited number of I / O protocols (e.g., does not provide PCIe support but supports a display interface and Thunderbolt). Depending on the implementation, the CIO MUX may be integrated as part of the SoC.

[0273] 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 the UVCS module. The power budget / contract can provide the minimum and maximum voltages, the current / power needs of the UVCS module, and, if any, the current power supply limits of the UVCS interface. This enables the evaluation of the compatibility of a given pair of UCS hub and module, as well as the operational advantages.

[0274] Figure 14 is a software component view of an exemplary in-vehicle system formed by UVCS. As shown, an in-vehicle system 1400 that can be formed by UVCS 1300 includes hardware 1402 and software 1410. Software 1410 includes a hypervisor 1412 that hosts several virtual machines (VMs) 1422-1428. The hypervisor 1412 can be configured or operable to host the execution of VMs 1422-1428. The hypervisor 1412 can also implement some or all of the functions described above for the system management controller of the UVCS module. By way of example, the hypervisor 1412 can be a KVM hypervisor, Xen provided by Citrix, VMware provided by VMware, and / or any other suitable hypervisor or VM manager (VMM) technology as described herein. VMs 1422-1428 include a service VM 1422 and several user VMs 1424-1428. The service machine 1422 includes a service OS that hosts the execution of several instrumentation cluster applications 1432. By way of example, the service OS of the service VM 1422 and the user OS of the user VMs 1424-1428 can be, for example, Linux (registered trademark) available from Red Hat Enterprise in Raleigh, North Carolina, Android (registered trademark) available from Google in Mountain View, California, and / or any other suitable OS as described herein.

[0275] The user VMs 1424 - 1428 can include a first user VM 1424 having a first user OS that hosts the execution of the front seat infotainment application 1434, a second user VM 1426 having a second user OS that hosts the execution of the rear seat infotainment application 1436, a third user VM 1428 having a third user OS that hosts the execution of the ITS - S subsystem 1450, and / or any other suitable OS / application as described herein. Additionally or alternatively, the VMs 1422 - 1426 can be, or can include, separate user space instances such as containers, partitions, virtual environments (VEs), etc., which can be implemented using appropriate OS - level virtualization techniques.

[0276] 5. Computing System and Hardware Configuration FIG. 15 illustrates an exemplary edge computing system and environment that can meet any of the computing nodes or devices described herein. The edge computing node 1550 can be embodied as a type of device, apparatus, computer, or other "thing" that can communicate with other edge, networking, or endpoint components. For example, the edge computing device 1550 can be embodied as a smartphone, a mobile computing device, a smart device, an in - vehicle computing system (e.g., a navigation system), or any other device or system capable of performing the described functions.

[0277] FIG. 15 shows an example of components that may be present in an edge computing node 1550 for implementing the techniques (e.g., operations, processes, methods, and methodologies) described herein. This edge computing node 1550 provides a closer view of each component of node 1550 when implemented as or as part of a computing device (e.g., a mobile device, a base station, a server, a gateway, infrastructure equipment, a roadside unit (RSU) or R-ITS-S 130, a radio head, a relay station, a server, and / or any other element / device described herein). The edge computing node 1550 can include any combination of the hardware or logical components referenced herein and can include or be coupled to any device usable in an edge communication network or a combination of such networks. The components may be implemented as an IC, a part thereof, an individual electronic device, or other module, instruction set, programmable logic or algorithm, hardware, a hardware accelerator, software, firmware, or a combination thereof adapted for the edge computing node 1550, or as components incorporated within the chassis of a larger system.

[0278] The edge computing node 1550 includes processing circuitry in the form of one or more processors 1552. The processor circuitry 1552 includes, but is not limited to, one or more processor cores, as well as cache memory, a low dropout regulator (LDO), an interrupt controller, an SPI, I 2C, or a serial interface such as a universal programmable serial interface circuit, a real-time clock (RTC), a timer counter including an interval and watchdog timer, general-purpose I / O, a memory card controller such as a secure digital / multimedia card (SD / MMC), an interface, a mobile industry processor interface (MIPI) interface, and one or more of a joint test access group (JTAG) test access port. In some implementations, the processor circuit 1552 can include one or more hardware accelerators (e.g., the same or similar to the acceleration circuit 1564), which can be a microprocessor, a programmable processing device (e.g., FPGA, ASIC, etc.). One or more accelerators can include, for example, computer vision and / or deep learning accelerators. In some implementations, the processor circuit 1552 can include an on-chip memory circuit, which can 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 described herein.

[0279] The processor circuit 1552 can 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, multi-core processors, multi-threaded processors, ultra-low voltage processors, embedded processors, or any other known processing element, or any suitable combination thereof. The processor (or core) 1552 can be coupled to or can include memory / storage and is configured to execute instructions stored in the memory / storage to enable various applications or operating systems to operate on node 1550. The processor (or core) 1552 is configured to run application software to provide certain services to the users of node 1550. The processor 1552 can be a dedicated processor / controller configured (or configurable) to operate according to the descriptions in Sections 1-4 above.

[0280] In some implementations, the processor 1552 can be part of a system-on-chip (SoC), system-in-package (SiP), multi-chip package (MCP), etc., and the processor 1552 and other components can be formed on a single integrated circuit or a single package. The system 1550 may not utilize the processor 1552 and instead may include a dedicated processor / controller for processing, for example, IP data received from the EPC or 5GC.

[0281] In some implementation forms, such as an implementation where the subsystems of the system 1550 are individual software agents or AI agents, each agent is implemented on a respective hardware accelerator composed of a respective bitstream or logic block suitable for executing its respective function. In these implementation forms, the processor of the processor 1552 and / or the hardware accelerator can be specifically tuned for operating the agent and / or for machine learning functions such as a cluster of AI GPUs, a tensor processing unit (TPU), a neural network processing processor (NNP), a vision processing unit (VPU). The hardware accelerator can be implemented as an AI acceleration coprocessor such as a neural engine, a neural network processing unit, etc.

[0282] Processor 1552 can communicate with system memory 1554 via interconnect (IX) 1556. Any number of memory devices can be used to provide a given amount of system memory. By way of example, the memory can be random access memory (RAM) co-designed by the JEDEC (Joint Electron Device Engineering Council), such as, for example, the DDR or Mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In a particular example, the memory components can comply with 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, such as dynamic RAM (DRAM), synchronous DRAM (SDRAM), etc., can also be included. Such standards (and similar standards) can be referred to as DDR-based standards, and the communication interface of storage devices implementing such standards can be referred to as a DDR-based interface. In various implementations, the individual memory devices can be of any number of different package types, such as single die package (SDP), dual die package (DDP), or quad die package (Q17P). In some examples, these devices can be directly soldered onto the motherboard to provide a low-profile solution, but 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, including, but not limited to, different and diverse dual in-line memory modules (DIMMs), such as micro DIMMs or MiniDIMMs.

[0283] To provide persistent storage of information such as data, applications, operating systems, etc., storage 1558 can also be coupled to processor 1552 via IX 1556. In one example, storage 1558 may be implemented via a solid state disk drive (SSDD) and / or a high-speed electrically erasable memory (commonly referred to as "flash memory"). Other devices that can be used for storage 1558 include flash memory cards such as SD cards, microSD cards, XD picture cards, and USB flash drives. In one 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, magnetic 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, devices based on spintronic magnetic junctions, devices based on magnetic tunnel junctions (MTJ), devices based on magnetic walls (DW) and spin orbit transfer (SOT), memory devices based on thyristors, or any combination of the above, or other memories, or may include them. Memory circuit 1554 and / or storage circuit 1558 may also incorporate three-dimensional (3D) cross-point (XPOINT) memory.

[0284] In a low-power implementation, storage 1558 may be on-die memory or registers associated with processor 1552. However, in some examples, storage 1558 may be implemented using a micro hard disk drive (HDD). Additionally, in addition to, or instead of, the described technology, any number of new technologies such as resistive change memory, phase change memory, holographic memory, or chemical memory can be used for storage 1558.

[0285] Storage circuit 1558 stores computing logic 1582 (or "module 1582") in the form of software, firmware, or hardware commands to implement the techniques described herein. Computing logic 1582 can be employed to store a working copy and / or a persistent copy of a computer program, or data for creating a computer program, for the operation of various components of node 1550 (such as drivers, etc.), the OS of node 1550, and / or one or more applications for performing the functions described herein. Since computing logic 1582 is to be executed by processor circuit 1552 to provide the functions described herein, it can be stored or loaded into memory circuit 1554 as data for creating instructions 1582 or instructions 1588. The various elements can be implemented by assembly instructions supported by processor circuit 1552, or a high-level language (such as instructions 1588, or data for creating instructions 1588) that can be compiled into such instructions. A persistent copy of the programming instructions may be placed in the persistent storage device of storage circuit 1558 at the factory or in the field, for example, via a distribution medium (not shown), via a communication interface (from a distribution server (not shown)), or wirelessly (OTA).

[0286] In one example, the instructions 1583, 1582 provided via the memory circuit 1554 and / or the storage circuit 1558 of FIG. 15 are, for example, computer programs or data used to create a computer program, computer program product or data, as described with respect to the flowcharts and block diagrams of the operations and functions illustrated previously, to execute electronic operations at the node 1550 and / or to instruct the processor circuit 1552 of the node 1550 to execute a flow of a particular sequence or action, embodied as one or more non-transitory computer-readable storage media (see, e.g., NTCRSM 1560). The processor circuit 1552 accesses one or more non-transitory computer-readable storage media via the interconnect 1556.

[0287] Additionally or alternatively, the programming instructions (or data for creating the instructions) may be disposed on a plurality of NTCRSMs 1560. Additionally or alternatively, the programming instructions (or data for creating the instructions) may be disposed on a computer-readable temporary storage medium such as a signal. Instructions embodied by a machine-readable medium may further be transmitted or received via a communication network using a transmission medium via a network interface device that utilizes any one of several transfer protocols (e.g., HTTP). Any combination of one or more computer-usable media or computer-readable media may be utilized. A computer-usable or computer-readable medium may be, for example, but is not limited to, one or more electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or propagation media. For example, the NTCRSM 1560 may be embodied by a device as described for the storage circuit 1558 and / or the memory circuit 1554. More specific examples (non-exhaustive list) of computer-readable media include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM, flash memory, etc.), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device and / or an optical disc, a transmission medium such as those supporting the Internet or an intranet, a magnetic storage device, or any number of other hardware devices.A computer-usable or computer-readable medium may be, for example, paper or another suitable medium on which a program (or data for creating a program) is printed, because the program (or data for creating a program) can be electronically captured via, for example, optical scanning of the paper or other medium and then compiled, interpreted, or otherwise processed in a suitable manner and then stored in a computer memory (whether staged in a more intermediate storage medium or not). Note that in the context of this specification, a computer-usable or computer-readable medium may be any medium that can store, communicate, propagate, or transport a program (or data for creating a program) for use by or in connection with an instruction execution system, apparatus, or device. A computer-usable medium may include a propagated data signal in which computer-usable program code (or data for creating program code) is embodied, either in baseband or as part of a carrier wave. The computer-usable program code (or data for creating a program) may be transmitted using any suitable medium, including but not limited to wireless, wireline, fiber optic cable, RF, etc.

[0288] The program code (or data for creating the program code) described in this specification can be stored in one or more of a compressed format, an encrypted format, a fragmented format, a packaged format, etc. The program code (or data for creating the program code) described in this specification may require one or more of installation, modification, adaptation, update, combination, complementation, configuration, decoding, decompression, unpacking, distribution, reallocation, etc. to make them directly readable and / or executable by a computing device and / or other machine. For example, the program code (or data for creating the program code) may be stored in multiple parts that are individually compressed, encrypted, and stored on separate computing devices, and the parts, when decoded, decompressed, and combined, form a set of executable instructions that implement the program code (data for creating the program code as described in this specification). In another example, the program code (or data for creating the program code) may be stored in a state where it can be read by a computer, but additional items such as a library (e.g., a dynamic link library), a software development kit (SDK), an application programming interface (API), etc. are required to execute the instructions on a particular computing device or other device. In another example, the program code (or data for creating the program code) may need to be configured (e.g., stored settings, data input, recorded network addresses, etc.) before the program code (or data for creating the program code) can be executed / used in whole or in part. In this example, the program code (or data for creating the program code) may be unpacked, configured for proper execution, and the configuration instructions may be stored at a first location that is different from a second location where the disclosed technology enabling instructions are located. The configuration instructions can be initiated by an action, trigger, or instruction that is not located at the same location or execution location as the disclosed technology enabling instructions.Therefore, the disclosed program code (or data for creating the program code) is intended to include such machine-readable instructions and / or programs (or data for creating such machine-readable instructions and / or programs), regardless of the particular format or state of the machine-readable instructions and / or programs when stored, or otherwise at rest, or in transit.

[0289] The computer program code for performing the operations of the present disclosure (e.g., the aforementioned calculation logic 1583, instruction 1582, instruction 1581) can be described in any combination of one or more programming languages, including 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, scripting languages such as 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 Pages (JSP), Node.js, ASP.NET, JAMscript, markup languages such as, for example, Hypertext Markup Language (HTML), Extensible Markup Language (XML), JavaScript Object Notation (JSON), Apex®, Cascading Style Sheets (CSS), JavaServer Pages (JSP), MessagePack™, Apache® Thrift, Abstract Syntax Notation One (ASN.1), Google® Protocol Buffers (protobuf), an in-house programming language and / or development tool, or any other suitable programming language tool. The computer program code for performing the operations of the present disclosure may also be written in any combination of the programming languages described herein. The program code can be executed entirely on the system 1550, partially on the system 1550, as a stand-alone software package, partially on the system 1550 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 the system 1550 through any type of network including a LAN or WAN, or the connection may be made to an external computer (e.g., through the Internet using an Internet service provider).

[0290] In one example, instructions 1581 on the processor circuit 1552 (separately or in combination with instructions 1582 and / or logic / modules 1583 stored in a computer-readable storage medium) can configure the execution or operation of a Trusted Execution Environment (TEE) 1590. The TEE 1590 operates as a protected area accessible to the processor circuit 1552 to enable secure access to data and secure execution of instructions. The TEE 1590 may be a separate physical hardware device distinct from other components of the system 1550 such as a secure built-in controller, a dedicated SoC, or a tamper-resistant chipset or microcontroller with an embedded processing device and memory device.

[0291] Additionally or alternatively, the TEE 1590 may be implemented as a secure enclave, which is a separate area of code and / or data within the processor and / or memory / storage circuitry of the system 1550. Only the code executed within the secure enclave can access the data within the same secure enclave, and the secure enclave can be made accessible only using a secure application (which can be implemented by an application processor or a tamper-resistant microcontroller). The various implementations of the TEE 1550, as well as the accompanying secure areas of the processor circuit 1552 or the memory circuit 1554 and / or the storage circuit 1558, can be provided, for example, through the use of software guard extensions (SGX), hardware security extensions, secure enclaves, etc. The details of security enhancement, the hardware root of trust, and reliable or protected operation can be implemented in the device 1550 through the TEE 1590 and the processor circuit 1552.

[0292] The memory circuit 1554 and / or the storage circuit 1558 may be divided into separate user space instances such as containers, partitions, virtual environments (VEs), etc. The separate user space instances may be implemented using appropriate OS-level virtualization techniques such as containers, zones, virtual private servers, virtual kernels and / or jail, schroot jail, etc. In some implementations, virtual machines can also be used. The memory circuit 1554 and / or the storage circuit 1558 can be divided into one or more reliable memory regions for storing the applications or software modules of the TEE 1590.

[0293] Command 1582 is shown as a code block included in memory circuit 1554, and computation logic 1583 is shown as a code block of storage circuit 1558, but it should be understood that any of the code blocks may be replaced by a hardwired circuit constructed in, for example, an FPGA, an ASIC, or some other suitable circuit. For example, if processor circuit 1552 includes a (e.g., FPGA-based) hardware accelerator as well as a processor core, the hardware accelerator (e.g., FPGA cells) can be preconfigured (e.g., using an appropriate bitstream) with the aforementioned computation logic to perform some or all of the aforementioned functions (instead of adopting programming instructions executed by the processor core).

[0294] Memory circuit 1554 and / or storage circuit 1558 can store program code of an operating system (OS), which can be a general-purpose OS or an OS specifically written and tailored for computing node 1550. For example, the OS can 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 the ones described herein.

[0295] The OS can include one or more drivers that operate to control a particular device incorporated in, attached to, or further communicatively coupled to node 1550. The drivers can include individual drivers that enable other components of node 1550 to interact with or control various I / O devices that can be present within node 1550 or connected to the node. For example, the drivers can include a display driver for controlling and permitting access to a display device, a touch screen driver for controlling and permitting access to the touch screen interface of node 1550, a sensor driver for obtaining sensor readings of sensor circuit 1572 and controlling and permitting access to sensor circuit 1572, an actuator driver for obtaining the actuator position of actuator 1574 and / or controlling and permitting access to actuator 1574, a camera driver for controlling and permitting access to an embedded image capture device, and an audio driver for controlling and permitting access to one or more audio devices. The OS can also include one or more libraries, drivers, APIs, firmware, middleware, software groups, etc. that provide program code and / or software components for one or more applications to obtain and use data from a secure execution environment, a trusted execution environment, and / or a management engine of node 1550 (not shown).

[0296] The components of the edge computing device 1550 can communicate via the IX 1556. The IX 1556 can include any number of bus and / or interconnect (IX) technologies such as industry standard architecture (ISA), extended ISA (EISA), inter-integrated circuit (I2C), serial peripheral interface (SPI), point-to-point interface, power management bus (PMBus), peripheral component interconnect (PCI), PCI express (PCIe), ultra path interface (UPI), accelerator link (IAL), common application programming interface (CAPI), quick path interconnect (QPI), ultra path interconnect (UPI), OmniPath architecture (OPA) IX, RapidIO system IX, cache coherent interconnect for accelerators (CCIA), Gen-Z consortium, open coherent accelerator processor interface (OpenCAPI) IX, hypertransport interconnect, and / or any number of other IX technologies. The IX technology can be, for example, a dedicated bus used in a SoC-based system.

[0297] The IX 1556 couples the processor 1552 to the communication circuit 1566 to communicate with other devices such as a remote server (not shown) and / or the connected edge device 1562. The communication circuit 1566 is a hardware element or a set of hardware elements used to communicate via one or more networks (e.g., the cloud 1563) and / or with other devices (e.g., the edge device 1562). The modem circuit 156Z can convert data for wireless transmission using one or more radios 156X and 156Y and can convert received signals from the radios 156X and 156Y into digital signals / data for consumption by other elements of the system 1550.

[0298] The transceiver 1566 can use any number of frequencies and protocols, such as 2.4 gigahertz (GHz) transmission under the IEEE 802.15.4 standard, using the Bluetooth (R) Low Energy (BLE) standard, as defined by the Bluetooth (R) Special Interest Group or the ZigBee (R) standard, for example. Any number of radios 156X and 156Y (or "RAT circuits 156X and 156Y") configured for a particular wireless communication protocol can be used to connect to the connected edge device 1562. For example, the wireless local area network (WLAN) circuit 156X can be used to perform WiFi (R) communication according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. Additionally, wireless wide area communication (e.g., according to a cellular or other wireless wide area protocol) may be performed via the wireless wide area network (WWAN) circuit 156Y.

[0299] The wireless network transceiver 1566 (or transceivers) can communicate using multiple standards or radios to communicate over different ranges. For example, the edge computing node 1550 can communicate with a proximity device within, for example, about 10 meters using a BLE-based local transceiver or another low-power radio to conserve power. An edge device 1562 connected further away, such as within about 50 meters, for example, can be reached via ZigBee (R) or another medium-power radio. Both communication technologies may be performed with a single radio at different power levels, or with separate transceivers, such as a local transceiver using BLE and a separate mesh transceiver using ZigBee (R).

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

[0301] As described herein, in addition to the system described for the wireless network transceiver 1566, any number of other wireless communications and protocols can be used. For example, the transceiver 1566 can include a cellular transceiver that uses spread spectrum (SPA / SAS) communication to perform high-speed communication. Further, any number of other protocols can be used, such as a WiFi® network for providing medium-speed communication and network communication. The transceiver 1566 can include radios 156X and 156Y that are compatible with any number of 3GPP® specifications, such as LTE and 5G / NR communication systems, which are described in more detail at the end of this disclosure. The network interface controller (NIC) 1568 may be included to provide wired communication to other devices, such as a node of the edge cloud 1563 or a connected edge device 1562 (e.g., operating in a mesh). The wired communication may provide an Ethernet® connection or, alternatively, may be based on any of a number of other types of networks, such as Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway Plus (DH+), PROFIBUS, or PROFINET. To enable connection to a second network, additional NICs 1568 may be included, such as a first NIC 1568 that provides communication to the cloud via Ethernet® and a second NIC 1568 that provides communication to other devices via another type of network.

[0302] Considering the various types of applicable communication from a device to another component or network, the applicable communication circuitry used by the device can include or be embodied by any one or more of components 1564, 1566, 1568, or 1570. Thus, in various examples, the applicable means for communicating (e.g., receiving, Tx, etc.) can be embodied by such communication circuitry.

[0303] Edge computing node 1550 can include, or be coupled to, an acceleration circuit 1564, which can be embodied by one or more AI accelerators, neural computing sticks, neuromorphic hardware, FPGA, GPU arrangements, 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 CPLD or HCPLD, and / or other forms of special processors or circuits designed to achieve one or more special tasks. These tasks can include AI processing (including machine learning, training, inference, and classification operations), visual data processing, network data processing, object detection, rule analysis, and the like. In an FPGA-based implementation, acceleration circuit 1564 can include logic blocks or logic fabric, and other interconnected resources that can be programmed (configured) to perform various functions such as the procedures, methods, functions, etc. described herein. In such an implementation, acceleration circuit 1564 can also include memory cells (e.g., EPROM, EEPROM, flash memory, static memory (e.g., SRAM, anti-fuse, etc.)) used to store logic blocks, logic fabric, data, etc., such as LUTs.

[0304] IX 1556 also couples processor 1552 to a sensor hub or external interface 1570 used to connect additional devices or subsystems. The additional / external devices can include sensors 1572, actuators 1574, and positioning circuit 1545.

[0305] The sensor circuit 1572 includes a device, module, or subsystem that is intended to detect an event or change in its environment and transmit information (sensor data) regarding the detected event to some other device, module, subsystem, etc. Examples of such sensors 1572 include, among others, an inertial measurement unit (IMU) equipped with an accelerometer, gyroscope, and / or magnetometer, a microelectromechanical system (MEMS) or nanoelectromechanical system (NEMS) equipped with a three-axis accelerometer, three-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 image capture device (e.g., a camera), a light detection and ranging (LiDAR) sensor, a proximity sensor (e.g., an infrared detector, etc.), a depth sensor, an ambient light sensor, an optical sensor, an ultrasonic transceiver, a microphone, etc.

[0306] Additionally or alternatively, some of the sensors 172 may be sensors used in various vehicle control systems, and in particular, exhaust sensors including an exhaust oxygen sensor for obtaining oxygen data and a manifold absolute pressure (MAP) sensor for obtaining manifold pressure data, a mass air flow (MAF) sensor for obtaining intake air flow data, an intake air temperature (IAT) sensor for obtaining IAT data, an ambient air temperature (AAT) sensor for obtaining AAT data, an ambient air pressure (AAP) sensor (e.g., tire air pressure data) for obtaining AAP data, a catalytic converter sensor including a catalytic converter temperature (CCT) for obtaining CCT data and a catalytic converter oxygen (CCO) sensor for obtaining CCO data, a vehicle speed sensor (VSS) for obtaining VSS data, an exhaust gas recirculation (EGR) sensor including an EGR pressure sensor for obtaining EGR pressure data and an EGR position sensor for obtaining the position / orientation data of the EGR valve pintle, a throttle position sensor (TPS) for obtaining throttle position / orientation / angle data, a crank / cam position sensor for obtaining crank / cam / piston position / orientation / angle data, a coolant temperature sensor, a driveline sensor (e.g., transmission fluid level) for collecting driveline sensor data, a body sensor (e.g., data associated with buckling of the front grill / fender, side door, rear fender, rear trunk, etc.) for collecting body data, and the like. The sensor 172 may 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 described herein. The sensor data from the sensors 172 of the host vehicle can include engine sensor data collected by various engine sensors (e.g., engine temperature, oil pressure, etc.).

[0307] Actuator 1574 enables node 1550 to change its state, position, and / or orientation, or to move or control a mechanism or system. Actuator 1574 comprises an electrical and / or mechanical device for moving or controlling a mechanism or system, and converts energy (e.g., electric current or moving air and / or liquid) into some kind of movement. Actuator 1574 can include one or more electronic (or electro-chemical) devices such as piezoelectric bioforms, solid state actuators, solid state relays (SSRs), shape memory alloy-based actuators, electroactive polymer-based actuators, relay driver integrated circuits (ICs). Actuator 1574 can 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, servomechanisms, etc.), power switches, valve actuators, wheels, thrusters, propellers, claws, clamps, hooks, audible sound generators, visual warning devices, and / or other similar electromechanical components. Node 1550 can be configured to operate one or more actuators 1574 based on one or more captured events and / or instructions or control signals received from service providers and / or various client systems.

[0308] The actuator 1574 may be a drive control unit (e.g., the DCU 174 of FIG. 1). Examples of the DCU 1574 include a drive train control unit, an engine control unit (ECU), an engine control module (ECM), an EEMS, a power train control module (PCM), a transmission control module (TCM), an anti-lock braking system (ABS) module and / or a brake control module (BCM) including an electronic stability control (ESC) system, a central control module (CCM), a central timing module (CTM), a general electronics module (GEM), a body control module (BCM), a suspension control module (SCM), a door control unit (DCU), a speed control unit (SCU), a human machine interface (HMI) unit, a telematics control unit (TTU), a battery management system, a portable emission measurement system (PEMS), an evasive steering assist (EMA) module / system, and / or any other entity or node of the vehicle system. Examples of the CSD that may be generated by the DCU 174 include, but are not limited to, the engine revolutions per minute (RPM) of the vehicle's engine, fuel injector activation timing data for one or more cylinders of the engine and / or one or more injectors, ignition spark timing data for one or more cylinders (e.g., indication of the spark event relative to the crank angle of one or more cylinders), transmission ratio data and / or transmission state data (which may be supplied by a transmission control unit (TCU) to the ECM), and other real-time calculated engine load values from an engine control module (ECM).

[0309] In a vehicle implementation form, for the actuator / DCU 1574, a control system configuration (CSC), which is a set of software modules, software components, logic blocks, parameters, calibrations, variant forms, etc. used to control and / or monitor various systems implemented by the node 1550 (for example, when the node 1550 is the CA / AD vehicle 110), can be provisioned. The CSC defines how the DCU 1574 should interpret the sensor data of the sensor 1572 and / or the CSD of other DCU 1574 using a multi-dimensional performance map or a look-up table, and defines how the actuator / component should be adjusted / modified based on the sensor data. The CSC and / or software components executed by the individual DCU 1574 can be developed using any suitable object-oriented programming language (such as C, C++, Java (registered trademark), etc.), schema language (such as XML schema, AUTomotive Open System Architecture (AUTOSAR) XML schema, etc.), script language (such as VBScript, JavaScript (registered trademark), etc.). The CSC and software components can be defined using a hardware description language (HDL) such as register transfer logic (RTL) for the DCU 1574 implemented as a field programmable device (FPD), very high speed integrated circuit (VHSIC) HDL (VHDL), Verilog, etc. The CSC and software components can be generated using a modeling environment or model-based development tools. The CSC can 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.

[0310] IVS 101 and / or DCU 1574 can be configured or made operative to operate one or more actuators based on one or more captured events (as indicated by sensor data captured by sensor 1572), and / or instructions or control signals received from user input, signals wirelessly received from a service provider, etc. Additionally, one or more DCU 1574 can be configured or made operative to operate one or more actuators by Tx / transmitting commands or control signals to the actuators based on detected events (as indicated by sensor data captured by sensor 1572). One or more DCU 1574 can read or otherwise obtain sensor data from one or more sensors 1572, 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 vehicle 110. An embedded device / system functioning as a central controller or hub can also access the control system data for processing using appropriate drivers, APIs, ABIs, libraries, middleware, firmware, etc., and / or DCU 1574 can be configured or made operative to provide the control system data to the central hub and / or other devices / components periodically or aperiodically and / or when triggered.

[0311] Various subsystems, including sensor 1572 and / or DCU 1574, may be operated and / or controlled by one or more AI agents. An AI agent is an autonomous entity that can be configured or operative to observe environmental conditions and determine actions to take to further a particular goal. The particular environmental conditions to be observed and the actions to take can be based on an operational design domain (ODD). The ODD includes the operating conditions for which a given AI agent or its features are specifically designed to function. The ODD can include environmental, geographic, and time limitations, and / or operational limitations such as the presence or absence of specific traffic or road characteristics.

[0312] Additionally or alternatively, individual AI agents may be configured or operable to control respective control systems of the host vehicle, some of which may include the use of one or more DCUs 1574 and / or one or more sensors 1572. The actions to be taken and the specific goals to be achieved may be specified or individualized based on the control system itself. Additionally, 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 operation and tactical functions necessary to operate vehicle 110 in traffic on the road, excluding strategic functions such as trip scheduling and selection of destinations and waypoints. DDT includes tactical and operational tasks such as lateral vehicle movement control (operation) via steering, longitudinal vehicle movement control (operation) via acceleration and deceleration, monitoring the driving environment via detection, recognition, classification, and preparation for response to objects and events (operation and tactics), object and event response execution (operation and tactics), maneuver planning (tactics), enhancing salience via lighting, signaling, gestures, etc. (tactical), etc. The OEDR task may be a subtask of DDT that monitors the driving environment (e.g., detecting, recognizing, and classifying objects and events and preparing to respond as necessary) and, as necessary, performs appropriate responses to such objects and events, for example, to complete the DDT or fallback tasks.

[0313] To observe environmental conditions, the AI agent can be configured or operative to receive or monitor sensor data from one or more sensors 1572 and receive control system data (CSD) from one or more DCUs 1574 of the host vehicle 110. The monitoring operation can include capturing CSD and / or sensor data from the individual sensors 172 and DCUs 1574. The monitoring can include polling (e.g., periodic polling, sequential (roll call) polling, etc.) one or more sensors 1572 for sensor data and / or one or more DCUs 1574 for CSD over a specified / selected period of time. Additionally or alternatively, the monitoring can include sending requests or commands for sensor data / CSD in response to external requests for sensor data / CSD. The monitoring can include waiting for sensor data / CSD from various sensors / modules based on triggers or events, such as when the host vehicle reaches a predetermined speed and / or distance at a predetermined time (regardless of the presence of a pause). The events / triggers can be specific to the AI agent and can vary depending on the particular application, use case, design choices, etc. The monitoring can be triggered or activated by an application or subsystem of the IVS 101 or by a remote device such as the computing node 140 and / or server 160.

[0314] Additionally or alternatively, one or more of the AI agents can be configured or operable to process sensor data and CSD to identify the internal and / or external environmental conditions that act. Examples of sensor data can include, but are not limited to, image data from one or more cameras of a vehicle that provide a front, rear, and / or side view as seen from the vehicle, sensor data from an accelerometer, inertial measurement unit (IMU), and / or gyroscope of the vehicle that provide speed, acceleration, and tilt data of the host vehicle, audio data provided by a microphone, and control system sensor data provided by one or more control system sensors. In one example, one or more of the AI agents can be configured or operable to process an image captured by sensor 1572 (an image capture device) and / or evaluate a state identified by some other subsystem (e.g., an EMA subsystem, a CAS and / or CPS entity, etc.) to determine the state or situation of the surrounding area (e.g., a depression, the presence of fallen trees / poles, damage to a barrier along the road, debris of the vehicle, etc.). In another example, one or more of the AI agents can be configured or operable to process CSD provided by one or more DCUs 1574 to determine the current emissions or fuel consumption of the host vehicle. The AI agent can also be configured or operable to compare the sensor data and / or CSD with training set data to determine or contribute to the determination of environmental conditions for controlling the corresponding control system of the vehicle.

[0315] To determine the actions to be taken to further a particular goal, each of the AI agents identifies the current state of the IVS 101, host vehicle 110, and / or the AI agent itself, identifies or obtains one or more models (e.g., an ML model), identifies or obtains goal information, and is configurable or operable to predict the outcome of taking one or more actions based on the current state / context, one or more models, and the goal information. The one or more models may be any algorithm or object created after the AI agent has been trained on one or more training data sets, and the one or more models may indicate possible actions that can be taken based on the current state. The one or more models may be based on the ODD defined for a particular AI agent. The current state is a configuration or set of information in one or more other systems of the IVS 101 and / or the host vehicle 110, or various state metrics in one or more other systems of the IVS 101 and / or the host vehicle 110. The current state is stored internally in the AI agent and maintained in an appropriate data structure. The AI agent is configurable or operable to predict the possible outcomes as a result of executing a particular action defined by the model. The goal information describes a desired outcome (or goal state) that is desirable considering the current state. Each of the AI agents selects an outcome from among the predictable outcomes that reach a particular goal state and provides signals or commands to various other subsystems of the vehicle 110 to execute one or more actions determined to lead to the selected outcome. The AI agent may also include a learning module that is configurable or operable to learn from the selected outcome and experience regarding some performance metric. The experience may include sensor data and / or new state data collected after execution of one or more actions of the selected outcome. The learned experience may be used to generate a new or updated model for determining future actions to take.

[0316] The positioning circuit 1545 includes circuits for receiving and decoding signals transmitted / broadcast by the positioning network of a global navigation satellite system (GNSS). Examples of navigation satellite constellations (or GNSS) include the United States' Global Positioning System (GPS), Russia's Global Navigation Satellite System (GLONASS), the European Union's Galileo system, China's Beidou Navigation Satellite System, regional navigation systems, or GNSS augmentation systems (e.g., navigation by the Indian constellation (NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS), etc.). The positioning circuit 1545 comprises various hardware elements (including hardware devices such as switches, filters, amplifiers, antenna elements, etc. to facilitate OTA communication) for communicating with components of the positioning network such as navigation satellite constellation nodes. The positioning circuit 1545 can include a Micro-PNT (Micro-Positioning, Navigation, and Timing) IC for performing position tracking / estimation without GNSS assistance using an integrated timing clock. The positioning circuit 1545 may also be part of the communication circuit 1566 or interact with the communication circuit for communicating with nodes and components of the positioning network. The positioning circuit 1545 can also provide position data and / or time data to the application circuit, which can use the data to synchronize operations with various infrastructure (e.g., radio base stations) for turn-by-turn navigation, etc. When GNSS signals are unavailable or when GNSS position accuracy is not sufficient for a particular application or service, positioning enhancement techniques can be used to provide enhanced positioning information and data to the application or service. Such positioning enhancement techniques can include, for example, satellite-based positioning enhancement (e.g., EGNOS) and / or ground-based positioning enhancement (e.g., DGPS).In some implementations, the positioning circuit 1545 continuously calculates the position, orientation, and / or velocity (including direction and speed of movement) of the node 1550 without requiring an external reference (e.g., using dead reckoning, triangulation, etc. with dead reckoning). To do this, it uses a sensor circuit 1572 (e.g., a motion sensor such as an accelerometer, a rotation sensor such as a gyroscope, and a system or device such as an INS (registered trademark) that uses an altimeter, a magnetic sensor, etc., or includes it).

[0317] In some optional examples, various input / output (I / O) devices may be present within the edge computing node 1550 or may be connected to the edge computing node, which are referred to as input circuit 1586 and output circuit 1584 in FIG. 15. The input circuit 1586 and output circuit 1584 include one or more user interfaces designed to enable user interaction with the node 1550 and / or peripheral component interfaces designed to enable interaction with peripheral components of the node 1550. The input circuit 1586 can include, among other things, any physical or virtual means for receiving inputs including one or more physical or virtual buttons (e.g., reset button), physical keyboard, keypad, mouse, touchpad, touch screen, microphone, scanner, headset, etc. The output circuit 1584 may be included to indicate information such as sensor readings, actuator positions, or other similar information or to communicate information in other ways. Data and / or graphics may be displayed on one or more user interface components of the output circuit 1584. The output circuit 1584 can include, among other things, any number and / or combination of audio or visual displays including one or more simple visual outputs / indicators (e.g., binary status indicators (e.g., light emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as display devices or touch screens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, projectors, etc.) with outputs such as characters, graphics, multimedia objects, etc. generated or produced from the operation of the node 1550. The output circuit 1584 may also include speakers or other sound-emitting devices, printers, etc. The sensor circuit 1572 may be used as an input circuit 1584 (e.g., image capture device, motion capture device, etc.), and one or more actuators 1574 may be used as an output device circuit 1584 (e.g., actuator providing tactile feedback, etc.).In another example, a Near Field Communication (NFC) circuit comprising an antenna element and an NFC controller coupled to a processing device may be included to read an electronic tag and / or connect to another NFC-enabled device. The peripheral component interface can include, without limitation, a non-volatile memory port, a USB port, an audio jack, a power interface, and the like. In the context of this system, a display or console hardware can be used to provide the output of the edge computing system, receive input, manage the components or services of the edge computing system, identify the state of the edge computing components or services, or perform any other number of administrative or operational functions or service use cases.

[0318] The battery 1576 can power the edge computing node 1550. However, in an example where the edge computing node 1550 is fixedly attached, it can have a power source coupled to the power grid, or the battery can be used as a backup or for temporary capabilities. The battery 1576 can be a lithium-ion battery or a metal-air battery such as a zinc-air battery, an aluminum-air battery, or a lithium-air battery.

[0319] The battery monitor / charger 1578, if included, may be included in the edge computing node 1550 to track the state of charge (SoCh) of the battery 1576. The battery monitor / charger 1578 may be used to monitor other parameters of the battery 1576 to provide fault predictions such as the state of health (SoH) and state of function (SoF) of the battery 1576. The battery monitor / charger 1578 can include a battery monitor integrated circuit such as the LTC4020 or LTC2990 from Linear Technologies, the ADT7488A from ON Semiconductor in Phoenix, Arizona, or the UCD90xxx family of ICs from Texas Instruments in Dallas, Texas. The battery monitor / charger 1578 can communicate information regarding the battery 1576 to the processor 1552 via the IX 1556. The battery monitor / charger 1578 can also include an analog-to-digital (ADC) converter that enables the processor 1552 to directly monitor the voltage of the battery 1576 or the current from the battery 1576. The battery parameters can be used to determine actions that the edge computing node 1550 can perform, such as the transmission frequency, mesh network operation, sensing frequency, etc.

[0320] The power block 1580, or another power source coupled to the grid, may be coupled to the battery monitor / charger 1578 to charge the battery 1576. In some examples, the power block 1580 may be replaced with a wireless power receiver to wirelessly obtain power, for example, through the loop antenna of the edge computing node 1550. In particular, a wireless battery charging circuit, such as the LTC4020 chip manufactured by Linear Technologies of Milpitas, California, may be included in the battery monitor / charger 1578. A particular charging circuit can be selected based on the size of the battery 1576 and thus the required current. Charging can be performed using, in particular, the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard promulgated by the Alliance for Wireless Power.

[0321] The storage 1558 can include instructions 1583 in the form of software, firmware, or hardware commands for implementing the techniques described herein. Such instructions 1583 are shown as code blocks included in the memory 1554 and the storage 1558, but it should be understood that any of the code blocks can be replaced, for example, with a hard-wired circuit incorporated in an application specific integrated circuit (ASIC).

[0322] In one example, instructions 1581, 1582, 1583 provided via memory 1554, storage 1558, or processor 1552 can be embodied as a non-transitory, machine-readable medium 1560 that includes code for instructing processor 1552 to perform electronic operations at edge computing node 1550. Processor 1552 can access non-transitory, machine-readable medium 1560 via IX 1556. For example, non-transitory, machine-readable medium 1560 may be embodied by a device described for storage 1558 and may include a particular storage unit such as an optical disk, flash drive, or any number of other hardware devices. Non-transitory, machine-readable medium 1560 can include instructions for instructing processor 1552 to perform a flow of a particular sequence or action, as described with respect to the flowcharts and block diagrams of operations and functions illustrated above. As used herein, the terms “machine-readable medium” and “computer-readable medium” are interchangeable.

[0323] In a further example, a machine-readable medium can also store, encode, or carry instructions for machine execution, causing a machine to perform any one or more of the methodologies of the present disclosure, or being used by or associated with such instructions, or can include any tangible medium that can store, encode, or carry the data structures associated therewith. Thus, a "machine-readable medium" can include, but is not limited to, solid state memories as well as optical and magnetic media. Specific examples of machine-readable media include, but are not limited to, non-volatile memories such as semiconductor memory devices (e.g., electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM)) and flash memory devices, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks. Instructions embodied by a machine-readable medium can further be transmitted or received over a communication network using a transmission medium via a network interface device that utilizes any one of a number of transfer protocols (e.g., HTTP).

[0324] A machine-readable medium may be provided by a storage device or other apparatus capable of hosting data in a non-transitory format. In one example, the information stored or otherwise provided on the machine-readable medium can represent instructions, such as the instructions themselves or a format from which the instructions can be derived. This format from which the instructions can be derived can include source code, encoded instructions (e.g., in a compressed or encrypted form), packaged instructions (e.g., split into multiple packages), and the like. The information representing the instructions on the machine-readable medium can be processed into instructions by a processing circuit to perform any of the operations described herein. For example, deriving instructions from information (e.g., by a processing circuit) can include compiling (e.g., from source code, object code, etc.), interpreting, loading, assembling (e.g., dynamically or statically linking), encoding, decoding, encrypting, not encrypting, packaging, not packaging, or otherwise operating on the information to create the instructions.

[0325] In one example, deriving the instructions can include assembling, compiling, or interpreting information (e.g., by a processing circuit) to create the instructions from some intermediate or preprocessed format provided by the machine-readable medium. If the information is provided in multiple parts, it can be combined, unpacked, and modified to create the instructions. For example, the information can be in multiple compressed source code packages (or object code, or binary executable code, etc.) on one or several remote servers. The source code packages can be encrypted when moving across a network and, if necessary, decrypted, uncompressed, assembled (e.g., linked), compiled or interpreted (e.g., into libraries, stand-alone executable files, etc.) on a local machine, and executed by the local machine.

[0326] The illustrations of FIGS. 12 - 15 are intended to illustrate a high - level view of various devices, subsystems, or components of an edge - computing node configuration. However, some of the components shown may be omitted, additional components may exist, and different arrangements of components may occur in other implementations. Further, these arrangements are usable in a variety of use cases and environments, including those described herein (e.g., mobile UEs in industrial computing for smart cities or smart factories, among many other examples). The computing platform of FIG. 15 can support multiple edge instances (e.g., edge clusters) by using tenant containers running on a single computing platform. Similarly, multiple edge nodes can exist as sub - nodes running on a tenant within the same computing platform. Thus, based on available resource partitioning, a single system or computing platform can be divided or partitioned among multiple supported tenants and edge - node instances, each of which can support multiple services and functions even while potentially being operated or controlled by multiple owners on multiple computing - platform instances. These various types of partitions can support many combinations of complex multi - tenant and multi - stakeholder scenarios through the use of LSM or other implementations of separation / security policies. Thus, the use of LSM and references to security functions that enhance or implement such security capabilities are noted in the following sections. Similarly, services and functions operating in these various types of multi - entity partitions can be load - balanced, moved, and adjusted to achieve the required service objectives and operations.

[0327] At least one of the systems or components described in one or more of the foregoing figures can be configured or operable to perform one or more of the operations, techniques, processes, and / or methods described in the sections of the following examples.

[0328] 1. Example Example 1 includes a method of operating an Intelligent Transport System Station (ITS-S), the method including generating a Collective Perception Message (CPM) including a hierarchical cost map container, the hierarchical cost map container including cost values and corresponding reliability levels of a hierarchical cost map available in the ITS-S, and transmitting the CPM to one or more other ITS-Ss.

[0329] Example 2 includes the method of Example 1 and / or some other examples herein, further including that generating the CPM by detecting a CPM generation event is for further generating a CPM in response to the detection of the CPM generation event.

[0330] Example 3 includes the method of Examples 1-2 and / or some other examples herein, wherein the cost-based occupancy grid data includes data of an aggregated cost map layer of a hierarchical cost map available in the ITS-S.

[0331] Example 4 includes the method of Example 3 and / or some other examples herein, further including selecting the aggregated cost map layer such that when one or more values of each cell of the aggregated cost map layer change beyond an aggregated layer threshold, they are included in the CPM, the one or more values being the cost value of each cell or the reliability level of each cell.

[0332] Example 5 includes the method of Example 4 and / or some other examples herein, wherein the aggregated layer threshold is based on a portion of the total number of cells of the aggregated cost map layer in which the cost value or reliability level has changed compared to the cost value or reliability level in the previous aggregated cost map layer of a previously transmitted CPM.

[0333] Example 6 includes the method of Examples 3-5 and / or some other examples herein, and further includes determining to include in the CPM a hierarchical cost map container with an aggregated cost map layer when the difference between the current Euclidean distance of the center point of the hierarchical cost map and the previous Euclidean distance of the center point of the previous hierarchical cost map included in the previously transmitted CPM exceeds a center point position change threshold.

[0334] Example 7 includes the method of Examples 3-6 and / or some other examples herein, and further includes determining to include in the CPM a hierarchical cost map container with an aggregated cost map layer when the difference between the current dimensions of the hierarchical cost map and the previous dimensions of the hierarchical cost map included in the previously transmitted CPM exceeds a dimension change threshold.

[0335] Example 8 includes the method of Examples 3-7 and / or some other examples herein, and further includes determining to include in the CPM a hierarchical cost map container with an aggregated cost map layer when the difference between the current orientation of the hierarchical cost map and the previous orientation of the hierarchical cost map included in the previously transmitted CPM exceeds an orientation change threshold.

[0336] Example 9 includes the method of Examples 3-8 and / or some other examples herein, and further includes determining to include in the CPM a hierarchical cost map container with an aggregated cost map layer when the time elapsed from the previous time when the aggregated cost map layer was included in the previously transmitted CPM exceeds a threshold time (T_GenCpmMax), where T_GenCpmMax is the elapsed time from the start of the previous CPM generation event to the current CPM generation event.

[0337] Example 10 includes the methods of Examples 3-9 and / or some other examples herein, and the cost-based occupancy grid data further includes one or more other layers of the hierarchical cost map available in the ITS-S, and the other layers include a disagreement processing cost map layer and a collaboration request cost map layer, and the disagreement processing cost map layer indicates cells where there is a disagreement between the cost value or reliability level of the hierarchical cost map and the cost value or reliability level of another hierarchical cost map received from one or more adjacent ITS-Ss, and the collaboration request cost map layer indicates cells where the ITS-S could not determine the perception at the minimum reliability level.

[0338] Example 11 includes the methods of Example 10 and / or some other examples herein, and further includes determining to include in the CPM a hierarchical cost map container with a disagreement processing cost map layer when one or more values in each cell in the disagreement processing cost map layer change beyond a disagreement threshold, and the one or more values are the cost value of each cell or the reliability level of each cell.

[0339] Example 12 includes the methods of Example 11 and / or some other examples herein, and the disagreement threshold is based on a portion of the total number of cells in the disagreement processing cost map layer or the aggregated cost map layer where the cost value or reliability level has changed compared to the cost value or reliability level of the cost map layer of the CPM received from adjacent ITS-Ss.

[0340] Example 13 includes the methods of Examples 10-12 and / or some other examples herein, and further includes determining to include in the CPM a hierarchical cost map container with a collaboration request cost map layer when the reliability level for the perception in one or more cells of the hierarchical cost map is lower than the reliability level threshold for exceeding the threshold number of cells in the aggregated cost map layer.

[0341] Example 14 includes the methods of Examples 10 - 13 of this specification and / or some other examples, and the other layers further include one or more of a static cost map layer indicating a perceived persistent structure, a perceived object cost map layer indicating one or more perceived objects that are dynamic or static, an inflated cost map layer indicating a respective buffer region around one or more perceived objects or persistent structures, and a collective perception cost map layer indicating one or more perceived objects received from one or more adjacent ITS - S.

[0342] Example 15 includes the methods of Example 14 and / or some other examples of this specification, and when the reliability level of one or more cells of a static cost map layer, a perceived object cost map layer, an inflated cost map layer, or a collective perception cost map layer is lower than a reliability level threshold for exceeding a threshold number of cells in a hierarchical cost map compared to the cost value or reliability level of the same cost map layer of a previously transmitted CPM, it further includes determining to include in the CPM a hierarchical cost map container with corresponding ones of the static cost map layer, the perceived object cost map layer, the inflated cost map layer, and the collective perception cost map layer.

[0343] Example 16 includes the methods of Examples 14 - 15 and / or some other examples of this specification, and when the time elapsed since the same cost map layer was last included in a previously transmitted CPM exceeds another threshold time, it further includes determining to include in the CPM a hierarchical cost map container with one or more of the static cost map layer, the perceived object cost map layer, the inflated cost map layer, and the collective perception cost map layer.

[0344] Example 17 includes the methods of Example 16 and / or some other examples of this specification, and the other threshold time is based on a predefined amount of time that elapses while the CPM and T_GenCpmMax continuously include cost map layers other than the aggregated cost map layer.

[0345] Example 18 includes the methods of Examples 3 - 17, and further includes dividing a hierarchical cost map into a plurality of cells, generating a plurality of layers of the hierarchical cost map, and preparing an aggregated cost map layer by aggregating each layer of the plurality of layers.

[0346] Example 19 includes the method of Example 18, and preparing a hierarchical cost map further includes preparing a hierarchical cost map having dimensions specified based on the field of view (FOV) of one or more sensors accessible by the ITS-S.

[0347] Example 20 includes the method of Example 18 or 19, and preparing a hierarchical cost map further includes periodically updating the aggregated cost map layer, and the period for updating the aggregated cost map layer is shorter than the CPM generation event period.

[0348] Example 21 includes the methods of Examples 18 - 20, and generating a CPM further includes generating a CPM that further includes a ReportedCostMapGridArea data field including the dimensions of the hierarchical cost map, and generating a CPM that further includes a GridCellSizeX data element (DE) and a GridCellSizeY DE to indicate the dimensions of each cell of the plurality of cells.

[0349] Example 22 includes the methods of Examples 18 - 21, and generating a CPM further includes generating a CPM that further includes a NumberOfLayeredCostMap DF indicating the number of cost map layers of the hierarchical cost map container.

[0350] Example 23 includes the methods of Examples 18 - 22, and further includes determining the respective cost values of each cell of the plurality of cells based on sensor data obtained from one or more sensors, information obtained from one or more adjacent ITS-Ss, and a static map available to the ITS-S.

[0351] Example 24 includes the methods of Examples 18 to 23, and generating the CPM further includes generating the CPM to further include PerGridCellCostValueConfigType DF and PerGridCellConfidenceLevelConfigType DF. PerGridCellCostValueConfigType DF includes the cost values of cells of a plurality of cells, and PerGridCellConfidenceLevelConfigType DF includes the confidence levels of cells of a plurality of cells.

[0352] Example 25 includes the methods of Examples 1 to 24, and at least one cost map layer included in the hierarchical cost map container has a format different from at least one other cost map layer included in the hierarchical cost map container.

[0353] Example 26 includes the methods of Examples 1 to 25, and ITS-S is vehicle ITS-S (V-ITS-S), roadside ITS-S (R-ITS-S), or vulnerable road user (VRU) ITS-S.

[0354] Example Y01 includes an apparatus employed in a vehicle. The apparatus includes a communication circuit communicatively coupled to a processor circuit. The processor circuit is communicatively coupled to a memory circuit, and the processor circuit is configurable or operable to execute any one of the methods of Examples 1 to 26.

[0355] Example Y02 includes an apparatus employed in roadside infrastructure. The apparatus includes a communication circuit communicatively coupled to a processor circuit. The processor circuit is communicatively coupled to a memory circuit, and the processor circuit is configurable or operable to execute any one of the methods of Examples 1 to 26.

[0356] Example Y03 includes an apparatus adopted as a mobile device, the apparatus comprising a communication circuit communicatively coupled to a processor circuit, the processor circuit being communicatively coupled to a memory circuit, and the processor circuit being configurable or operable to execute any one of the methods of Examples 1 to 26.

[0357] Example Z01 includes one or more computer-readable media comprising instructions, the execution of the instructions by a processor circuit causing the processor circuit to execute any one of the methods of Examples 1 to 26 and / or Y01 to Y03. Example Z02 includes a computer program comprising the instructions of Example Z01. Example Z03a includes an application programming interface defining functions, methods, variables, data structures, and / or protocols for the computer program of Example Z02.

[0358] Example Z03b includes an API or specification defining or encompassing the use of any of Examples 1 to 26 and / or Y01 to Y03 or a part thereof, or otherwise related to any of Examples 1 to 26 and / or Y01 to Y03 or a part thereof, and defining functions, methods, variables, data structures, protocols, etc.

[0359] Example Z04 includes an apparatus comprising a circuit in which the instructions of Example Z01 are loaded. Example Z05 includes an apparatus comprising a circuit operable to execute the instructions of Example Z01. Example Z06 includes an integrated circuit comprising the processor circuit of Example Z01 and one or more of the one or more computer-readable media of Example Z01. Example Z07 includes a computing system comprising one or more computer-readable media and the processor circuit of Example Z01. Example Z08 includes an apparatus comprising means for executing the instructions of Example Z01. Example Z09 includes a signal generated as a result of executing the instructions of Example Z01. Example Z10 includes a data unit generated as a result of executing the instructions of Example Z01.

[0360] Example Z11 includes the data units of Example Z10 and / or some other examples herein, where the data unit is a datagram, network packet, data frame, data segment, protocol data unit (PDU), service data unit (SDU), message, or database object. Example Z12 includes a signal encoded with the data units of Example Z10 and / or Z11. Example Z13 includes an electromagnetic signal that conveys the instructions of Example Z01. Example Z14 includes an apparatus comprising means for performing any one of the methods of Examples 1-26 and / or Y01-Y03 and / or some other examples herein.

[0361] An exemplary implementation includes a multi-access edge computing (MEC) host that executes a service as part of one or more MEC applications instantiated on a virtualization infrastructure, where the service is related to any of Examples 1-26 and / or Y01-Y03 or a part thereof and / or some other examples herein, and the MEC host is configurable or operable to operate according to specifications from one or more ETSI MEC standard families.

[0362] An exemplary implementation is an edge computing system that includes each edge processing device and node for invoking or executing the operations of Examples 1-26 or other topics described herein. Another exemplary implementation is a client endpoint node operable to invoke or execute the operations of Examples 1-26 or other topics described herein. Another exemplary implementation is an aggregation node, network hub node, gateway node, or core data processing node within or coupled to an edge computing system, operable to invoke or execute the operations of Examples 1-26 and / or Y01-Y03 or other topics described herein. Another exemplary implementation is an access point, base station, roadside unit, street-side unit, or on-premises unit within or coupled to an edge computing system, operable to invoke or execute the operations of Examples 1-26 and / or Y01-Y03 or other topics described herein. Another exemplary implementation is an edge provisioning node, service orchestration node, application orchestration node, or multi-tenant management node within or coupled to an edge computing system, operable to invoke or execute the operations of Examples 1-26 and / or Y01-Y03 or other topics described herein.

[0363] Another exemplary implementation is an edge provisioning service, application or service orchestration service, virtual machine deployment, container deployment, function deployment, and edge node that operates to call or execute the operations of Examples 1-26 and / or Y01-Y03, or other subject matter described herein, within or coupled to an edge computing system. Another exemplary implementation is an edge computing system that operates as an edge mesh, with sidecar loading, or as an edge mesh with inter-mesh communication, that is operable to call or execute the operations of Examples 1-26 and / or Y01-Y03, or other subject matter described herein. Another exemplary implementation is an edge computing system that includes network functions, acceleration functions, acceleration hardware, storage hardware, or computing hardware resources that are operable to call or execute the use cases described herein using Examples 1-26 and / or Y01-Y03, or other subject matter described herein. Another exemplary implementation is an edge computing system that is adapted to support client mobility, vehicle-to-vehicle (V2V), vehicle-to-vehicle and infrastructure-to-vehicle (V2X), or infrastructure-to-vehicle (V2I) scenarios and optionally operates to call or execute the use cases described herein using Examples 1-26 and / or Y01-Y03, or other subject matter described herein, and that operates according to the ETSI MEC specification. Another exemplary implementation is an edge computing system adapted for mobile wireless communication that includes a configuration by 3GPP (registered trademark) 4G / LTE or 5G network capabilities that is operable to call or execute the use cases described herein using Examples 1-26, and / or other subject matter described herein.Another exemplary implementation is an edge computing system that supports xApps and is adapted to operate according to the O-RAN specification, and is operable to invoke or execute the use cases described herein using Examples 1-26 and / or Y01-Y03, or other subject matter described herein. Another exemplary implementation is an edge computing system that is adapted to operate according to the Open Visual Inference and Neural Network Optimization (OpenVINO) specification and is operable to invoke or execute the use cases described herein using Examples 1-26 and / or Y01-Y03, or other subject matter described herein. Another exemplary implementation is an edge computing system that is adapted to operate according to the OpenNESS specification and is operable to invoke or execute the use cases described herein using Examples 1-26 and / or Y01-Y03, or other subject matter described herein. Another exemplary implementation is an edge computing system that is adapted to operate according to a smart edge computing framework and is operable to invoke or execute the use cases described herein using Examples 1-26 and / or Y01-Y03, or other subject matter described herein.

[0364] Any of the above examples can be combined with any other example (or combination of examples) unless otherwise specified.

[0365] 2. Terms The terms used in this specification are for the purpose of this disclosure only and are not intended to limit this disclosure. This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and / or computer program products of this disclosure. In the drawings, some structural or methodological features can be shown in a particular arrangement and / or ordering. However, it should be understood that such a particular arrangement and / or ordering may not be required. Rather, such features may be arranged in a different manner and / or ordering than that shown in the exemplary figures. Additionally, including a structural or methodological feature in a particular figure does not mean that such a feature is required in all implementations, and it may not be included, or it may be combined with other features.

[0366] As used in this specification, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises" and / or "comprising", as used in this specification, specifically denote the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. The phrase "A and / or B" means (A), (B), or (A and B). For the purposes of this disclosure, the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). The terms "comprising", "including", "having", etc., used with respect to this disclosure are synonyms.

[0367] The terms "coupled" and "communicatively coupled" are used herein along with their derivatives. The term "coupled" may mean that two or more elements are in direct physical or electrical contact with each other, that two or more elements are in indirect contact with each other but still cooperate or interact with each other, and / or that one or more other elements are coupled or connected between the elements said to be coupled to each other. The term "directly coupled" may mean that two or more elements are in direct contact with each other. The term "communicatively coupled" may mean that two or more elements can contact each other by means of communication, including through a wired or other interconnection, through a wireless communication channel or link, etc.

[0368] The term "circuitry" refers to a circuit or a system of multiple circuits configured to perform a specific function of an electronic device. The circuit or the system of circuits can be or include part of one or more hardware components such as a logic circuit, a processor (shared, dedicated, or group), and / or a memory (shared, dedicated, or group), an ASIC, an FPGA, a programmable logic controller (PLC), a SoC, a SiP, a multi-chip package (MCP), a DSP, etc., and they are configured to provide the described function. Additionally, the term "circuitry" can also refer to a combination of one or more hardware elements and program code used to execute the function of the program code. Some types of circuitry can execute one or more software or firmware programs to provide at least some of the described functions. Such a combination of a hardware element and program code may sometimes be referred to as a specific type of circuitry.

[0369] It should be understood that the functional units or capabilities described herein may be referred to or labeled as components or modules in order to more specifically emphasize their implementation independence. Such components may be embodied in any number of software or hardware forms. For example, a component or module may be implemented as a hardware circuit comprising off-the-shelf semiconductors such as custom very large scale integration (VLSI) circuits or gate arrays, logic chips, transistors, or other discrete components. A component or module may also be implemented in a programmable hardware device such as a field programmable gate array, programmable array logic, programmable logic device. A component or module may also be implemented in software for execution by various types of processors. An identified component or module of executable code can, for example, include one or more physical or logical blocks of computer instructions, which can be organized, for example, as objects, routines, or functions. Nevertheless, the executable files of the identified components or modules need not be physically located together, but can include components or modules when logically combined together and can include different instructions stored in different locations that achieve the stated purpose of the components or modules.

[0370] In fact, the components or modules of executable code may be a single instruction or many instructions, and may be distributed across several different code segments, different programs, and several memory devices or processing systems. In particular, some of the described processes (e.g., code rewriting and code analysis) may be performed on a processing system different from the processing system on which the code is deployed (e.g., in a computer incorporated in a sensor or robot), such as in a computer within a data center. Similarly, the operation data may be identified and illustrated within a component or module herein, embodied in any suitable form, and organized within any suitable type of data structure. The operation data may be collected as a single data set, or distributed across different locations including different storage devices, and may exist at least partially only as electronic signals on a system or network. A component or module can be passive or active, including agents operable to perform a desired function.

[0371] As used herein, the term "processor circuitry" refers to, is part of, or includes a circuit that can sequentially and automatically perform a series of arithmetic or logical operations, or record, store, and / or transfer digital data. The term "processor circuitry" can refer to one or more application processors, one or more baseband processors, a physical CPU, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and / or any other device capable of executing or otherwise operating computer-executable instructions such as program code, software modules, and / or functional processes. The terms "application circuitry" and / or "baseband circuitry" may be considered synonymous with "processor circuitry" and may be referred to as "processor circuitry".

[0372] As used herein, the terms "memory" and / or "memory circuit" refer to one or more hardware devices for storing data, including RAM, MRAM, PRAM, DRAM, and / or SDRAM, core memory, ROM, magnetic disk storage media, optical storage media, flash memory devices, or other machine-readable media for storing data. The term "computer-readable medium" can include, but is not limited to, memory, portable or fixed storage devices, optical storage devices, and various other media capable of storing, storing, or transporting instructions or data.

[0373] As used herein, the term "interface circuit" refers to, is part of, or includes a circuit that enables the exchange of information between two or more components or devices. The term "interface circuit" can refer to one or more hardware interfaces, such as a bus, I / O interface, peripheral component interface, network interface card, and the like.

[0374] The term "element" refers to a unit that is indivisible at a given level of abstraction and has a well-defined boundary, and an element can be any type of entity, including, for example, one or more devices, systems, controllers, network elements, modules, etc., or combinations thereof. The term "device" refers to a physical entity incorporated into or attached to another physical entity in the vicinity of which digital information is transmitted from or to its physical entity. The term "entity" refers to a distinct component of an architecture or device, or information transferred as a payload. The term "controller" refers to an element or entity having the ability to affect a physical entity, such as by changing its state or moving a physical entity.

[0375] As used herein, the term "edge computing" encompasses many implementations of distributed computing that move processing activities and resources (e.g., computing, storage, acceleration resources) towards the "edge" of the network as part of an effort to reduce latency and improve throughput for endpoint users (such as client devices, user equipment, etc.). Such edge computing implementations typically involve providing such activities and resources in services, functions, applications, and subsystems such as the cloud from one or more locations accessible via a wireless network. Thus, references herein to the "edge" of a network, cluster, domain, system, or computing arrangement are to a group or grouping of functional distributed computing elements and are thus generally unrelated to the "edges" (links or connections) used in graph theory. Certain arrangements of edge computing applications and services accessible via mobile wireless networks (such as cellular and WiFi data networks) may be referred to as "mobile edge computing" or "multi-access edge computing" and may be referenced by the acronym "MEC". The use of "MEC" herein may also refer to a standardized implementation form published by the European Telecommunications Standards Institute (ETSI) called "ETSI MEC". Terms used by the ETSI MEC specifications are generally incorporated herein by reference unless conflicting definitions or uses are provided herein.

[0376] As used herein, the terms "computing node" or "computing device" refer to a distinguishable entity that implements elements of edge computing operations, whether it is part of a larger system, a distributed set of systems, or a stand-alone device. A computing node may be referred to as an "edge node", "edge device", or "edge system", regardless of whether it is operating as a client, server, or intermediate entity. Specific implementations of a computing node can be incorporated into, for example, a server, a base station, a gateway, a roadside unit, an on-premises unit, a UE, or an end-consumer device.

[0377] As used herein, the term "computer system" refers to any type of interconnected electronic device, computer device, or components thereof. Additionally, the terms "computer system" and / or "system" can refer to various components of computers communicatively coupled to each other. Further, the terms "computer system" and / or "system" can refer to multiple computer devices and / or multiple computing systems configured to communicate with each other and share computing resources and / or networking resources.

[0378] As used herein, the term "architecture" refers to a computer architecture or a network architecture. "Network architecture" is the physical and logical design or arrangement of the software and / or hardware elements of a network, including communication protocols, interfaces, and media transmission. "Computer architecture" is the physical and logical design or arrangement of the software and / or hardware elements in a computing system or platform, including the technical specifications for their interaction.

[0379] As used herein, terms such as "appliance" and "computer appliance" refer to a computer device or system with program code (e.g., software or firmware) specifically designed to provide certain computing resources. A "virtual appliance" is a virtual machine image that virtualizes or emulates a computer appliance or, if not, is implemented by a device with a hypervisor dedicated to providing certain computing resources.

[0380] As used herein, the term "user equipment" or "UE" refers to a device with wireless communication capabilities and can represent a remote user of network resources of a communication network. The term "user equipment" or "UE" may be considered synonymous with and may be referred to as client, mobile, mobile device, mobile terminal, user terminal, mobile unit, station, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, wireless device, reconfigurable wireless device, reconfigurable mobile device, etc. Further, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device including a wireless communication interface. The term "station" or "STA" refers to a logical entity that is a single addressable instance of a medium access control (MAC) and physical layer (PHY) interface to a wireless medium (WM). The term "wireless medium" or "WM" refers to the medium used to carry out the transfer of protocol data units (PDUs) between peer physical layer (PHY) entities of a wireless local area network (LAN).

[0381] As used herein, the term "network element" refers to physical or virtualized devices and / or infrastructure used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with, and / or referred to as, networked computers, networking hardware, network devices, network nodes, routers, switches, hubs, bridges, wireless network controllers, RAN devices, RAN nodes, gateways, servers, virtualized VNFs, NFVIs, etc.

[0382] As used herein, the term "access point" or "AP" refers to an entity that includes one station (STA) and provides access to delivery services to the associated STA via a wireless medium (WM). The AP comprises the STA and a delivery system access function (DSAF). As used herein, the term "base station" refers to a network element of a radio access network (RAN), such as a 4th generation (4G) or 5th generation (5G) mobile communication network, responsible for transmitting and receiving radio signals in one or more cells between user equipment (UE). The base station can have an integrated antenna or can be connected to an antenna array by a feeder cable. The base station uses dedicated digital signal processing and network function hardware. The base station can be divided into multiple functional blocks that operate in software for flexibility, cost, and performance. The base station can include an evolved Node B (eNB) or a next generation Node B (gNB). The base station can operate or include computing hardware to operate as a computing node. However, in many of the scenarios described herein, the RAN base station can be replaced by an access point (e.g., a wireless network access point) or other network access hardware.

[0383] As used herein, the term "central office" (or CO) refers to a convergence point of telecommunications infrastructure within an accessible or defined geographic area, and in many cases, telecommunications service providers have conventionally located switching equipment for one or more types of access networks. A CO can be physically designed to house telecommunications infrastructure equipment or computing, data storage, and network resources. However, a CO need not be a location designated by a telecommunications service provider. A CO can host any number of computing devices for edge applications and services, or even for local implementations of services such as the cloud.

[0384] The term "cloud computing" or "the cloud" refers to a paradigm that enables network access to a scalable and elastic pool of sharable computing resources using self-service provisioning and on-demand management, without the need for active management by the user. Cloud computing provides cloud computing services (or cloud services), which are one or more capabilities provided via cloud computing that are invoked using a defined interface (e.g., an API, etc.). The term "computing resource" or simply "resource" refers to any physical or virtual component within a computer system or network whose availability is limited, or the use of such components. Examples of computing resources include use / access to a server, processor, storage device, memory device, memory area, network, power, input / output (peripheral) devices, mechanical devices, network connections (e.g., channels / links, ports, network sockets, etc.), operating system, virtual machine (VM), software / application, computer file, etc. for a period of time. "Hardware resources" can refer to computing, storage, and / or network resources provided by physical hardware elements. "Virtualized resources" can refer to computing, storage, and / or network resources provided to applications, devices, systems, etc. by a virtualization infrastructure. The term "network resource" or "communication resource" can refer to resources accessible by computer devices / systems via a communication network. The term "system resource" can refer to any kind of shared entity for providing services and can include computing resources and / or network resources.System resources can be thought of as a set of coherent functions, network data objects, or services that are accessible through a server where such system resources exist on a single host or multiple hosts and are clearly identifiable.

[0385] The term "workload" refers to the amount of work performed by a computing system, device, entity, etc. over a period of time or at a particular instant. A workload can be represented as a benchmark such as response time, throughput (e.g., how much work is achieved over a period of time), etc. Additionally or alternatively, a workload can be represented as a memory workload (e.g., the amount of memory space required for program execution to store temporary or persistent data and perform intermediate calculations), a processor workload (e.g., several instructions executed by a processor over a given period of time or at a particular instant), an I / O workload (e.g., several inputs and outputs or system accesses over a given period of time or at a particular point in time), a database workload (e.g., several database queries over a period of time), a network-related workload (e.g., the number of network attachments, the number of mobility updates, the number of wireless link failures, the number of handovers, the amount of data transferred over an air interface, etc.). Various algorithms can be used to determine a workload and / or workload characteristics that can be based on any of the aforementioned workload types.

[0386] As used herein, the term "cloud service provider" (or CSP) refers to an organization that operates typically large-scale "cloud" resources consisting of centralized, regional, and edge data centers (e.g., as used in the context of a public cloud). In other examples, a CSP may also be referred to as a cloud service operator (CSO). References to "cloud computing" generally refer to computing resources and services provided by a CSP or CSO at a remote location where there is at least some increased latency, distance, or constraint relative to edge computing.

[0387] As used herein, the term "data center" refers to a dedicated structure designed to house multiple high-performance computing and data storage nodes such that large amounts of computing, data storage, and network resources exist at a single location. This often requires special rack and enclosure systems, appropriate heating, cooling, ventilation, security, fire suppression, and power supply systems. The term may also, in some cont...

Claims

1. An apparatus adopted as a high-level road traffic system station (ITS-S), wherein the apparatus comprises: a memory circuit configured to store instructions of a collective perception service (CPS) facility; a processor circuit connected to the memory circuit, wherein the processor circuit operates the CPS to generate a collective perception message (CPM) including a hierarchical cost map container including a cost value of a hierarchical cost map available in the ITS-S and a corresponding reliability level; cause transmission of the CPM to one or more other ITS-Ss configured processor circuit and comprising, the hierarchical cost map includes a set of layers, the set of layers includes an aggregated cost map layer, the apparatus, wherein the aggregated cost map layer is an aggregation of each layer of the set of layers.

2. The processor circuit operates the CPS to select the aggregated cost map layer such that one or more values of each cell of the aggregated cost map layer are included in the CPM when the values change beyond an aggregated layer threshold. The apparatus according to claim 1, wherein the apparatus is configured as described above.

3. The one or more values are a cost value of each cell or a reliability level of each cell, The apparatus according to claim 2, wherein the aggregated layer threshold is based on a part of the total number of cells of the aggregated cost map layer in which the cost value or the reliability level has changed as compared with the cost value or the reliability level in the previous aggregated cost map layer of the previously transmitted CPM.

4. The processor circuit operates the CPS to generate the set of layers of the hierarchical cost map, divide each layer of the set of layers into a set of cells, Based on sensor data obtained from one or more sensors accessible by the ITS-S, a static map available in the ITS-S, and information obtained from one or more adjacent ITS-Ss, determine the respective cost values of the corresponding cells of the set of cells. The apparatus according to any one of claims 1 to 3, wherein the apparatus is configured as described above.

5. The processor circuit operates the CPS to be configured to determine to include the aggregated cost map layer in the hierarchical cost map container of the CPM, and the determination is made by When the difference between the current Euclidean distance of the center point of the hierarchical cost map and the previous Euclidean distance of the center point of the previous hierarchical cost map included in the previously transmitted CPM exceeds the center point position change threshold, and When the difference between the current dimensions of the hierarchical cost map and the previous dimensions of the hierarchical cost map included in the previously transmitted CPM exceeds the dimension change threshold, and When the difference between the current orientation of the hierarchical cost map and the previous orientation of the hierarchical cost map included in the previously transmitted CPM exceeds the orientation change threshold, and When the elapsed time from the previous time when the aggregated cost map layer was included in the previously transmitted CPM exceeds the threshold time (T_GenCpmMax), where the T_GenCpmMax is the elapsed time from the start of the previous CPM generation event to the current CPM generation event, The apparatus according to claim 4, wherein one or more of the above are satisfied.

6. The set of layers includes a mismatch processing cost map layer, and the mismatch processing cost map layer indicates cells where there is a mismatch between the cost value or the reliability level of the hierarchical cost map and the cost value or the reliability level of another hierarchical cost map received from one or more adjacent ITS-Ss. The processor circuit operates the CPS to Determine to include the hierarchical cost map container with the mismatch processing cost map layer in the CPM when one or more values of each cell of the mismatch processing cost map layer change beyond a mismatch threshold, The one or more values of each cell of the mismatch processing cost map layer are the cost value or the reliability level of the respective cell, The apparatus according to claim 4 or 5, wherein the mismatch threshold is based on a part of the total number of cells of the mismatch processing cost map layer or the aggregated cost map layer where the cost value or the reliability level has changed compared to the cost value or the reliability level of the cost map layer of the CPM received from adjacent ITS-Ss.

7. The set of layers includes a collaboration request cost map layer, the collaboration request cost map layer indicates cells where the ITS-S was unable to determine perception at a minimum reliability level, and the processor circuit operates the CPS to, include, in the CPM, the hierarchical cost map container with the collaboration request cost map layer when the reliability level for perception in one or more cells of the hierarchical cost map is lower than a reliability level threshold by more than a threshold number of cells in the cell in the aggregated cost map layer. The apparatus according to claim 6, which is configured to determine. [

8. ] The set of layers includes one or more of a static cost map layer indicating a perceived permanent structure, a perceived object cost map layer indicating one or more perceived objects, whether dynamic or static, an inflation cost map layer indicating a respective buffer region around the one or more perceived objects or the permanent structure, and an aggregated perception cost map layer indicating one or more perceived objects received from one or more adjacent ITS-Ss, and the processor circuit operates the CPS to, is configured to determine to include, in the CPM, the hierarchical cost map container with the corresponding one of the static cost map layer, the perceived object cost map layer, the inflation cost map layer, and the aggregated perception cost map layer, and the determination is made when, the reliability level of one or more cells of the static cost map layer, the perceived object cost map layer, the inflation cost map layer, or the aggregated perception cost map layer is lower than a reliability level threshold by more than a threshold number of cells in the hierarchical cost map compared to the cost value or reliability level of the same cost map layer of the previously transmitted CPM, and when the time elapsed since the last time the same cost map layer was included in the previously transmitted CPM exceeds another threshold time, the other threshold time being based on a predefined time that elapses between continuously including cost map layers other than the aggregated cost map layer in the CPM and a threshold time (T_GenCpmMax), one or more of which is the apparatus according to claim 6 or 7.

9. The processor circuit is configured to operate the CPS to prepare the aggregated cost map layer by aggregating each layer of the set of layers, the apparatus according to any one of claims 4 to 8.

10. To prepare the hierarchical cost map, the processor circuit is configured to operate the CPS to prepare the hierarchical cost map to have dimensions specified based on the field of view (FOV) of the one or more sensors, and periodically update the aggregated cost map layer, wherein a period for updating the aggregated cost map layer is shorter than a CPM generation event period, the periodically updating, the apparatus according to claim 9, configured to perform one or both of.

11. The processor circuit is configured to operate the CPS to generate the CPM, a ReportedCostMapGridArea data frame (DF) for including dimensions of the hierarchical cost map, a GridCellSizeX data element (DE) and a GridCellSizeY DE for including dimensions of each cell of the set of cells, a NumberOfLayeredCostMap data frame for indicating the number of cost map layers of the hierarchical cost map container, a PerGridCellCostValueConfigType DF for including cost values of cells of the set of cells, a PerGridCellConfidenceLevelConfigType DF for including confidence levels of the cells of the set of cells the apparatus according to claim 9 or 10, configured to include one or more of.

12. At least one layer of the set of layers has a different format from at least one other layer of the set of layers, the apparatus according to any one of claims 9 to 11.

13. An apparatus adopted as an intelligent transport system station (ITS-S), the apparatus comprising: a memory circuit configured to store instructions of a collective perception service (CPS) facility, a processor circuit connected to the memory circuit, the processor circuit being configured to operate the CPS to Generate a collective perception message (CPM) that includes a hierarchical cost map container containing the cost values of the hierarchical cost map available in the ITS-S and the corresponding reliability levels, Cause transmission of the CPM to one or more other ITS-Ss A processor circuit configured to Comprising, The hierarchical cost map includes a set of layers, Each layer of the set of layers includes a set of cells, The set of layers includes a mismatch processing cost map layer, The mismatch processing cost map layer indicates cells where there is a mismatch between the cost value or the reliability level of the hierarchical cost map and the cost value or reliability level of another hierarchical cost map received from one or more adjacent ITS-Ss, a device.

14. The processor circuit is configured to operate the CPS to Detect a CPM generation event, and the CPM is generated in response to detection of the CPM generation event, the device according to any one of claims 1 to 13.

15. The ITS-S is a vehicle ITS-S (V-ITS-S), a roadside ITS-S (R-ITS-S), or a vulnerable road user (VRU) ITS-S, the device according to any one of claims 1 to 14.

16. A method of operating a collective perception service (CPS) facility in a facility layer of an advanced road traffic system station (ITS-S), the method comprising: Generating a collective perception message (CPM), the CPM including a hierarchical cost map container, the hierarchical cost map container including the cost values of the hierarchical cost map available in the ITS-S and the corresponding reliability levels, a generating step; Causing transmission of the CPM to one or more other ITS-Ss Comprising, The hierarchical cost map includes a set of layers, The set of layers includes an aggregated cost map layer, The aggregated cost map layer is an aggregation of each layer of the set of layers, a method.

17. Each layer of the set of layers includes a set of cells arranged in a grid, the method comprising, Determining a cost value for a corresponding cell of the set of cells of each layer based on sensor data obtained from the one or more sensors accessible by the ITS-S, a static map available in the ITS-S, and information obtained from one or more adjacent ITS-Ss The method according to claim 16, comprising this.

18. The set of layers includes a mismatch processing cost map layer, and the mismatch processing cost map layer indicates cells where there is a mismatch between the cost value or reliability level of the hierarchical cost map and the cost value or reliability level of another hierarchical cost map received from one or more adjacent ITS-Ss. The method according to claim 17.

19. The set of layers includes a collaboration request cost map layer, and the collaboration request cost map layer indicates cells where the ITS-S was unable to determine a perception at a minimum reliability level. The method according to claim 18.

20. The set of layers includes one or more of a static cost map layer indicating a perceived permanent structure, a perceived object cost map layer indicating one or more perceived objects, whether dynamic or static, an inflation cost map layer indicating each buffer region around the one or more perceived objects or the permanent structure, and a collective perception cost map layer indicating one or more perceived objects received from one or more adjacent ITS-Ss. The method according to claim 19.

21. Preparing the aggregated cost map layer by aggregating each layer of the set of layers The method according to any one of claims 17 to 20, further comprising this.

22. The step of preparing the hierarchical cost map Further comprising The step of preparing the hierarchical cost map is Preparing the hierarchical cost map to have dimensions specified based on the field of view (FOV) of the one or more sensors Periodically updating the aggregated cost map layer, wherein the period for updating the aggregated cost map layer is shorter than the CPM generation event period. The method according to claim 17, having one or both of the periodically updating steps

23. The generating step generates the CPM and ​ A ReportedCostMapGridArea data frame (DF) for including the dimensions of the hierarchical cost map, a GridCellSizeX data element (DE) and a GridCellSizeY DE for including the dimensions of each cell in the set of cells, a NumberOfLayeredCostMap DF for indicating the number of cost map layers in the hierarchical cost map container, a PerGridCellCostValueConfigType DF for including the cost values of the cells in the set of cells, a PerGridCellConfidenceLevelConfigType DF for including the confidence levels of the cells in the set of cells The method according to any one of claims 17 to 22, having a step including one or more of the above.

24. The method according to any one of claims 17 to 23, wherein at least one layer of the set of layers has a different format from at least one other layer of the set of layers.

25. A method for operating a collective perception service (CPS) facility in a facility layer of an intelligent transportation system station (ITS-S), the method comprising: generating a collective perception message (CPM), the CPM including a hierarchical cost map container, the hierarchical cost map container including cost values and corresponding confidence levels of a hierarchical cost map available in the ITS-S; causing transmission of the CPM to one or more other ITS-Ss; comprising the hierarchical cost map includes a set of layers, each layer of the set of layers includes a set of cells, the set of layers includes a mismatch processing cost map layer, the mismatch processing cost map layer indicates cells having a mismatch between the cost value or the confidence level of the hierarchical cost map and the cost value or confidence level of another hierarchical cost map received from one or more adjacent ITS-Ss; method.

26. Detecting a CPM generation event further comprising The method according to any one of claims 16 to 25, wherein the step of generating the CPM is based on the detection of the CPM generation event.

27. The method according to any one of claims 16 to 26, wherein the ITS-S is a vehicle ITS-S (V-ITS-S), a roadside ITS-S (R-ITS-S), or a vulnerable road user (VRU) ITS-S. **Claim 28** A computer program stored on one or more computer-readable storage media, the computer program causing an advanced road traffic system to execute the method according to any one of claims 16 to 27.

Images