Patent Application
20220383750
Embodiments described herein generally relate to edge computing, network communication, and communication system implementations, and in particular, to connected and computer-assisted and/or autonomous driving vehicles, Internet of Vehicles, Internet of Things (IoT) technologies, and Intelligent Transportation Systems.
Intelligent Transport Systems (ITS) comprise advanced applications and services related to different modes of transportation and traffic to enable an increase in traffic safety and efficiency, and to reduce emissions and fuel consumption. Various forms of wireless communications and/or Radio Access Technologies (RATs) may be used for ITS. These RATs may need to coexist in one or more communication channels, such as those available in the 5.9 Gigahertz (GHz) band. Existing RATs do not have mechanisms to coexist with one another and are usually not interoperable with one another. Cooperative Intelligent Transport Systems (C-ITS) have been developed to enable an increase in traffic safety and efficiency, and to reduce emissions and fuel consumption. The initial focus of C-ITS was on road traffic safety and especially on vehicle safety. Recent efforts are being made to increase traffic safety and efficiency for vulnerable road users (VRUs), which refers to both physical entities (e.g., pedestrians) and/or user devices (e.g., mobile stations, etc.) used by physical entities. Regulation (EU) No 168/2013 of the European Parliament and of the Council of 15 Jan. 2013 on the approval and market surveillance of two- or three-wheel vehicles and quadricycles (“EU regulation 168/2013”) provides various examples of VRUs. Computer-assisted and/or autonomous driving vehicles (“CA/AD vehicles”) are expected to reduce VRU-related injuries and fatalities by eliminating or reducing human-error in operating vehicles. However, to date CA/AD vehicles can do very little about detection, let alone correction of the human-error at VRUs' end, even though it is equipped with a sophisticated sensing technology suite, as well as computing and mapping technologies.
In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which:
The operation and control of vehicles is becoming more autonomous over time, and most vehicles will likely become fully autonomous in the future. Vehicles that include some form of autonomy or otherwise assist a human operator may be referred to herein as “computer-assisted or autonomous driving” vehicles. Computer-assisted or autonomous driving (CA/AD) vehicles may include Artificial Intelligence (AI), machine learning (ML), and/or other like self-learning systems to enable autonomous operation and/or provide driving assistance capabilities. Typically, these systems perceive their environment (e.g., using sensor data) and perform various actions to maximize the likelihood of successful vehicle operation.
The Vehicle-to-Everything (V2X) applications (referred to simply 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 communications (V2P), and ITS station (ITS-S) to ITS-S communication (X2X). V2X applications can use co-operative awareness to provide more intelligent services for end-users. This means that entities, such as vehicle stations or vehicle user equipment (vUEs) including such as CA/AD vehicles, roadside infrastructure or roadside units (RSUs), application servers, and pedestrian devices (e.g., smartphones, tablets, etc.), collect knowledge of their local environment (e.g., information received from other vehicles or sensor equipment in proximity) to process and share that knowledge in order to provide more intelligent services, such as cooperative perception, maneuver coordination, and the like, which are used for collision warning systems, autonomous driving, and/or the like.
One such V2X application include Intelligent Transport Systems (ITS), which are systems to support transportation of goods and humans with information and communication technologies in order to efficiently and safely use the transport infrastructure and transport means (e.g., automobiles, trains, aircraft, watercraft, etc.). Elements of ITS are standardized in various standardization organizations, both on an international level and on regional levels. Communications in ITS (ITSC) may utilize a variety of existing and new access technologies (or radio access technologies (RAT)) and ITS applications. Examples of these V2X RATs include Institute of Electrical and Electronics Engineers (IEEE) RATs and Third Generation Partnership (3GPP) RATs. The IEEE V2X RATs include, for example, Wireless Access in Vehicular Environments (WAVE), Dedicated Short Range Communication (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 referred to as Worldwide Interoperability for Microwave Access (WiMAX). The term “DSRC” refers to vehicular communications in the 5.9 GHz frequency band that is generally used in the United States, while “ITS-G5” refers to vehicular communications in the 5.9 GHz frequency band in Europe. Since the present embodiments are applicable to any number of different RATs (including IEEE 802.11p-based RATs) that may be used in any geographic or political region, the terms “DSRC” (used, among other regions, in the U.S.) and “ITS-G5” (used, among other regions, in Europe) may be used interchangeably throughout this disclosure. The 3GPP V2X RATs include, for example, cellular V2X (C-V2X) using Long Term Evolution (LTE) technologies (sometimes referred to as “LTE-V2X”) and/or using Fifth Generation (5G) technologies (sometimes referred to as “5G-V2X” or “NR-V2X”). Other RATs may be used for ITS and/or V2X applications such as RATs using UHF and VHF frequencies, Global System for Mobile Communications (GSM), and/or other wireless communication technologies.
For illustrative purposes, the following description is provided for deployment scenarios including vehicles 110 in a 2D freeway/highway/roadway environment wherein the vehicles 110 are automobiles. However, the embodiments described herein are also applicable to other types of vehicles, such as trucks, busses, motorboats, motorcycles, electric personal transporters, and/or any other motorized devices capable of transporting people or goods. Also, embodiments described herein are applicable to social networking between vehicles of different vehicle types. The embodiments described herein may also be applicable to 3D deployment scenarios where some or all of the vehicles 110 are implemented as flying objects, such as aircraft, drones, UAVs, and/or to any other like motorized devices.
For illustrative purposes, the following description is provided for example embodiments where the vehicles 110 include in-vehicle systems (IVS) 101, which are discussed in more detail infra. However, the vehicles 110 could include additional or alternative types of computing devices/systems such as smartphones, tablets, wearables, laptops, laptop computer, in-vehicle infotainment system, in-car entertainment system, instrument cluster, head-up display (HUD) device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, microcontroller, control module, engine management system, and the like that may be operable to perform the various embodiments discussed herein. Vehicles 110 including a computing system (e.g., IVS 101) as well as the vehicles referenced throughout the present disclosure, may be referred to as vehicle user equipment (vUE) 110, vehicle stations 110, vehicle ITS stations (V-ITS-S) 110, computer assisted (CA)/autonomous driving (AD) vehicles 110, and/or the like.
Each vehicle 110 includes an in-vehicle system (IVS) 101, one or more sensors 172, and one or more driving control units (DCUs) 174. The IVS 100 includes a number of vehicle computing hardware subsystems and/or applications including, for example, various hardware and software elements to implement the ITS architecture of
The IVS 101 includes the ITS-S 103, which may be the same or similar to the ITS-S 1101 of
Except for the UVCS technology of the present disclosure, IVS 101 and CA/AD vehicle 110 otherwise may be any one of a number of in-vehicle systems and CA/AD vehicles, from computer-assisted to partially or fully autonomous vehicles. Additionally, the IVS 101 and CA/AD vehicle 110 may include other components/subsystems not shown by
In addition to the functionality discussed herein, the ITS-S 1101 (or the underlying V2X RAT circuitry on which the ITS-S 1101 operates) is capable of measuring various signals or determining/identifying various signal/channel characteristics. Signal measurement may be performed for cell selection, handover, network attachment, testing, and/or other purposes. The measurements/characteristics collected by the ITS-S 1101 (or V2X RAT circuitry) may include one or more of the following: a bandwidth (BW), network or cell load, latency, jitter, round trip time (RTT), number of interrupts, out-of-order delivery of data packets, transmission power, bit error rate, bit error ratio (BER), Block Error Rate (BLER), packet loss rate (PLR), packet reception rate (PRR), Channel Busy Ratio (CBR), Channel occupancy Ratio (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 cell frames for UE positioning for E-UTRAN or 5G/NR (e.g., a timing between a NAN 130 reference time and a 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 ith GNSS satellite signal), GNSS carrier phase measurements (e.g., the number of carrier-phase cycles (integer and fractional parts) of the ith GNSS satellite signal, measured since locking onto the signal; also called Accumulated Delta Range (ADR)), channel interference measurement, thermal noise power measurement, received interference power measurement, and/or other like measurements. The RSRP, RSSI, and/or RSRQ measurements may include RSRP, RSSI, and/or RSRQ measurements of cell-specific reference signals, channel state information reference signals (CSI-RS), and/or synchronization signals (SS) or SS blocks for 3GPP networks (e.g., LTE or 5G/NR) and RSRP, RSSI, and/or RSRQ measurements of various beacon, FILS discovery frames, or probe response frames for IEEE 802.11 WLAN/WiFi networks. Other measurements may be additionally or alternatively used, such as those discussed in 3GPP TS 36.214 v15.4.0 (2019 September), 3GPP TS 38.215 v16.1.0 (2020 April), IEEE 802.11, Part 11: “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, IEEE Std.”, and/or the like. The same or similar measurements may be measured or collected by the NAN 130.
The subsystems/applications may also include instrument cluster subsystems, front-seat and/or back-seat infotainment subsystems and/or other like media subsystems, a navigation subsystem (NAV) 102, a vehicle status subsystem/application, a HUD subsystem, an EMA subsystem, and so forth. The NAV 102 may be configurable or operable to provide navigation guidance or control, depending on whether vehicle 110 is a computer-assisted vehicle, partially or fully autonomous driving vehicle. NAV 102 may be configured with computer vision to recognize stationary or moving objects (e.g., a pedestrian, another vehicle, or some other moving object) in an area surrounding vehicle 110, as it travels enroute to its destination. The NAV 102 may be configurable or operable to recognize stationary or moving objects in the area surrounding vehicle 110, and in response, make its decision in guiding or controlling DCUs of vehicle 110, based at least in part on sensor data collected by sensors 172.
The DCUs 174 include hardware elements that control various systems of the vehicles 110, such as the operation of the engine, the transmission, steering, braking, etc. DCUs 174 are embedded systems or other like computer devices that control a corresponding system of a vehicle 110. The DCUs 174 may each have the same or similar components as devices/systems of
IVS 101, on its own or in response to user interactions, communicates or interacts with one or more vehicles 110 via interface 153, which may be, for example, 3GPP-based direct links or IEEE-based direct links. The 3GPP (e.g., LTE or 5G/NR) direct links may be sidelinks, Proximity Services (ProSe) links, and/or PC5 interfaces/links, IEEE (WiFi) based direct links or a personal area network (PAN) based links may be, for example, WiFi-direct links, IEEE 802.11p links, IEEE 802.11bd links, IEEE 802.15.4 links (e.g., ZigBee, IPv6 over Low power Wireless Personal Area Networks (6LoWPAN), WirelessHART, MiWi, Thread, etc.). Other technologies could be used, such as Bluetooth/Bluetooth Low Energy (BLE) or the like. In various embodiments, the vehicles 110 may exchange ITS protocol data units (PDUs) or other messages of the example embodiments with one another over the interface 153.
IVS 101, on its own or in response to user interactions, communicates or interacts with one or more remote/cloud servers 160 via NAN 130 over interface 112 and over network 158. The NAN 130 is arranged to provide network connectivity to the vehicles 110 via respective interfaces 112 between the NAN 130 and the individual vehicles 110. The NAN 130 is, or includes, an ITS-S, and may be a roadside ITS-S(R-ITS-S). The NAN 130 is a network element that is part of an access network that provides network connectivity to the end-user devices (e.g., V-ITS-Ss 110 and/or VRU ITS-Ss 117). The access networks may be Radio Access Networks (RANs) such as an NG RAN or a 5G RAN for a RAN that operates in a 5G/NR cellular network, an E-UTRAN for a RAN that operates in an LTE or 4G cellular network, or a legacy RAN such as a UTRAN or GERAN for GSM or CDMA cellular networks. The access network or RAN may be referred to as an Access Service Network for WiMAX implementations. In some embodiments, all or parts of the RAN may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a cloud RAN (CRAN), Cognitive Radio (CR), a virtual baseband unit pool (vBBUP), and/or the like. In these embodiments, the CRAN, CR, or vBBUP may implement a RAN function split, wherein one or more communication protocol layers are operated by the CRAN/CR/vBBUP and other communication protocol entities are operated by individual RAN nodes 130. This virtualized framework allows the freed-up processor cores of the NAN 130 to perform other virtualized applications, such as virtualized applications for the VRU/V-ITS-S embodiments discussed herein.
Environment 100 also includes VRU 116, which includes a VRU ITS-S 117. The VRU 116 is a non-motorized road users as well as L class of vehicles (e.g., mopeds, motorcycles, segways, etc.), as defined in Annex I of EU regulation 168/2013 (see e.g., International Organization for Standardization (ISO) D., “Road vehicles—Vehicle dynamics and road-holding ability—Vocabulary”, ISO 8855 (2013) (hereinafter “[ISO8855]”)). A VRU 116 is an actor that interacts with a VRU system 117 in a given use case and behavior scenario. For example, if the VRU 116 is equipped with a personal device, then the VRU 116 can directly interact via the personal device with other ITS-Stations and/or other VRUs 116 having VRU devices 117. If the VRU 116 is not equipped with a device, then the VRU 116 interacts indirectly, as the VRU 116 is detected by another ITS-Station in the VRU system 117 via its sensing devices such as sensors and/or other components. However, such VRUs 116 cannot detect other VRUs 116 (e.g., a bicycle).
A VRU 116 can be equipped with a portable device (e.g., device 117). The term “VRU” may be used to refer to both a VRU 116 and its VRU device 117 unless the context dictates otherwise. The VRU device 117 may be initially configured and may evolve during its operation following context changes that need to be specified. This is particularly true for the setting-up of the VRU profile and VRU type which can be achieved automatically at power on or via an HMI. The change of the road user vulnerability state needs to be also provided either to activate the VRU basic service when the road user becomes vulnerable or to de-activate it when entering a protected area. The initial configuration can be set-up automatically when the device is powered up. This can be the case for the VRU equipment type which may be: VRU-Tx with the only communication capability to broadcast messages and complying with the channel congestion control rules; VRU-Rx with the only communication capability to receive messages; and/or VRU-St with full duplex communication capabilities. During operation, the VRU profile may also change due to some clustering or de-assembly. Consequently, the VRU device role will be able to evolve according to the VRU profile changes.
A “VRU system” (e.g., VRU ITS-S 117) comprises ITS artefacts that are relevant for VRU use cases and scenarios such as those discussed herein, including the primary components and their configuration, the actors and their equipment, relevant traffic situations, and operating environments. The terms “VRU device,” “VRU equipment,” and “VRU system” refers to a portable device (e.g., mobile stations such as smartphones, tablets, wearable devices, fitness tracker, etc.) or an IoT device (e.g., traffic control devices) used by a VRU 116 integrating ITS-S technology, and as such, the VRU ITS-S 117 may include or refer to a “VRU device,” “VRU equipment,” and/or “VRU system”.
The VRU systems considered in the present disclosure are Cooperative Intelligent Transport Systems (C-ITS) that comprise 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 Road side ITS-Station that is processing the VRU application logic based on the services provided by the lower communication layers (Facilities, Networking & Transport and Access layer (see e.g., ETSI EN 302 665 V1.1.1 (2010 September) (“[EN302665]”)), related hardware components, other in-station services and sensor sub-systems. A VRU system may be extended with other VRUs, other ITS-S and other road users involved in a scenario such as vehicles, motorcycles, bikes, and pedestrians. VRUs may be equipped with ITS-S or with different technologies (e.g., IoT) that enable them to send or receive an alert. The VRU system considered is thus a heterogeneous system. A definition of a VRU system is used to identify the system components that actively participate in a use case and behavior scenario. The active system components are equipped with ITS-Stations, while all other components are passive and form part of the environment of the VRU system.
The VRU ITS-S 117 may operate one or more VRU applications. A VRU application is an application that extends the awareness of and/or about VRUs and/or VRU clusters in or around other traffic participants. VRU applications can exist in any ITS-S, meaning that VRU applications can be found either in the VRU itself or in non-VRU ITS stations, for example cars, trucks, buses, road-side stations or central stations. These applications aim at providing VRU-relevant information to actors such as humans directly or to automated systems. VRU applications can increase the awareness of vulnerable road users, provide VRU-collision risk warnings to any other road user or trigger an automated action in a vehicle. VRU applications make use of data received from other ITS-Ss via the C-ITS network and may use additional information provided by the ITS-S own sensor systems and other integrated services.
In general, there are four types of VRU equipment 117 including non-equipped VRUs (e.g., a VRU 116 not having a device); VRU-Tx (e.g., a VRU 116 equipped with an ITS-S 117 having only a transmission (Tx) but no reception (Rx) capabilities that broadcasts awareness messages or beacons about the VRU 116); VRU-Rx (e.g., a VRU 116 equipped with an ITS-S 117 having only an Rx (but no Tx) capabilities that receives broadcasted awareness messages or beacons about the other VRUs 116 or other non-VRU ITS-Ss); and VRU-St (e.g., a VRU 116 equipped with an ITS-S 117 that includes the VRU-Tx and VRU-Rx functionality). The use cases and behavior scenarios consider a wide set of configurations of VRU systems 117 based on the equipment of the VRU 116 and the presence or absence of V-ITS-S 117 and/or R-ITS-S 130 with a VRU application. Examples of the various VRU system configurations are shown by table 2 of [TR103300-1].
The message specified for VRUs 116/117 is the VRU awareness message (VAM). VAMs are messages transmitted from VRU ITSs 117 to create and maintain awareness of VRUs 116 participating in the VRU/ITS system. VAMs are harmonized in the largest extent with the existing Cooperative Awareness Messages (CAM) defined in Error! Reference source not found. The transmission of the VAM is limited to the VRU profiles specified in clause 6.1 of [TS103300-2] The VAMs contain all required data depending on the VRU profile and the actual environmental conditions. The data elements in the VAM should be as described in Table 0-1.
The VRU system 117 supports the flexible and dynamic triggering of messages with generation intervals from X milliseconds (ms) at the most frequent, where X is a number (e.g., X=100 ms). The VAMs frequency is related to the VRU motion dynamics and chosen collision risk metric as discussed in clause 6.5.10.5 of [TS103300-3].
The number of VRUs 116 operating in a given area can get very high. In some cases, the VRU 116 can be combined with a VRU vehicle (e.g., rider on a bicycle or the like). In order to reduce the amount of communication and associated resource usage (e.g., spectrum requirements), VRUs 116 may be grouped together into one or more VRU clusters. A VRU cluster is a set of two or more VRUs 116 (e.g., pedestrians) such that the VRUs 116 move in a coherent manner, for example, with coherent velocity or direction and within a VRU bounding box. A “coherent cluster velocity” refers to the velocity range of VRUs 116 in a cluster such that the differences in speed and heading between any of the VRUs in a cluster are below a predefined threshold. A “VRU bounding box” is a rectangular area containing all the VRUs 116 in a VRU cluster such that all the VRUs in the bounding box make contact with the surface at approximately the same elevation.
VRU clusters can be homogeneous VRU clusters (e.g., a group of pedestrians) or heterogeneous VRU clusters (e.g., groups of pedestrians and bicycles with human operators). These clusters are considered as a single object/entity. The parameters of the VRU cluster are communicated using VRU Awareness Messages (VAMs), where only the cluster head continuously transmits VAMs. The VAMs contain an optional field that indicates whether the VRU 116 is leading a cluster, which is not present for an individual VRUs (e.g., other VRUs in the cluster should not transmit VAM or should transmit VAM with very long periodicity). The leading VRU also indicates in the VAM whether it is a homogeneous cluster or heterogeneous, the latter one being of any combination of VRUs. Indicating whether the VRU cluster is heterogeneous and/or homogeneous may provide useful information about trajectory and behaviors prediction when the cluster is disbanded.
The use of a bicycle or motorcycle will significantly change the behavior and parameters set of the VRU using this non-VRU object (or VRU vehicle such as a “bicycle”/“motorcycle”). A combination of a VRU 116 and a non-VRU object is called a “combined VRU.” VRUs 116 with VRU Profile 3 (e.g., motorcyclists) are usually not involved in the VRU clustering.
A VAM contains status and attribute information of the originating VRU ITS-S 117. The content may vary depending on the profile of the VRU ITS-S 117. A typical status information includes time, position, motion state, cluster status, and others. Typical attribute information includes data about the VRU profile, type, dimensions, and others. The generation, transmission and reception of VAMs are managed by the VRU basic service (VBS) (see e.g.,
The Radio Access Technologies (RATs) employed by the NAN 130, the V-ITS-Ss 110, and the VRU ITS-S 117 may include one or more V2X RATs, which allow the V-ITS-Ss 110 to communicate directly with one another, with infrastructure equipment (e.g., NAN 130), and with VRU devices 117. In the example of
In V2X scenarios, a V-ITS-Ss 110 or a NAN 130 may be or act as a RSU or R-ITS-S 130, which refers to any transportation infrastructure entity used for V2X communications. In this example, the RSU 130 may be a stationary RSU, such as an gNB/eNB-type RSU or other like infrastructure, or relatively stationary UE. In other embodiments, the RSU 130 may be a mobile RSU or a UE-type RSU, which may be implemented by a vehicle (e.g., V-ITS-Ss 110), pedestrian, or some other device with such capabilities. In these cases, mobility issues can be managed in order to ensure a proper radio coverage of the translation entities.
In an example implementation, RSU 130 is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing V-ITS-Ss 110. The RSU 130 may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic. The RSU 130 provides various services/capabilities 180 such as, for example, very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU 130 may provide other services/capabilities 180 such as, for example, cellular/WLAN communications services. In some implementations, the components of the RSU 130 may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller and/or a backhaul network. Further, RSU 130 may include wired or wireless interfaces to communicate with other RSUs 130 (not shown by
In arrangement 100, V-ITS-S 110a may be equipped with a first V2X RAT communication system (e.g., C-V2X) whereas V-ITS-S 110b may be equipped with a second V2X RAT communication system (e.g., W-V2X which may be DSRC, ITS-G5, or the like). In other embodiments, the V-ITS-S 110a and/or V-ITS-S 110b may each be employed with one or more V2X RAT communication systems. In these embodiments, the RSU 130 may provide V2X RAT translation services among one or more services/capabilities 180 so that individual V-ITS-Ss 110 may communicate with one another even when the V-ITS-Ss 110 implement different V2X RATs. According to various embodiments, the RSU 130 (or edge compute node 140) may provide VRU services among the one or more services/capabilities 180 wherein the RSU 130 shares CPMs, MCMs, VAMs DENMs, CAMs, etc., with V-ITS-Ss 110 and/or VRUs for VRU safety purposes including RSS purposes. The V-ITS-Ss 110 may also share such messages with each other, with RSU 130, and/or with VRUs. These messages may include the various data elements and/or data fields as discussed herein.
In this example, the NAN 130 may be a stationary RSU, such as an gNB/eNB-type RSU or other like infrastructure. In other embodiments, the NAN 130 may be a mobile RSU or a UE-type RSU, which may be implemented by a vehicle, pedestrian, or some other device with such capabilities. In these cases, mobility issues can be managed in order to ensure a proper radio coverage of the translation entities. The NAN 130 that enables the connections 112 may be referred to as a “RAN node” or the like. The RAN node 130 may comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). The RAN node 130 may be implemented as one or more of a dedicated physical device such as a macrocell base station, and/or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells. In this example, the RAN node 130 is embodied as a NodeB, evolved NodeB (eNB), or a next generation NodeB (gNB), one or more relay nodes, distributed units, or Road Side Unites (RSUs). Any other type of NANs can be used. Additionally, the RAN node 130 can fulfill various logical functions for the RAN including, but not limited to, RAN function(s) (e.g., radio network controller (RNC) functions and/or NG-RAN functions) for radio resource management, admission control, uplink and downlink dynamic resource allocation, radio bearer management, data packet scheduling, etc.
The network 158 may represent a network such as the Internet, a wireless local area network (WLAN), or a wireless wide area network (WWAN) including proprietary and/or enterprise networks for a company or organization, a cellular core network (e.g., an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, a 5G core (5GC), or some other type of core network), a cloud computing architecture/platform that provides one or more cloud computing services, and/or combinations thereof. As examples, the network 158 and/or access technologies may include cellular technology such as LTE, MuLTEfire, and/or NR/5G (e.g., as provided by Radio Access Network (RAN) node 130), WLAN (e.g., WiFi®) technologies (e.g., as provided by an access point (AP) 130), and/or the like. Different technologies exhibit benefits and limitations in different scenarios, and application performance in different scenarios becomes dependent on the choice of the access networks (e.g., WiFi, LTE, etc.) and the used network and transport protocols (e.g., Transfer Control Protocol (TCP), Virtual Private Network (VPN), Multi-Path TCP (MPTCP), Generic Routing Encapsulation (GRE), etc.).
The remote/cloud servers 160 may represent one or more application servers, a cloud computing architecture/platform that provides cloud computing services, and/or some other remote infrastructure. The remote/cloud servers 160 may 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., multi-media infotainment streaming), and/or the like.
Additionally, the NAN 130 is co-located with an edge compute node 140 (or a collection of edge compute nodes 140), which may provide any number of services/capabilities 180 to vehicles 110 such as ITS services/applications, driving assistance, and/or content provision services 180. The edge compute node 140 may include or be part of an edge network or “edge cloud.” The edge compute node 140 may also be referred to as an “edge host 140,” “edge server 140,” or “compute platforms 140.” The edge compute nodes 140 may partition resources (e.g., memory, CPU, GPU, interrupt controller, I/O controller, memory controller, bus controller, network connections or sessions, etc.) where respective partitionings may contain security and/or integrity protection capabilities. Edge nodes may also provide orchestration of multiple applications through isolated user-space instances such as containers, partitions, virtual environments (VEs), virtual machines (VMs), Servlets, servers, and/or other like computation abstractions. The edge compute node 140 may be implemented in a data center or cloud installation; a designated edge node server, an enterprise server, a roadside server, a telecom central office; or a local or peer at-the-edge device being served consuming edge services. The edge compute node 140 may provide any number of driving assistance and/or content provision services 180 to vehicles 110. The edge compute node 140 may be implemented in a data center or cloud installation; a designated edge node server, an enterprise server, a roadside server, a telecom central office; or a local or peer at-the-edge device being served consuming edge services. Examples of such other edge computing/networking technologies that may implement the edge compute node 140 and/or edge computing network/cloud include Multi-Access Edge Computing (MEC), Content Delivery Networks (CDNs) (also referred to as “Content Distribution Networks” or the like); Mobility Service Provider (MSP) edge computing and/or Mobility as a Service (MaaS) provider systems (e.g., used in AECC architectures); Nebula edge-cloud systems; Fog computing systems; Cloudlet edge-cloud systems; Mobile Cloud Computing (MCC) systems; Central Office Re-architected as a Datacenter (CORD), mobile CORD (M-CORD) and/or Converged Multi-Access and Core (COMAC) systems; and/or the like. 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 practice the embodiments herein.
Embodiments herein include VRU clustering to reduce messaging/signaling overhead, which may be used scenarios involving a relatively high VRU 116 density. Such scenarios of relatively high VRU 116 density may include, for example, crowded urban intersections and sidewalks, intersection and sidewalks near a big public event like sports-events/music-concerts, and the like. One of the challenges with very high VRU 116 density scenarios is the extremely high messaging overhead from VRUs 116 resulting in network congestion and message loss at the access layer. For example, all of the tens or hundreds of pedestrians crossing intersection may flood network with messages (e.g., pedestrian safety messages, VRU awareness messages (VAMs), etc.). ETSI ITS WG1 has also identified the similar issues (see e.g., Draft ETSI TS 103 300-2 V0.3.0 (2019 December) (“[TS103300-2]”), and ETSI TR 103 300-1 v2.1.1 (2019 September) (“[TR103300-1]”)). For example, the number of VRUs 116 operating in a given area can get very high (e.g., up to 500) or the VRU 116 can be combined with a VRU vehicle 116/117 (e.g., rider on a bicycle) [TR103300-1], [TS103300-2]. These scenarios/cases of high VRU-messaging overhead may result in severe network congestion and message loss at access layer.
In order to reduce the amount of communications and/or resource usage, one proposed solution involves grouping VRUs 116 together to send limited VAMs over the air-interface. [TS103300-2] suggests VRU clustering as a way of grouping VRUs 116 for group VAM transmission by a leader VRU 116 (also referred to as a “cluster head), and skipping individual VAMs by cluster members. However, [TS103300-2] lacks details of the mechanisms for efficient VRU cluster formation and cluster management. VRU 116 clustering for communication overhead reduction is beneficial only if cluster creation, cluster management (e.g., handling leaving/joining members, changing the cluster head, etc.), and coordination among cluster members is performed efficiently in terms of communication message overhead, latency of CH (re)selection, life time of CH, cluster-stay-time of cluster members, and frequency of cluster management efforts.
The present disclosure provides various embodiments to enable efficient VRU 116 clustering for reduction of communication overhead in Vehicular Networks (e.g., V2X networks, ITS networks, and the like) addressing the shortcomings of the existing solutions as well as the following issues/challenges: initiation of VRU Cluster formation is triggered at VRUs 116 in distributed manner; VRU Cluster Head selection including when multiple VRUs 116 show intentions to be cluster head for the same VRU cluster bounding box at the beginning of the cluster formation, and conflict resolution mechanisms when such scenarios arise; VRU cluster joining/exiting mechanisms to allow VRUs 116 to join/exit exiting VRU clusters including when CH exits an existing VRU cluster; and interaction mechanisms within VRU clusters to collect info/parameters for the cluster-wise VAMs to be transmitted by the cluster head.
The VRU clustering embodiments for reduction of communication overhead in Vehicular Networks may be used for very high VRU density scenarios/cases such as crowded urban intersections and sidewalks, intersection and sidewalks near and/or during public events like sports events, music concerts, etc. The VRU clustering embodiments herein serves as a way of grouping VRUs enabling a single group message (e.g., VAMs) transmission by a leader VRU 116 (also referred to as a “cluster head” or the like) and skipping individual VAMs by cluster members. The VRU clustering embodiments are highly effective to reduce network messaging overhead for very high VRU density scenarios/cases.
The wireless communications (e.g., from R-ITS-Ss 130 and/or V-ITS-Ss 110) with VRUs 116 enhances the safety of all road users. Radio resources are scarce and need to be used efficiently when there is a huge demand and it involves safety messages. In the scenarios with presence of high number of VRUs 116, large number of VAMs would be broadcasted to inform their presence on the streets, sidewalks and trails. This may lead to signaling/spectrum congestion and signaling/message collisions in the access medium. In such situations, a VRU cluster is formed with a cluster head (CH) to broadcast the VAM message on behalf of the cluster members to reduce the network congestion. The VRUs 116 in the cluster still listen to all the VAM messages in the communication channel and act on them. However, cluster members skip individual VAMs. The embodiments herein define various cluster aspects to reduce the VRU messaging overhead in high VRU density scenarios.
According to various embodiments, a VRU cluster is formed on or around an area with a geographical bounding box. A VRU cluster is a set of two or more VRUs 116 such that the VRUs 116 move in a coherent manner, for example, with a coherent speed/velocity, coherent movement/direction, and/or within a bounding box. These clusters can be homogeneous VRU clusters (e.g., a group of the same types of VRUs 116 such as pedestrians only) or heterogeneous VRU clusters (e.g., groups of different types of VRUs 116 such as pedestrians and bicycles).
Coherent “cluster” velocity is velocity range of VRUs 116 in a cluster such that the differences in speed and heading between any of the VRUs 116 are below a predefined threshold. In case of heterogeneous VRU clusters, differences in speed of same type of VRUs 116 may be below a lower predefined threshold value. However, differences in speed of different types of the VRUs 116 may be below a higher predefined threshold value.
The VRU bounding box is a continuous area where members of the VRU cluster are present and there is no vehicle road user in this area for the life span of the cluster. The bounding box of the VRU cluster may be stationary (e.g., in case of intersection crossing, Zebra crossing, etc.) or mobile (e.g., in case of a side walk). In case of a mobile VRU bounding box, the distance between any of the cluster members (e.g., member VRUs 116) in this area is smaller than a threshold. The bounding box/area could take different geometrical shapes: circle, rectangle, ellipse, polygon, etc. The CH is responsible for transmitting VAM messages on behalf of all cluster members within the bounding area. These clusters can be considered as a single object/entity and only the cluster head will continuously transmit the VAM.
The parameters of the VRU cluster are communicated to proximity VRUs 116, V-ITS-Ss 110, and R-ITS-Ss 130 using VAMs (where a single group VAM is used for the cluster) transmitted by the CH. The frequency of VAM transmission by the CH is determined by a group/cluster profile. For example, the CH may select VAM periodicity as the least individual VAM periodicity among the periodicities of cluster members. The CH may direct cluster members to update their profile info periodically or on demand (e.g., asynchronously). There could be other VRUs 116 in the bounding area that are not part of the cluster, CH is not responsible to transmit info about these non-member VRUs 116 within the bounding box/area in the cluster VAM. The terms “VRU bounding box,” “VRU bounding area,” “bounding box,” “bounding area,” and “bounding geo-area” may be used interchangeably throughout this document.
Table 1.1-1 shows example requirements for VRU clusters according to various embodiments.
Various embodiments include mechanisms for VRU Cluster formation and cluster management. In embodiments, a VRU device 117 is able to determine whether it should be acting as a clustered or isolated VRU 116. If a VRU is part of a cluster, only the VRU leading the cluster, e.g., cluster head VRU, transmits the VAM, indicating the cluster's total dimension and velocity. A cluster head VRU leads and manages a cluster, e.g., forming and disbanding a cluster, and cluster member VRUs join and leave a cluster.
Forming a VRU cluster takes place when a VRU 116/117 determines to form a cluster based on the received VAMs from other VRUs 116/117. The VRU 116/117 sends a VAM indicating that it will lead the cluster with the VRU cluster's identifier.
Disbanding a VRU cluster takes place when a VRU 116/117 determines to disband a cluster. This VRU 116/117 sends a VAM indicating that it will disband the cluster with the VRU cluster's identifier. The cluster leader (or cluster head) sends (e.g., transmits or broadcasts) disbanding indication a predefined number of times (e.g., once or more) in consecutive VAMs.
Joining a VRU cluster takes place when a VRU 116/117 receives VAMs from a cluster head (CH) VRU 116/117. The VRU 116/117 analyses the received VAMs and decides whether it should join the cluster or not. In order to join the cluster, the VRU 116/117 sends a VAM indicating that it is joining (or would like to join) the cluster with the VRU cluster's identifier, stops transmission afterwards, and monitors the VAMs from the CH VRU 116/117. This allows the CH VRU 116/117 to know whether the cluster is homogeneous or heterogeneous, and the profile, size, speed, and reference position of the cluster. If the new VRU cluster member finds that the CH VRU 116/117 has not heard its last VAM with cluster join indication (e.g., based on bounding box information transmitted in next VAM from the cluster leader), it should send VAM again with cluster join indication before stopping its VAM transmission.
Leaving a VRU cluster takes place when a VRU 116/117 in a cluster receives VAMs from the cluster head VRU 116/117. The VRU 116/117 analyses the received VAMs and decides whether it should leave the cluster or not. In order to leave a cluster, it sends a VAM (e.g., the first VAM after its silence) indicating that it is leaving the cluster and resumes the transmission of the VAM. In embodiments, a VRU 116/117 is always allowed to leave a cluster for any reason (or for no reason).
A VRU device 117 determines whether it can join or should leave a cluster by comparing its measured position and speed with the position and speed indicated in the VAM of the CH VRU 116/117. If the compared information fulfils certain conditions (e.g., less than 3-5 meters away and speed difference less than 5% of own speed), the VRU device 117 can join the cluster. After joining the cluster, when the compared information does not fulfil the conditions any longer, the VRU device 117 leaves the cluster. In some cases, moving VRU clusters on sidewalk with similar coherent cluster velocity profiles may come closer with fully or partially overlapped bounding boxes. In such a case, merging these VRU clusters can further reduce VRU messaging in the network.
Additionally or alternatively, one or more cluster member VRUs 116/117 may determine that the CH VRU 116/117 is lost. In some cases, the cluster leader may lose communication connection or fail as a node. In this case, the CH VRU 116/117 cannot send VAM(s) on behalf of the cluster. If there is no VAM for a predefined time (e.g., the VRU(s) 116/117 in the cluster do(es) not receive more than a predefined number of consecutive VAMs from the cluster leader), the VRU(s) 116/117 assume(s) the CH VRU 116/117 to be lost and the VRU(s) 116/117 resumes sending VAMs.
In various embodiments, Road Side Equipment (RSE)/RSUs may help to identify a need for VRU cluster formation, such as when several VRUs 116 are waiting to cross an intersection (e.g., several VRUs 116 have requested a traffic light-controller to cross the intersection). Alternately, sensors at the RSE may have detected several VRUs 116 (e.g., beyond a threshold number e.g., >10) at the intersection or on the side walk.
In these cases, the RSE may send/broadcast a warning/awareness message to VRUs 116 indicating a VRU clustering recommendation. VRUs 116 receiving the warning/awareness message from the RSE can then initiate VRU Cluster formation. In some embodiments, RSEs may indicate front most location in the warning message, so that only VRU(s) 116 near the frontmost location initiate VRU cluster formation (e.g., in case of intersection crossing or zebra-crossing).
In another embodiment, sensors at a V-ITS-S 110 may have detected several VRUs 116, for example, beyond a threshold number (e.g., >10) at the intersection or on the side walk. In this case, the V-ITS-S 110 may send/broadcast warning/awareness message to VRUs 116 indicating VRU clustering recommendation. VRUs 116 receiving a warning/awareness message from the V-ITS-S 110 can then initiate VRU Cluster formation. In some embodiments, the V-ITS-S 110 may indicate front most location in the warning message, so that only VRU(s) near the frontmost location initiate VRU cluster formation e.g., in case of intersection crossing or zebra-crossing.
Each VRU may decide such VRU cluster formation requirement from VAMs transmitted by VRUs 116 in the proximity. For example, if several VRUs 116 (beyond a threshold number e.g., >10) indicate nearby locations and same intended directions in their VAMs, VRU(s) may trigger a VRU cluster formation.
In another embodiment, only VRU(s) near the front most location (based on the shared location information) may initiate cluster formation e.g., in case of intersection crossing or zebra-crossing.
As discussed above with respect to triggering VRU cluster formation, under certain circumstances one or more VRUs 116 set a flag to initiate a new VRU cluster. These VRUs 116 (e.g., VRU(s) near the front location in the direction of potential cluster movement) initiate cluster formation by generating a VAM and indicating themselves as the CH in the VAM.
In embodiments, a VRU 116 may first check its profile whether it has sufficient capability to serve as CH. The VRU 116 may initiate VRU cluster formation only if it has sufficient capabilities to serve as CH. The minimum capabilities to serve as the CH (e.g., in terms of battery, CPU, memory, message processing rate, positioning accuracy, VAM Tx, Rx, St capabilities, interoperability with one or several common set(s) of standards, etc.) may be either predefined or preconfigured, or broadcast by an R-ITS-S 130 or network/cloud either periodically or whenever the VRU cluster potential is detected by R-ITS-S 130. In some embodiments, only the VRU-St device type (see e.g., clause 4.1 of [TS103300-2]) is allowed to be part or lead a cluster. The VRU device type (VRU-St or VRU-Tx) is indicated in the VAM. Examples of the minimum capabilities to serve as the CH is provided infra.
In some embodiments, the CH of a VRU cluster is selected as the VRU 116 with the most upfront reference position considering the VRU direction. A VRU cluster is considered as a single entity in the overall VRU communication. Only a single VAM is generated per cluster containing the relevant information/parameter of the cluster.
In some embodiments, the single VAM for the cluster includes information about the intended VRU cluster. Examples of the cluster information included in this VAM include an intended Geo-Area size of the cluster, direction, velocity profile (e.g., speed range to join cluster), security requirement to join the cluster (e.g., specific Trusted Execution Environment (TEE) requirement(s) to be installed at a cluster member), a number of participants in the cluster, Ncluster, dimension of cluster expressed as reference point including length and width of the bounding box. speed of cluster, position of cluster (e.g., position of the cluster head, the VRU cluster reference position), and/or other like parameters.
Since generation of VAM at VRU module and transmission of VAM at access layer has delay, it is possible that more than one VRU may generate VAM with their intention to initiate VRU cluster formation. For example, a first VRU (VRU-ch1) sending a VAM indicating itself as CH waits for up to a pre-defined period of time (e.g., 1 or 2 VAM period(s); or longest VAM period defined in one or more technical standards), and monitors for VAMs from other VRUs 116 with indication of CH. If none of the other VRUs 116 has initiated VRU cluster formation, VRU-ch1 retains itself as cluster head of the new VRU cluster. However, if there are Multiple VRUs 116 indicating to serve as CHs in their VAMs, the following procedure may be used to select one VRU to act as the CH:
If none of the front most VRUs 116 sends a VAM with indication to serve as CH for one or two VAM periods after ‘trigger of VRU Cluster formation’, other VRUs 116 which are farther from the front most location initiate VRU cluster formation as described above.
At operation 310, VRU Cluster Formation is initiated by Potential cluster head (CH) VRUs 116 (or VRU ITS-Ss 117). In embodiments, a VRU satisfying CH minimum capability requirement generates a VAM indicating itself as the CH and broadcasts or transmits this VAM to the VRUs 116 detected at operation 305. Due to inherent delay between generation and access layer transmission of VAMs, multiple qualifying VRUs 116 may indicate themselves as (candidate) CHs. Current VRU ITS-S specifications/standards assume no such conflicts exist, however, since generation of VAM at VRU module and transmission of VAM at access layer have different delay for different VRUs 116/117, it is quite possible that more than one VRU 116/117 may generate VAMs with their intention to initiate VRU cluster formation. In these cases, a distributed ‘Multiple CH Candidates Resolution’ mechanism is run by Candidate CH VRUs 116, resulting in selection of only one VRU 116 as the CH.
At operation 315, VRUs are enabled to join the existing (already created) VRU cluster. In embodiments, the CH VRU 116 periodically sends (broadcasts or transmits) VAMs with cluster related information and VRU cluster joining criteria. When a VRU 116 (or VRU ITS-S 117) receives this VAM from the CH; finds itself within or nearby of a bounding box of VRU cluster; satisfies Cluster joining criteria; and decides to join the VRU cluster, the VRU 116 (or VRU ITS-S 117) sends joining request along with its profile and gets confirmation from the CH VRU 116 to join the cluster. Then, the VRU indicates or includes a ‘Cluster joining’ DE/DF/indicator in its next VAM and then either stops individual VAM communication or configures individual VAM periodicity to be very large. Then, the CH VRU 116 updates the ‘Cluster Profile Info’ DE/DF to be included in next Cluster-VAM transmission.
Prior to, subsequent to, or simultaneously with operation 315, at operation 320 VRUs are enabled to exit/leave the existing VRU cluster. In some embodiments, a cluster member VRU 116 decides to leave the VRU cluster if it finds itself outside of the bounding box of VRU cluster. Additionally or alternatively, a cluster member VRU 116 decides to leave the VRU cluster when the separation with a nearest other cluster member is larger than a predefined or configured threshold. Some other trigger condition, criteria, and/or parameters may be used by a cluster member VRU 116 to determine if/when to leave an existing VRU cluster. When a cluster member VRU 116 decides to leave an existing VRU cluster, the exiting VRU 116 starts sending VAM(s) again with a regular periodicity, which may be predefined or configured. In some embodiments, the exiting VRU 116 may indicate or include a ‘leaving VRU Cluster’ DE/DF in its first VAM after leaving cluster or upon leaving the cluster. Then, the CH VRU 116 updates the Cluster Profile Info DE/DF to be included in the next VAM transmission.
At operation 325, the CH VRU 116 determines whether to disband the VRU cluster, which may be based on various triggers/conditions/criteria/parameters as discussed herein. If the CH VRU 116 determines not to disband the VRU cluster, the CH VRU 116 loops back to perform operations 315 and 320. If the CH VRU 116 determines to disband the VRU cluster, the CH VRU 116 proceeds to operation 330 to disband the VRU cluster as discussed herein.
After formation of VRU cluster, the CH VRU 116 periodically sends a VAM with VRU cluster related info such as the number of participants in the cluster (Ncluster), intended Geo-Area size of the cluster, direction, cluster velocity profile (e.g., within speed range or above minimum speed threshold to join cluster), security requirement to join the cluster (e.g., requiring VRU ITS-S 117 to have specific trusted execution environment (TEE) requirements/capabilities, have provisioned security credentials, etc.), VRUs-Exceeds-Cluster-Size-Limit-Flag, have specific RAT capabilities, etc.
A potential cluster member (e.g., VRU-m1) neighboring a formed cluster can detect the existing cluster by monitoring for VAMs from the CH. VRU-m1 may decide to join the existing (detected) VRU cluster if its location is within current Geo-Area/bounding-box of the cluster and/or very close to the Geo-Area/bounding-box of the cluster (e.g., x cm apart before entering cluster bounding box; moving beside a cluster with y cm lateral separation from bounding box of cluster, or the like). If VRU-m1 decides to join the VRU cluster and finds VRUs-Exceeds-Cluster-Size-Limit-Flag is set by the CH of the existing VRU cluster, VRU-m1 may initiate formation of another overlapping VRU cluster.
Otherwise, VRU-m1 may decide to join the existing VRU cluster if the existing cluster satisfies some other cluster requirements such as its Geo-location, speed, and direction are in accordance with desired or configured cluster requirements. In these embodiments, VRU-m1 sends a joining request with profile info to the CH VRU 116—via peer-to-peer (VRU-to-VRU) message exchange provision (see e.g., [TS103300-2]). The CH VRU 116 sends a confirmation message to the new cluster member (CM) VRU-m1 with a potential set of cluster rules or coordination configuration for further communication via peer-to-peer (VRU-to-VRU) message exchange provision (see e.g., [TS103300-2]).
VRU-m1 then joins cluster, and indicates VRU cluster joining in its next VAM. Then VRU-m1 stops sending the separate VAM, or VRU-m1 may select a VAM periodicity of very high (e.g., infinity) to stop VAM transmission. Once the CH VRU 116 adds new member(s), it updates Cluster Profile Info such as total size, speed info, Geo bounding box, etc. to be included in next VAM transmission.
A cluster member (e.g., VRU-m2) may decide to leave the existing VRU cluster if its location is outside of the current Geo-Area/bounding-box of the cluster—such as x cm apart cluster bounding box longitudinally in the direction of the cluster; or z cm apart laterally from bounding box of cluster. In some embodiment, cluster member (e.g., VRU-m2) may decide to leave the existing VRU cluster when the separation with nearest another cluster member is larger than a threshold (e.g., d cm).
Once VRU-m2 decides to leave the VRU cluster it may send a message to the CH VRU 116 informing its intension. In some cases, the CH VRU 116 may predict leaving time of the members, such as based on cluster bounding box and member's profile such as speed/direction. Once the CH VRU 116 detects exit of member(s), it updates Cluster Profile Info including total size, speed info, bounding box, etc.
The VRU-m2 starts sending a VAM when it decides to leave the VRU cluster. The VRU-m2 may indicate ‘leaving VRU Cluster’ in its first one or more VAMs. VRU-m2 may help the CH VRU 116 to note that one of its members has left the cluster in case the CH VRU 116 fails to receive earlier message indicating Cluster-Exit from VRU-m2.
In embodiments, an existing CH VRU 116 may decide to leave the role as CH, although VRU cluster can still be useful.
For example, at intersection crossings or cross-walks, when the CH VRU 116 reaches the other side of the road, it may decide to handover the CH role to another VRU 116 still in the intersection or cross-walk. In some embodiments, the current CH VRU 116 can handover the CH role to a VRU 116 that is CH-Capable and is at a predefined or configured location within the cluster bounding box. In one example, the CH role may be transferred to a CH-Capable VRU 116 that just entered the back of the cluster bounding box in order to maximize the lifetime of the new CH within the VRU cluster. The current CH VRU 116 may also consider VRU capabilities (e.g., processor load, processor power, available or utilized memory, message processing rate, RAT implementations, and/or other capabilities and/or configurations, such as those discussed herein) when selecting a new CH.
CH handover can be done by peer-to-peer (e.g., VRU-to-VRU) message exchange provision (see e.g., [TS103300-2]). In some embodiments, the current CH VRU 116 informs all cluster members about the new CH by peer-to-peer (e.g., VRU-to-VRU) broadcast message. In some embodiments, the current CH VRU 116 informs one or more proximate cluster members (e.g., within a predefined or configured distance from the current CH VRU 116) about the new CH by peer-to-peer (e.g., VRU-to-VRU) broadcast message, and the proximate cluster members relay the VAM indicating the new CH to other proximate cluster members, and so forth until all cluster members obtain the VAM. The current CH VRU 116 may also transfer all info about the cluster to the new CH during or after the CH handover procedure.
When the current CH VRU 116 starts sending VAMs, the current CH VRU 116 indicates ‘Leaving-CH-Role-Handed-over-to-New-CH’ DE/DF in its first one or more VAMs and then sends another VAM with no indication of serving as CH. The new CH VRU 116 starts sending VAM(s) with indication of serving as CH. In a first VAM, the new CH VRU 116 may send an additional flag indicating ‘Accepted-CH-Role-handed-over-by-Previous-CH’ or the like.
In another example, when the moving cluster is on a sidewalk and the new CH VRU 116 needs to cross the intersection, while most of its members have indicated to continue in the current direction of the cluster, the current CH VRU 116 selects a new CH-Capable VRU 116 that has indicated to move in the cluster-direction as a new CH. The current CH VRU 116 may consider VRU location as a factor while selecting new CH. For example, a VRU 116 near the center of the cluster bounding box may get a higher priority than VRUs 116 closer to the periphery of the cluster bounding box. Current CH may also consider VRU capabilities (e.g., CPU, memory, message processing rate, and/or other capabilities such as those discussed herein) when selecting a new CH.
CH handover can be done by peer-to-peer (VRU-to-VRU) message exchange provision (see e.g., [TS103300-2]). The current CH VRU 116 informs all cluster members about the new CH by peer-to-peer (VRU-to-VRU) broadcast message. The current CH VRU 116 starts sending VAMs and indicates ‘Leaving-CH-Role-Handed-over-to-New-CH’ in its first one or more VAMs. After it sends the first one or more VAMs with ‘Leaving-CH-Role-Handed-over-to-New-CH’ indication, it sends one or more VAMs with no indication of serving as CH. The new CH VRU 116 starts sending VAMs with indication of serving as CH. In the first VAM sent by the new CH VRU 116, the new CH VRU 116 may send an additional flag indicating ‘Accepted-CH-Role-handed-over-by-Previous-CH’ or the like.
In some cases, moving VRU clusters on sidewalk with similar coherent cluster velocity profiles may come closer with fully or partially overlapped Bounding boxes (e.g., due to these clusters had different wait times during red traffic lights). In such a case, merging these VRU clusters may further reduce VRU messaging in the network. According to various embodiments merging two or more VRU clusters when they come together may be triggered as follows:
(1) CH of each VRU cluster continuously monitors for VAMs from proximity VRU Clusters.
(2) If a first CH VRU 116 (CH-1) of VRU Cluster-1 and a second CH VRU 116 (CH-2) of VRU Cluster-2 detect one another in the proximity of their cluster bounding boxes, partially or fully overlapped, the following actions are taken. (2.A) CH-1 and CH-2 independently evaluate the percentage of overlapped Bonding Boxes with respect to smaller Bonding Box among these two Clusters. Note that we assume that CHs of VRU clusters share bonding box info, Coherent Cluster Velocity Info, etc. with each other in VAM. (2.B) If calculated percentage of overlapped Bonding Boxes <Min-Overlapping-for-Merging-Threshold (e.g., 30%), merging is not considered. Otherwise, merging of these VRU Clusters is considered and following steps are taken.
(3) If the difference between coherent cluster velocity of these two clusters is >Max-Diff-Coherent-Cluster-Velocity-for-Merging, merging is skipped. Otherwise, following steps are taken to proceed merging. (4) A CH for VRU cluster after merging is selected. In one embodiment, current CH of largest VRU Cluster (in size) among the clusters being merged elects itself as CH of merged cluster. In another embodiment, current CH of VRU Cluster with earlier Cluster-Formation-Time among the clusters being merged elects itself as CH of merged cluster.
(5) Elected CH of merged cluster informs other CHs of Clusters being merged; and other CHs confirms it by acknowledging. These message exchanges can be done by peer-to-peer (VRU-to-VRU) message exchange provision discussed in [TS103300-2].
(6) CHs of all clusters being merged then broadcast merge info to their members with info of new CH of the merged cluster.
(7) Elected CH of merged cluster then becomes confirmed CH of merged cluster. CH of merged cluster now starts sending VAM (with updated cluster profile info such as updated merged bounding box, cluster size, etc.). In the first one or more VAMs after merging, CH of merged cluster also indicates ‘Accepted-Merged-CH-Role-Due-To-Clusters-Merging’.
(8) All CHs (except CH which is elected as CH of merged cluster) indicate ‘Leaving-CH-Role-Handed-over-to-New-CH-Due-To-Clusters-Merging’ in its first one or more VAMs after clusters merging. Then after these CHs either send VAM with no indication of serving as CH or skip sending VAM (if they become member of the merged cluster).
In some cases, spitting of one of more VRU clusters also be needed. For example, if two clusters (e.g., Cluster-x1 and Cluster-x2) are waiting for green lights on the traffic light to continue ahead and some members from both clusters are about to cross intersection (leaving clusters in a direction perpendicular to cluster direction). These leaving members can make a new cluster (e.g., Cluster-x3) more efficiently rather than going for fresh process of new cluster. Specially existing clusters can help in triggering a third new cluster. For example, Cluster-x1 and Cluster-x2 detect each other and coordinate with each other via peer-to-peer (VRU-to-VRU) message exchange regarding their members leaving clusters due to intersection crossing. Let us say 4 members of Cluster-x1 and 2 members of Cluster-x2 are leaving their clusters. CHs of Cluster-x1 and Cluster-x2 may decide to form a new cluster for leaving members and select a new CH say CH-s1 for the new VRU Cluster. In one embodiment, CH of the cluster among splitting clusters from which highest number of members are leaving the cluster (CH of Cluster-x1 in this example) can select one of its leaving members as CH (CH-s1). CHs of Cluster-X1 and Cluster-x2 indicate ‘Cluster-Split-Leaving-Members-Joined-New-VRU-Cluster’ (along with splitting info and new Cluster info) in its first one or more VAMs after clusters splitting and formation of a new Cluster. New CH (CH-s1) starts sending VAM with new cluster info. CH-s1 indicates ‘Accepted-CH-Role-of-a-New-Cluster-Due-to-Splitting-of-Clusters’ in its first one or more VAMs. Members of new cluster do not need to send VAM indicating they are leaving previous Cluster or joining new cluster to reduce messaging overhead. Note that above described process of splitting of two or more clusters and formation of a new VRU cluster is applicable in case of splitting of a single VRU cluster as well. That is a single VRU cluster may split and leaving members can for a new VRU cluster with help of existing CH.
In certain scenarios, cluster head may need to disband the cluster with explicit indication in its VAM. For example, if the purpose of Cluster is fulfilled or remaining number of members is very low, etc., Cluster head may terminate the cluster. In this case, the CH sends ‘Cluster-Disbanding-Indication’ indication in VAM and then stops transmitting VAM as CH. CH may provide a reason of disbanding the VRU cluster as ‘Cluster-Disbanding-Reason’ in the VAM. Reason can be all members crossed intersection or zebra-crossing successfully; low number of cluster members, CH going out of bounding box, etc.
Cluster Head Lost Case: In some cases, CH may lose communication connection or fails as a node. In this case CH cannot send VAM on behalf of the cluster. If there is no VAM for a pre-defined time (e.g., more than Max-VAM-Loss-from-CH consecutive VAM losses), VRU cluster can be considered as Disbanded or terminated. In various embodiments, if a VRU 116/117 is part of a cluster, it continuously monitors for (e.g., attempts to obtain and/or decode) VAM(s) from the cluster leader VRU 116/117. If there is no VAM for a pre-defined time (e.g., the VRU 116/117 does not hear more than a pre-defined number of consecutive VAMs from the cluster leader), the VRU 116/117 assumes the cluster leader to be lost and the VRU resumes sending VAMs.
In some embodiments, the following actions can be taken in case of a lost CH. In one embodiment, all members may start sending VAM—similar to disbanding VRU Cluster case. Alternately, a member X may send a VAM indicating CH of the same cluster (a VRU cluster can be identified by its cluster ID). In this case only CH is changed while same Cluster is revived—without requiring all member to send VAMs indicating exiting and joining cluster indications. New CH selection may follow similar approach as discussed previously in the section “I
Since the CH plays a vital role in operation of VRU cluster, a VRU may be required to have some minimum capabilities in order to serve as cluster head (CH) of a VRU cluster. Serving as a Cluster head may need some minimum capabilities in terms of say battery, CPU, Memory, message processing rate, positioning accuracy, VAM Tx-Rx capability, interoperability with one or several common set(s) of standards, etc. The CH may be selected from VRUs 116/117 with one or more of the following capabilities:
A VRU cluster information container is added to a VAM 5b00 originated from the VRU cluster leader. This container provides the information/parameters relevant to the VRU cluster. The VRU cluster information container is of type VruClusterInformationContainer. A VRU cluster information container comprises information about the cluster identifier (ID), shape of the cluster bounding box, cardinality size of the cluster, and profiles of VRUs 116/117 in the cluster. The cluster ID is of type ClusterID. ClusterID is selected by the cluster leader to be non-zero and locally unique as specified in clause 5.4.2.2 of [TS103300-3] and/or as shown by Table 1.3-1. The shape of the VRU cluster bounding box is specified by DF ClusterBoundingBoxShape. The shape of the cluster bounding box can be rectangular, circular or polygon. An example of the DF ClusterBoundingBoxShape is shown by Table 1.3-2.
The AreaRectangle, AreaCircular, and AreaPolygon, are shown by Table 1.3-3, Table 1.3-4, and Table 1.3-5, respectively, and additional aspects of these DEs/DFs are shown by Table 1.3-6, Table 1.3-7, Table 1.3-8, Table 1.3-9, Table 1.3-10, Table 1.3-11, Table 1.3-12, Table 1.3-13, Table 1.3-14, and Table 1.3-15.
A VRU cluster operation container contains information relevant to change of cluster state and composition (comp.). This container may be included by a cluster VAM transmitter or by a cluster member (e.g., cluster leader/CH or ordinary member). A cluster leader/CH includes VRU cluster operation container for performing cluster operations of disbanding (breaking up) cluster. A cluster member includes VRU cluster operation container in its individual VAM 5b00 to perform cluster operations of joining a VRU cluster and leaving a VRU cluster. VRU cluster operation containers are of type VruClusterOperationContainer.
VruClusterOperationContainer provides: DF clusterJoinInfo for cluster operation of joining a VRU cluster by a new member; DF clusterLeaveInfo for an existing cluster member to leave a VRU cluster; DF clusterBreakupInfo to perform cluster operations of disbanding (breaking up) cluster respectively by the cluster leader; and DE clusterIdChangeTimeInfo to indicate that the cluster leader is planning to change the cluster ID at the time indicated in the DE. The new Id is not provided with the indication for privacy reasons (see E.G., clause 5.4.2.3 and clause 6.5.4 of [TS 103300-3]).
A VRU device 117 joining or leaving a cluster announced in a message other than a VAM indicates this using the ClusterId value 0. A VRU device 117 leaving a cluster indicates the reason why it leaves the cluster using the DE ClusterLeaveReason. The available reasons are depicted in Table 1.3-16. A VRU leader device breaking up a cluster indicates the reason why it breaks up the cluster using the ClusterBreakupReason. The available reasons are depicted in Table 1.3-17. In the case the reason for leaving the cluster or breaking up the cluster is not exactly matched to one of the available reasons, the device systematically sends the value “notProvided(0)”.
In particular, a VRU in a cluster, may determine that one or more new vehicles or other VRUs (e.g., VRU Profile 3—Motorcyclist) have come closer than minimum safe lateral distance (MSLaD) laterally, and closer than minimum safe longitudinal distance (MSLoD) longitudinally and closer than minimum safe vertical distance (MSVD) vertically (the minimum safe distance condition is satisfied as in clause 6.5.10.5 of [TS103300-3]); it leaves the cluster and enter VRU-ACTIVE-STANDALONE VBS state in order to transmit immediate VAM with ClusterLeaveReason“SafetyCondition(8)”. The same applies if any other safety issue is detected by the VRU device 117. Device suppliers and/or manufacturers may declare the conditions on which the VRU device 117 will join/leave a cluster.
The VruClusterOperationContainer does not include the creation of VRU cluster by the cluster leader. When the cluster leader starts to send a cluster VAM 5b00, it indicates that it has created a VRU cluster. While the cluster leader is sending a cluster VAM 5b00, any individual VRUs 116/117 can join the cluster if the joining conditions are met.
The VRU cluster operation container of VAM 5b00 is vruClusterOperationContainer. The VRU cluster operation container includes the following parameters: clusterJoinInfo; clusterLeaveInfo; clusterBreakupInfo; and clusterIdChangeTimeInfo. The clusterJoinInfo DF indicates the intent of an individual VAM transmitter to join a cluster. The clusterJoinInfo DF includes clusterId and joinTime. The clusterId is the cluster identifier for the cluster to be joined (e.g., identical to the clusterId field in the vruInformationClusterContainer in the VAM 5b00 describing the cluster that the sender of the clusterJoinInfo intends to join). The joinTime is the time after which the sender will no longer send individual VAMs 5b00 and/or a time after which the VAM transmitter will stop transmitting individual VAMs 5b00. It is presented and interpreted as specified in clause F.6.6 of [TS103300-3], VruClusterOpTimestamp, and/or as shown by Table 1.3-18.
The clusterLeaveInfo DF indicates that an individual VAM transmitter has recently left the VRU cluster. This DF is presented as specified in clause F.6.2 of [TS103300-3], at clusterLeaveInfo, clusterId, and clusterLeaveReason; and/or as shown by Table 1.3-19. The clusterId is identical to the clusterId field in the VruClusterInformationContainer in the VAM 5b00 describing the cluster that the sender of the clusterLeaveInfo has recently left. The clusterLeaveReason indicates the reason why the sender of ClusterLeaveInfo has recently left the cluster. It is presented and interpreted as specified in clause F.6.4 of [TS103300-3], ClusterLeaveReason and/or as shown by Table 1.3-19. This DF is used in VRU cluster operation container DF as defined in clause B.6.1 of [TS103300-3]. In this DF, clusterId is the cluster identifier for the cluster that the VAM sender has just left, and ClusterLeaveReason is the reason why it left.
The clusterBreakupInfo DF indicates the intent of a cluster VAM transmitter to stop sending cluster VAMs. This DF is presented as specified in clause B.6.1 and/or clause F.6.3 of [TS103300-3], clusterBreakupInfo, clusterBreakupReason; breakupTime; and/or as shown by Table 1.3-20. The clusterBreakupReason indicates the reason why the sender of ClusterBreakupInfo intends to break up the cluster. It is presented and interpreted as specified in clause F.6.5 of [TS103300-3], ClusterBreakupReason. The breakupTime indicates a time after which the VAM transmitter will stop transmitting cluster VAMs. It is presented and interpreted as specified in clause F.6.6 of [TS103300-3], VruClusterOpTimestamp.
The clusterIdChangeTimeInfo DF indicates the intent of a cluster VAM transmitter to change cluster ID. This DE is presented as in clause B.6.1 and/or clause F.6.6 of [TS103300-3], VruClusterOpTimestamp. VruClusterOpTimestamp is a unit of time. In one implementation, the unit of time is 256 milliseconds, and the VruClusterOpTimestamp is represented as an INTEGER (1 . . . 255). It can be interpreted as the first 8 bytes of a GenerationDeltaTime. To convert a VruClusterOpTimestamp to a GenerationDeltaTime, multiply by 256 (e.g., append a “00” byte).
The clusterLeaveReason DF indicates the reason for leaving the VRU cluster by an individual VAM transmitter. This DE indicates a reason why the VAM transmitter has left the cluster recently and/or and started to send individual VAMs. It is presented and interpreted as specified in clause B.6.1 and/or clause F.6.4 of [TS103300-3], ClusterLeaveReason and/or as shown by Table 1.3-21. In one implementation, the value 15 is set to “max” in order to bound the size of the encoded field.
The clusterBreakupReason DF indicates the reason for disbanding VRU cluster by a cluster VAM transmitter. This DE indicates a reason why a cluster leader VRU broke up the cluster that it was leading and/or the reason why the VAM transmitter will stop transmitting cluster VAMs. It is presented and interpreted as specified in clause B.6.1 and/or clause F.6.5 of [TS103300-3], ClusterBreakupReason and/or as shown by Table 1.3-22. In one implementation, the value 15 is set to “max” in order to bound the size of the encoded field.
The parameters in Table 1.3-23 govern the VRU decision to create, join or leave a cluster. The parameters may be set on individual devices or system wide and may depend on external conditions or be independent of them.
The parameters in Table 1.3-24 govern the messaging behavior around joining and leaving clusters. The parameters may be set on individual devices or system wide and may depend on external conditions or be independent of them.
In embodiments, VRU cluster related content/Info to be incorporated in the VAM transmitted by a CH is discussed infra. In some embodiments, interaction of cluster members with the CH may be performed to update individual VRU/cluster-member's profile/Info to the CH periodically or when needed.
Along with the existing VAM contents, one or more of the following cluster related data items (e.g., data in data elements or data fields) may be included in the VAM. In embodiments, the CH maintains this info up to date to be included in Group/Cluster VAM transmission.
In the context of the present disclosure, a “Geo-Area” is specified by geometric shapes such as circular areas, rectangular areas, and elliptical areas. A circular Geo-Area is described by a circular shape with a single point A that represents the center of the circle and a radius r. The rectangular Geo-Area is defined by a rectangular shape with a point A that represents the center of the rectangle and a parameter a which is the distance between the center point and the short side of the rectangle (perpendicular bisector of the short side, a parameter b which is the distance between the center point and the long side of the rectangle (perpendicular bisector of the long side, and a parameter θ which is the azimuth angle of the long side of the rectangle. The elliptical Geo-Area is defined by an elliptical shape with a point A that represents the center of the rectangle and a parameter a which is the length of the long semi-axis, a parameter b which is the length of the short semi-axis, and a parameter θ which is the azimuth angle of the long semi-axis. An ITS-S can use a function F to determine whether a point P(x,y) is located inside, outside, at the center, or at the border of a geographical area. The function F(x,y) assumes the canonical form of the geometric shapes: The Cartesian coordinate system has its origin in the center of the shape. Its abscissa is parallel to the long side of the shapes. Point P is defined relative to this coordinate system. The various properties and other aspects of function F(x,y) are discussed in ETSI EN 302 931 v1.1.1 (2011 July).
A VRU cluster is considered as a single entity in the overall VRU communication system. If a cluster exists, cluster members do not transmit VAMs, and only the cluster leader (cluster head) transmits cluster VAMs that describe the entire cluster. The parameters included in a cluster VAM are shown by Table 1.3.2-1.
In embodiments, each new cluster member (e.g., VRU-m3) sends its profile/Info to the CH as unicast after joining cluster—by peer-to-peer (e.g., VRU-to-VRU) message exchange. VRU-m3 may send this info in the Cluster join request message during cluster joining process as well. In some cases, CH may have stored VAM from new member VRU-m3. In this case VRU-m3 may not need to send its profile/Info to the CH again. Then, VRU-m3 sends only changed info if needed to the CH as unicast peer-to-peer (VRU-to-VRU) message. For example, if VRU-m3 detects ‘a bike rider ejected in the proximity due to accident’, VRU-m3 may send this update to the CH.
During Cluster Joining (e.g., in Cluster Join Confirm message from CH to VRU-m3), the CH may indicate each member VRU-m3 to send updated full or partial info about its profile periodically. It helps CH to keep track of updated bounding box of cluster in case of dynamic bounding box cases (e.g., VRU cluster moving on a sidewalk).
In some cases, CH may ask to update full or partial info about its profile periodically to only selected members such as members located along the edges of the bounding box. It helps CH to keep track of updated bounding box of cluster in case of dynamic bounding box cases (e.g., VRU cluster moving on a sidewalk) with reduced signaling overhead.
Embodiments herein include VRU profile awareness mechanisms for ITS-Ss. As alluded to previously, VRUs 116 are users of the road including pedestrians, safety emergency responders, safety/road workers, animals, wheelchair users, skaters, bikes, powered two wheelers, mopeds, and others [TR103300-1]. One feature of ITS is to ensure safety of such VRUs 116 from other non-VRUs of the road such as V-ITS-Ss 110 and/or other VRUs 116 by robustly identifying a VRU 116 from a non-VRU. However, a VRU 116 may transition into a non-VRU, for instance, when a walking pedestrian may get into a passenger vehicle (car, bus, or train) and after some time, it may transition back into a VRU 116 when it gets out of the vehicle and resumes walking on the road. In such situations, the safety of a VRU 116 may be increased if a continuous awareness of the VRU 116 through such transitions can be maintained among other road users. Such awareness can help potential collision avoidance between a vehicle and the VRU 116 by undertaking collision avoidance maneuvers at the V-ITS-S 110 and/or VRU 116. Pre-emptively, the awareness can be used to notify the V-ITS-S 110 and/or VRU 116, if it is in danger and/or even other road users to warn about the potential collision so that it can be avoided.
A feature of VRU collision avoidance in ITS is the capability to predict movements (e.g., trajectories and momentum) of the VRUs 116 in time to avoid the collision via change in trajectory, deceleration or emergency braking. This is applicable to all types of moving objects (VRUs 116 and vehicles). Moreover, the prediction must come with a level of confidence associated with it. Such level of confidence is a function of movement-related parameters such as velocity, heading direction, intention, planned trajectory as well as behavioral features of VRUs 116. Thus, VRUs 116 should be profiled according to prediction of such movement-related parameters and possible behaviors. Hence, there is need for defining functional features for VRU system 117 with well-defined system-level, communications-level and operational-level mechanisms to enable VRU Profile Awareness in ITS for enhancing collision risk analysis and collision avoidance actions.
In [TS103300-2], the different types of VRUs 116 have been categorized into the following four profiles:
These profiles further define the VRU functional system and communications architectures for VRU ITS-S 117. For robustly supporting the VRU profile awareness enablement, embodiments herein provide VRU related functional system requirements, protocol and message exchange mechanisms including, but not limited to, VAMs [TS103300-2]. Additionally, the embodiments herein also apply to each VRU device type listed in Table 2-1 (see e.g., [TS103300-2]).
The embodiments herein may impact the abstracted flow/steps for VRU protection which are [TS103300-2]: (1) detection of VRU presence; (2) evaluation of whether the VRU 116 is at potential risk; (3) transmission of information about at-risk VRU 116; and (4) risk assessment at the Rx side.
The embodiments herein enables the risk assessment at the Rx side by helping to build a local dynamic map (LDM) including VRU location, velocity, intention, and other time-series data as elaborated herein. Additionally, the embodiments also impact the Event Detection function 818 (see e.g.,
To address the issues in VRU profile (transition) awareness, embodiments include protocol(s) to enable VRU profile awareness, VAM data field construction, and VAM exchange between VRU ITS-S 117, V-ITS-S 110, and/or R-ITS-S 130 to support the transition awareness at other road users, specifically, the V-ITS-Ss 110 in the vicinity of the VRU including the deployed RSUs. The embodiments also provide detailed techniques for VRU profile awareness via Sub-Profiling based on speed, environment and weight class; and dynamic motion prediction-based transition awareness of such profile with time. The proposed mechanisms enable VRU profile awareness within the functional system and communication requirements. These mechanisms directly aid in collision risk analysis (see e.g., CRA function 816 of
VRU profile transition awareness is used for VRU collision avoidance system of ITS is the capability to predict movements (trajectories and momentum) of the VRUs 116 in time to avoid the collision (via change in trajectory, deceleration or emergency braking). This is applicable to all types of moving objects (VRUs 116 and vehicles). Moreover, the prediction must come with a level of confidence associated to it. Such level of confidence is a function of any VRU's movement related parameters (such as activity or idleness of the VRU, speed, heading direction, environment, weight, and others). Thus, VRUs 116 need to be profiled according to such movement related parameters. The embodiments herein define functional features for VRU system 117 with well-defined system-level, communications-level and operational-level mechanisms to enable VRU Profile Awareness in ITS for enhancing Collision Risk Analysis and Collision Avoidance Actions. In this document, we address the problem of enabling such VRU profile awareness.
Embodiments include a protocol to enable VRU profile transition awareness, VAM data fields construction and VAM exchange between VRU ITS-Ss 117, V-ITS-Ss 110 and/or R-ITS-Ss 130, which are in vicinity of the VRU 116. The techniques for initial categorization of the VRU Profile, along with Sub-Profile, and maintaining awareness of the possible dynamic transition of such profile with time infra.
Procedure 400 begins at step 0a where the ego VRU ITS-S 117 is in the IDLE state and at step Ob the ego VRU ITS-S 117 performs VRU movement sensing using VRU system sensors (e.g., on-board sensors) to detect, for example, motion, position, heading, speed, etc. If the ego VRU ITS-S 117 does not detect VRU motion before expiration of a Movement Sensing Timer (MST) during step Ob, the ego VRU ITS-S 117 proceeds back to step 0a. If the ego VRU ITS-S 117 does detect VRU motion before expiration of the MST during step Ob, the ego VRU ITS-S 117 proceeds to step 1 to initialize fields such as, for example, ACTIVE/IDLE, Unique ID, Location, Speed, Heading, Initial Profile ID, Sub-Profile ID (Speed, Environment, Weight). Examples of the fields are shown by
At step 2, the ego VRU ITS-S 117 performs Motion State Estimation using, for example, its on-board sensors. The ego VRU ITS-S 117 may detect, for example, Starting (Acceleration), Moving (Changing Position Coordinates), Stopping (Deceleration), and/or the like. At step 3a, the V-ITS-S 110 initializes a VRU Profile based on the received VAM. At step 3b, the R-ITS-S 130 initializes a VRU Profile based on the received VAM. At step 4, the ego VRU ITS-S 117 updates the fields (e.g., ACTIVE/IDLE, Unique ID, Location, Speed, Heading, Profile ID, Sub-Profile ID (Speed, Environment, Weight), etc.; see e.g.,
At steps 5a and 5b, the V-ITS-S 110 and the R-ITS-S 130 perform VRU Profile parameter update processes, respectively, to update their respective VRU profiles based on the received VAM. At step 5c, the V-ITS-S 110 and the R-ITS-S 130 may perform a message exchange for coordination of the respective VRU profile update processes. In some embodiments, step 5c is omitted. If the respective VRU profile update processes indicate that the ego VRU ITS-S 117 is idle, then the V-ITS-S 110 and the R-ITS-S 130 proceed back to step 0a. If the ego VRU ITS-S 117 is not idle, then the V-ITS-S 110 and the R-ITS-S 130 proceed to steps 6a and 6b, respectively.
At steps 6a and 6b, the V-ITS-S 110 and the R-ITS-S 130 perform respective Collision Risk Analyses (CRAs). At step 6c, the V-ITS-S 110 and the R-ITS-S 130 may perform a message exchange for coordination of the respective CRAs. In some embodiments, step 6c is omitted. If the respective CRAs indicate that the ego VRU ITS-S 117 is at little to no risk of a collision, then the V-ITS-S 110 and the R-ITS-S 130 proceed back to step 0a. If the ego VRU ITS-S 117 is at a high risk of a collision (e.g., at or more than a threshold level of risk), then the V-ITS-S 110 and the R-ITS-S 130 proceed to steps 7 and 8b, respectively.
At step 7, the V-ITS-S 110 performs a Collision Avoidance Action. At steps 8a and 8b, the V-ITS-S 110 and the R-ITS-S 130 perform respective Collision Avoidance Notification Formatting processes. At step 8c, the V-ITS-S 110 and the R-ITS-S 130 may perform a message exchange for coordination of the respective Collision Avoidance Notification Formatting processes. In some embodiments, step 8c is omitted. At steps 9a and 9b, the V-ITS-S 110 and the R-ITS-S 130 send respective VAMs including the Collision Avoidance Notification to the ego VRU ITS-S 117. At step 10, the ego VRU ITS-S 117 performs Collision Avoidance Action (e.g., Maneuver/Stopping) based on the VAM(s) received at steps 9a and 9b.
ACTIVE/IDLE Indicator [1-bit]: Indicates whether the ITS-S is a VRU (ACTIVE=1 implies VRU-ITS-S is non-IDLE) or non-VRU (ACTIVE=0, implies VRU-ITS-S is IDLE). This field is essential to indicate the definite transition of a VRU to non-VRU and vice-versa.
VRU ID: Unique Identifier of the VRU within the coverage region of an ITS-S.
Position: Unique position coordinates associated with the VRU's physical location in 2D (X, Y) or 3D (X, Y, Z) plane.
Speed: Speed of the VRU in kilometers per hour (km/h) or miles per hour (m/h). We propose the speed to have four variations: LOW, MEDIUM and HIGH as defined by the ranges indicated in Table 2.2-2.
Heading: The direction or angle of heading of the VRU measured relative to one of the global reference coordinate planes (for instance, the Y-plane)
Initial Profile ID or (Updated) Profile ID [2-bits]: When a VRU ITS-S device is ready to be used for the first time for a VRU, it is first configured to a default Profile Category. For example, a person getting a VRU ITS-S device would have its VRU ITS-S 117 by default configured to a Profile 1; while a bicycle and motorcycle may themselves be equipped with a VRU ITS-S device as well and designated to be Profile 2 and Profile 3, respectively. In case the bicycle or motorcycle is not equipped with any ITS-S device, the person riding those would have their initial ITS-S device configured as Profile 1 subject to update later. Similarly, any domestic pet equipped with ITS-S device would have the initial Profile configured by default to Profile 4, again, subject update based on transition later. The designation of a VRU profile category mapping to bits is illustrated in Table 2.2-1.
Sub-Profile ID [6-bits]: According to various embodiments, sub-profiles are defined within a profile category to support robustness and accuracy of the profile transition due to increased granularity (resolution) of the profile parameter value ranges. The 6-bit ID for indicating Sub-Profiles within a VRU Profile Category are further broken down across speed range, environment and weight class as follows:
Speed Range [2-bits]: Depending on possible speed values, we propose classifying the VRU speed into one of the various speed ranges within a profile defined as: (i) LOW; (II) MEDIUM; and (iii) HIGH. In embodiments, speed is used for defining the sub-profile since speed is a key characteristic distinguishing parameter among all. The mapping details for various VRU Profile Categories are illustrated in Table 2.2-2 along with example range of values.
Environment [2-bits]: The environment for the VRUs 116 are typically defined only to one among Urban/Suburban, Rural and Highway [TS103300-2]. However, such environment definition may be too broad and may not provide a localized environment information for the VRU. Accordingly, sub-categories of the environment may be defined as follows: Sidewalk (on or near), Zebra Crossing (on or near), and Road Pavement (on or near). Table 2.2-2 shows the bit mappings for various VRU Profile categories along with example range of values.
Weight Class [2-bits]: Depending upon the weight of the VRU, 2-bits are used to indicate 3 levels ranging from LOW, MEDIUM to HIGH weights as shown in Table 2.2-2.
The ITS PDU Header is a header DF of the VAM 5b00. The ITS PDU Header includes DEs for the VAM protocol Version, the VAM message type identifier messageID and the station identifier stationID of the originating ITS-S. The DE protocol Version is used to select the appropriate protocol decoder at the receiving ITS-S. This DE messageID should be harmonized with other C-ITS message identifier definitions. In some implementations, the value of the DE protocol Version is set to 1. For VAM, the DE messageID is set to vam(14). The StationID is locally unique. This DF is presented as specified in clause E.3 of [TS103300-3].
The ITS PDU header is as specified in [TS102894-2]. Detailed data presentation rules of the ITS PDU header in the context of VAM is as specified in annex B of [TS103300-3]. The StationId field in the ITS PDU Header changes when the signing pseudonym certificate changes, or when the VRU starts to transmit individual VAMs after being a member of a cluster (e.g., either when, as leader, it breaks up the cluster, or when, as any cluster member, it leaves the cluster).
Exception if the VRU device experiences a “failed join” of a cluster as defined in clause 5.4.2.2 of [TS103300-3], it should continue to use the StationId and other identifiers that it used before the failed join. The generation time in the VAM is a GenerationDeltaTime as used in CAM. This is a measure of the number of milliseconds elapsed since the ITS epoch, modulo 216 (e.g., 65 536).
The VAM payload vam includes of indicates the time stamp of the VAM and the containers basicContainer and vruHighFrequency Container. The VAM payload may include the additional containers vruLowFrequencyContainer, vruClusterInformationContainer, vruClusterOperationContainer, and vruMotionPredictionContainer. The selection of the additional containers depends on the dissemination criteria, e.g., vruCluster or MotionDynamicPrediction availability. This DF is presented as specified in annex A of [TS103300-3].
The generationDeltaTime DF is or includes a time corresponding to the time of the reference position in the VAM, considered as time of the VAM generation. The value of the DE is wrapped to 65 536. This value is set as the remainder of to the corresponding value of TimestampIts divided by 65 536 as below. generationDeltaTime=TimestampIts mod 65 536. TimestampIts represents an integer value in milliseconds since 2004-01-01T00:00:00:000Z as defined in X. The DE is presented as specified in annex A of [TS103300-3].
The vamParameters DF includes of indicates the sequence of VAM mandatory and optional containers. Other containers may be added in the future. This DF is presented as specified in annex A of [TS103300-3].
The basicContainer is the (mandatory) basic container of a VAM. The basic container provides (includes of indicates) basic information of the originating ITS-S. Type of the originating ITS-S; this DE somehow overlaps with the VRU profile, even though they do not fully match (e.g., moped(3) and motorcycle(4) both correspond to a VRU profile 3). To enable a future possibility to have the VAM transmitted by non VRU ITS-S(see clause 4.1 and annex I), both data elements are kept independent. The latest geographic position of the originating ITS-S as obtained by the VBS at the VAM generation. This DF is defined in [TS102894-2] and includes a positionConfidenceEllipse which provides the accuracy of the measured position with the 95% confidence level. The basic container is present for VAM generated by all ITS-Ss implementing the VBS. Although the basic container has the same structure as the BasicContainer in other ETSI ITS messages, the type DE contains VRU-specific type values that are not used by the BasicContainer for vehicular messages. It is intended that at some point in the future the type field in the ITS Common Data Dictionary (CDD) in [TS102894-2] will be extended to include the VRU types. At this point the VRU BasicContainer and the vehicular BasicContainer will be identical.
The stationType DF includes of indicates the station type of the VAM originating device. This DE takes the value pedestrian(1), bicyclist(2), moped(3), motorcycle(4), lightVRUvehicle(12), or animal(13). Other values of stationType is not used in the basicContainer transmitted in the VAM. This DF is presented as specified in clause E.2 of [TS103300-3].
The referencePosition DF includes of indicates the position and position accuracy measured at the reference point of the originating ITS-S. The measurement time corresponds to generationDeltaTime. If the station type of the originating ITS-S is set to one out of the values listed in clause B.2.2 of [TS103300-3], the reference point is the ground position of the centre of the front side of the bounding box of the VRU (see e.g., ETSI EN 302 890-2 (“[EN302890-2]”)). The positionConfidenceEllipse provides the accuracy of the measured position with the 95% confidence level. Otherwise, the positionConfidenceEllipse is set to unavailable. If semiMajorOrientation is set to 0° North, then the semiMajorConfidence corresponds to the position accuracy in the North/South direction, while the semiMinorConfidence corresponds to the position accuracy in the East/West direction. This definition implies that the semiMajorConfidence might be smaller than the semiMinorConfidence. This DF is presented as specified in [TS102894-2] A.124 ReferencePosition.
VAM-specific containers include VRU high frequency (VRU HF) container and VRU low frequency (VRU LF) container. All VAMs generated by a VRU ITS-S include at least a VRU HF container. The VRU HF container contains potentially fast-changing status information of the VRU ITS-S such as heading or speed. As the VAM is not used by VRUs from profile 3 (motorcyclist), none of these containers apply to VRUs profile 3. Instead, VRUs profile 3 only transmit the motorcycle special container with the CAM (see clauses 4.1, 4.4, and 7.4 in [TS103300-3]). In addition, VAMs generated by a VRU ITS-S may include one or more of the containers, as specified in Table 2.2-1, if relevant conditions are met.
The VRU HF container of a VAM (vruHighFrequencyContainer) is presented as specified in annex A of [TS103300-3]. The VRU HF container of the VAM contains potentially fast-changing status information of the VRU ITS-S. It includes the parameters listed in clause B.3.1 of [TS103300-3]. The VRU HF container includes the following parameters: heading; speed; longitudinalAcceleration; curvature OPTIONAL (Recommended for VRU Profile 2); curvatureCalculationMode OPTIONAL (Recommended for VRU Profile 2); yawRate OPTIONAL (Recommended for VRU Profile 2); lateralAcceleration OPTIONAL (Recommended for VRU Profile 2); verticalAcceleration OPTIONAL; vruLanePosition OPTIONAL (extended to include sidewalks and bicycle lanes); environment OPTIONAL; vruMovementControl OPTIONAL (Recommended for VRU Profile 2); orientation OPTIONAL (Recommended for VRU Profile 2); rollAngle OPTIONAL (Recommended for VRU Profile 2); and/or vruDeviceUsage OPTIONAL (Recommended for VRU Profile 1). Part of the information in this container do not make sense for some VRU profiles, and therefore, they are indicated as optional, but recommended to specific VRU profiles.
The VRU profile may be included in the VRU LF container and so is not transmitted as often as the VRU HF container (see clause 6.2 of [TS103300-3]). However, the receiver may deduce the VRU profile from the vruStationType field: pedestrian indicates profile 1, bicyclist or lightVRUvehicle indicates profile 2, moped or motorcycle indicates profile 3, and animals indicates profile 4.
The VRU HF DF may be used to describe the lane position in CAM is not sufficient when considering VRUs, as it does not include bicycle paths and sidewalks. Accordingly, it has been extended to cover all positions where a VRU could be located. When present, the vruLanePosition DF either describes a lane on the road (same as for a vehicle), a lane off the road or an island between two lanes of the previous types. Further details are provided in the DF definition, in clause B.3.10 of [TS103300-3].
The VruOrientation DF complements the dimensions of the VRU vehicle by defining the angle between the VRU vehicle longitudinal axis with regards to the WGS84 north. It is restricted to VRUs from profile 2 (bicyclist) and profile 3 (motorcyclist). When present, it is as defined in clause B.3.17. The VruOrientationAngle is different from the vehicle heading, which is related to the VRU movement while the orientation is related to the VRU position.
The RollAngle DF provides an indication of a cornering two-wheeler. It is defined as the angle between the ground plane and the current orientation of a vehicle's y-axis with respect to the ground plane about the x-axis as specified in ISO 8855. The DF also includes the angle accuracy. Both values are coded in the same manner as DF Heading, see A.101 in [TS102894-2], with the following conventions: positive values mean rolling to the right side (0 . . . “500”), where 500 corresponds to a roll angle value to the right of 50 degrees; negative values mean rolling to the left side (3 600 . . . “3 100”), where 3 100 corresponds to a roll angle value to the left of 50 degrees; values between 500 and 3 100 is not used; the DE vruDeviceUsage provides indications to the VAM receiver about a parallel activity of the VRU. This DE is similar to the DE_PersonalDeviceUsageState specified in SAE J2945/9. It is restricted to VRUs from profile 1, e.g., pedestrians. When present, it is as defined in clause B.3.19 of [TS103300-3] and will provide the possible values given in Table 2.2-2. To respect the user's choice for privacy, the device configuration application should include a consent form for transmitting this information. How this consent form is implemented is out of scope of the present document. In the case the option is opted-out (default), the device systematically sends the value “unavailable(0)”.
The DE VruMovementControl indicates the mechanism used by the VRU to control the longitudinal movement of the VRU vehicle. It is mostly aimed at VRUs from profile 2, e.g., bicyclists. When present, it is presented as defined in clause B.3.16 of [TS103300-3] and provides the possible values given in Table 2.2-3. The usage of the different values provided in the table may depend on the country where they apply. For example, a pedal movement could be necessary for braking, depending on the bicycle in some countries. This DE could also serve as information for the surrounding vehicles' on-board systems to identify the bicyclist (among others) and hence improve/speed up the “matching” process of the messages already received from the VRU vehicle (before it entered the car's field of view) and the object which is detected by the other vehicle's camera (once the VRU vehicle enters the field of view).
The heading DF includes or indicates a heading and heading accuracy of the originating ITS-S with regards to the true north. The heading accuracy provided in the DE headingConfidence value provides the accuracy of the measured vehicle heading with a confidence level of 95%. Otherwise, the value of the headingConfidence is set to unavailable. The DE is presented as specified in [TS102894-2] A.112 heading.
The speed DF includes or indicates a speed in moving direction and speed accuracy of the originating ITS-S. The speed accuracy provided in the DE speedConfidence provides the accuracy of the speed value with a confidence level of 95%. Otherwise, the speedConfidence is set to unavailable. The DE is presented as specified in [TS102894-2] A.126 Speed.
The longitudinalAcceleration DF includes or indicates a longitudinal acceleration of the originating ITS-S. It includes the measured longitudinal acceleration and its accuracy value with the confidence level of 95%. Otherwise, the longitudinalAccelerationConfidence is set to unavailable. The data element is presented as specified in [TS102894-2], A.116 LongitudinalAcceleration.
The curvature DF is related to the actual trajectory of the VRU vehicle. It includes: curvatureValue denoted as inverse of the VRU current curve radius and the turning direction of the curve with regards to the moving direction of the VRU as defined in [TS102894-2]. curvatureConfidence denoted as the accuracy of the provided curvatureValue for a confidence level of 95%. Optional. Recommended to VRUs Profile 2. The DF is presented as specified in [TS102894-2], A.107 Curvature.
The curvatureCalculationMode is a flag DE indicates whether vehicle yaw-rate is used in the calculation of the curvature of the VRU vehicle ITS-S that originates the VAM. Optional. Recommended to VRUs Profile 2. The DE is presented as specified [TS102894-2], A.13 CurvatureCalculationMode.
The yawRate DF is similar to the one used in CAM and includes: yawRateValue denotes the VRU rotation around the centre of mass of the empty vehicle or VRU living being. The leading sign denotes the direction of rotation. The value is negative if the motion is clockwise when viewing from the top (in street coordinates). yawRateConfidence denotes the accuracy for the 95% confidence level for the measured yawRateValue. Otherwise, the value of yawRateConfidence is set to unavailable. Optional. Recommended to VRUs Profile 2. The DF is presented as specified in [TS102894-2], A.132 YawRate.
The lateralAcceleration DF includes or indicates a VRU vehicle lateral acceleration in the street plane, perpendicular to the heading direction of the originating ITS-S in the centre of the mass of the empty VRU vehicle (for profile 2) or of the human or animal VRU (for profile 1 or 4). It includes the measured VRU lateral acceleration and its accuracy value with the confidence level of 95%. This DE is present if the data is available at the originating ITS-S. Optional but recommended to VRUs Profile 2. The DF is presented as specified in [TS102894-2], A.115 DF_LateralAcceleration.
The verticalAcceleration DF includes or indicates a Vertical Acceleration of the originating ITS-S. This DE is present if the data is available at the originating ITS-S. The DF is presented as specified in [TS102894-2], A.129 VerticalAcceleration.
The vruLanePosition DF includes or indicates a lane position of the referencePosition of a VRU, which is either a VRU-specific non-traffic lane or a standard traffic lane. This DF is present if the data is available at the originating ITS-S(Additional information is needed to unambiguously identify the lane position and to allow the correlation to a map. This is linked to an adequate geolocation precision).This DF includes one or more of the following fields: onRoadLanePosition; offRoadLanePosition; trafficIslandPosition; and/or mapPosition. The DF is presented as specified in annex A and clause F.3.1 of [TS103300-3].
The offRoadLanePosition DE includes or indicates a lane position of the VRU when it is in a VRU-specific non-traffic lane. The DE is presented as specified in clause F.3.2 of [TS103300-3].
The onRoadLanePosition DE includes or indicates a onRoadLanePosition of the referencePosition of a VRU, counted from the outside border of the road, in the direction of the traffic flow. This DE is present if the data is available at the originating ITS-S (see note: Additional information is needed to unambiguously identify the lane position and to allow the correlation to a map. This is linked to an adequate geolocation precision). The DE is presented as specified in [TS102894-2], A.40 LanePosition.
The trafficIslandPosition DE includes or indicates a lane position of the VRU when it is on a VRU-specific traffic island. The TrafficIslandPosition type consists of two lane-identifiers for the two lanes on either side of the traffic island. Each identifier may be an offRoadLanePosition, a onRoadLanePosition, or a mapPosition. The extensibility marker allows for future extensions of this type for traffic islands with more than two sides. The DF is presented as specified in clause F.3.3 of [TS103300-3].
The mapPosition DE includes or indicates a lane position of the VRU as indicated by a MAPEM message, as specified in ETSI TS 103 301 v1.1.1 (2016 November). The DF is presented as specified in clause F.3.5 of [TS103300-3].
The environment DE provides contextual awareness of the VRU among other road users. This DE is present only if the data is available at the originating ITS-S. The DE is presented as specified in clause F.3.6 of [TS103300-3].
The vruMovementControl DE indicates the mechanism used by the VRU to control the longitudinal movement of the VRU vehicle (see e.g., accelerationControl in [TS102894-2], A.2). The impact of this mechanism may be indicated by other DEs in the vruMotionPredictionContainer (e.g., headingChangeIndication, accelerationChangeIndication). This DE is present only if the data is available at the originating ITS-S. The DE is presented as specified in clause F.3.7 of [TS103300-3].
The vruOrientation DF complements the dimensions of the VRU vehicle by defining the angle of the VRU vehicle longitudinal axis with regards to the WGS84 north. The orientation of the VRU is an important factor, especially in the case where the VRU has fallen on the ground after an accident and constitutes a non-moving obstacle to other road users. This DE is present only if the data is available at the originating ITS-S. Optional. Recommended to VRUs profile 2 and VRUs profile 3. The DE is presented as specified in clause F.3.8 of [TS103300-3].
The rollAngle DF rollAngle provides the angle and angle accuracy between the ground plane and the current orientation of a vehicle's y-axis with respect to the ground plane about the x-axis according to the ISO 8855. The DF includes the following information: rollAngle Value; rollAngleConfidence. This DF is present only if the data is available at the originating ITS-S. Optional. Recommended to VRUs profile 2 and VRUs profile 3. The DF is presented as specified in [TS102894-2] for the heading DF, which is also expressed as an angle with its confidence (see A.101 DF Heading). The rollAngleValue is set as specified in clause 7.3.3 of [TS103300-3].
The vruDeviceUsage DE provides indications from the personal device about the potential activity of the VRU. It is harmonized with the SAE PSM. This DE is present only if the data is available at the originating ITS-S. Optional but recommended for VRUs profile 1. The DE is presented as specified in clause F.3.9 of [TS103300-3].
The VRU low frequency (LF) container (vruLowFrequencyContainer) of a VAM may be mandatory with higher periodicity. This DF is presented as specified in annex A of [TS103300-3]. The VRU LF container includes the following parameters: vruProfileAndSubProfile; vruSizeClass; vruExteriorLights (optional or mandatory for VRUs profile 2 and VRUs profile 3).
The VRU LF container of the VAM contains potential slow-changing information of the VRU ITS-S. It includes the parameters listed in clause B.4.1 of [TS103300-3]. Some elements are mandatory, others are optional or conditional mandatory. The VRU LF container is included into the VAM with a parametrizable frequency as specified in clause 6.2 of [TS103300-3]. The VAM VRU LF container has the following content. The DE VruProfileAndSubProfile contains the identification of the profile and the sub-profile of the originating VRU ITS-S if defined. Table 2.2-4 shows the list of profiles and sub-profiles specified in the present document.
The DE VruProfileAndSubProfile is OPTIONAL if the VRU LF container is present. If it is absent, this means that the profile is unavailable. The sub-profiles for VRU profile 3 are used only in the CAM special container. The DE VRUSizeClass contains information of the size of the VRU. The DE VruSizeClass depends on the VRU profile. This dependency is depicted in Table 2.2-5. An example of the DE VruProfileAndSubProfile is shown by Table 2.2-6.
The DE VruExteriorLight gives the status of the most important exterior lights switches of the VRU ITS-S that originates the VAM. The DE VruExteriorLight is mandatory for the profile 2 and profile 3 if the low VRU LF container is present. For all other profiles it is optional.
The vruProfileAndSubProfile DE/DF includes or indicates a profile of the ITS-S that originates the VAM, including sub-profile information. The setting rules for this value are out of may be defined or discussed elsewhere (see e.g., [TS103300-2] and/or [TS103300-3]). The profile ID identifies the four types of VRU profiles specified in [TS103300-2] and/or [TS103300-3]: pedestrian, bicyclist, motorcyclist, and animal. The profile type names are descriptive: for example, a human-powered tricycle would conform to the bicyclist profile. The subProfile ID identifies different types of VRUs within a profile. Conditional mandatory if vruLowFrequencyContainer is included. The DE is presented as specified in clause F.4.1 of [TS103300-3].
The vruSubProfilePedestrian DE/DF includes or indicates the sub-profile of the ITS-S that originates the VAM. The setting rules for this value are out of may be defined or discussed elsewhere (see e.g., [TS103300-2] and/or [TS103300-3]). The DE is presented as specified in clause F.4.2 of [TS103300-3] and/or as shown by Table 2.2-7.
The vruSubProfileBicyclist DE/DF includes or indicates the sub-profile of the ITS-S that originates the VAM. The setting rules for this value are out of the scope of the present document (see e.g., [TS103300-2]). The DE is presented as specified in clause F.4.3 of [TS103300-3] and/or as shown by Table 2.2-8.
The vruSubProfileMotorcyclist DE/DF includes or indicates the sub-profile of the ITS-S that originates the VAM. The setting rules for this value are out of the scope of the present document (see e.g., [TS103300-2]). The DE is presented as specified in clause F.4.4 of [TS103300-3] and/or as shown by Table 2.2-9.
The vruSubProfileAnimal DE/DF includes or indicates the sub-profile of the ITS-S that originates the VAM. The setting rules for this value are out of the scope of the present document (see e.g., [TS103300-2]). The DE is presented as specified in clause F.4.5 of [TS103300-3] and/or as shown by Table 2.2-10.
The vruSizeClass DE/DF includes or indicates the SizeClass of the ITS-S that originates the VAM. The setting rules for this field are given in Table 2.2-5. The size class is interpreted in combination with the profile type to get the range of dimensions of the VRU. Mandatory if vruLowFrequencyContainer is included. The DE is presented as specified in clause F.4.6 of [TS103300-3] and/or as shown by Table 2.2-11.
The vruExteriorLights DE/DF includes or indicates the status of the most important exterior lights switches of the VRU ITS-S that originates the VAM. Conditional Mandatory (for VRUs profile 2 and VRUs profile 3). The DE is presented as specified in clause F.4.7 of [TS103300-3] and/or as shown by Table 2.2-11.
The VAM VRU Motion Prediction container carries the past and future motion state information of the VRU. The VRU Motion Prediction Container of type VruMotionPredictionContainer contains information about the past locations of the VRU of type PathHistory, predicted future locations of the VRU (formatted as SequenceOfVruPathPoint), safe distance indication between VRU and other road users/objects of type SequenceOfVruSafeDistanceIndication, VRU's possible trajectory interception with another VRU/object is of type SequenceOfTrajectoryInterceptionIndication, the change in the acceleration of the VRU is of type AccelerationChangeIndication, the heading changes of the VRU is of HeadingChangeIndication, and changes in the stability of the VRU is of type StabilityChangeIndication. The VRU Motion Prediction Container includes the following parameters: pathHistory; pathPrediction; safeDistance; trajectoryInterceptionIndication; accelerationChangeIndication; headingChangeIndication; and stabilityChangeIndication.
The Path History DF (pathHistory) is of PathHistory type. The PathHistory DF comprises the VRU's recent movement over past time and/or distance. The PathHistory DF includes up to 40 past path points, each represented as DF PathPoint (see [TS102894-2], A117 pathHistory, A118; and/or clause 7.3.6 of [TS103300-3]). Each PathPoint includes pathPosition (A109) and an optional pathDeltaTime (A47) with granularity of 10 ms. When a VRU leaves a cluster and wants to transmit its past locations in the VAM, the VRU may use the PathHistory DF.
The Path Prediction DF (pathPrediction) provides the set of predicted locations of the ITS-S, confidence values and the corresponding future time instants. The pathPrediction DF is of SequenceOfVruPathPoint type and defines up to 40 future path points, confidence values and corresponding time instances of the VRU ITS-S. It contains future path information for up to 10 seconds or up to 40 path points, whichever is smaller. The DF is presented specified in clause F.7.1 of [TS103300-3] and/or Table 2.2-11. It is a sequence of VruPathPoint. The VruPathPoint DE provides the predicted location of the ITS-S, confidence value and the corresponding future time instant. The DE shall be presented specified in clause F.7.2 of [TS103300-3] and/or Table 2.2-12.
The Safe Distance Indication (e.g., vruSafeDistance) provides indication of safe distance between an ego-VRU and up to 8 other ITS-S or entity on the road to indicate whether the ego-VRU is at a safe distance (that is less likely to physically collide) from another ITS-S or entity on the road. The Safe Distance Indication is of type SequenceOfVruSafeDistanceIndication and provides an indication of whether the VRU is at a recommended safe distance laterally, longitudinally and vertically from up to 8 other stations in its vicinity. The simultaneous comparisons between Lateral Distance (LaD), Longitudinal Distance (LoD) and Vertical Distance (VD) and their respective thresholds, Minimum Safe Lateral Distance (MSLaD), Minimum Safe Longitudinal Distance (MSLoD), and Minimum Safe Vertical Distance (MSVD) as defined in clause 6.5.10.5 of [TS103300-2], is used for setting the VruSafeDistanceIndication DF. Other ITS-S involved are indicated as StationID DE within the VruSafeDistanceIndication DE. The timetocollision (TTC) DE within the container reflects the estimated time taken for collision based on the latest onboard sensor measurements and VAMs. The DF is presented as specified in clause F.7.3 of [TS103300-3] and is a sequence of VruSafeDistanceIndication.
The VruSafeDistanceIndication DF provides indication of safe distance between an ego-VRU and ITS-S or entity on the road to indicate whether the ego-VRU is at a safe distance (that is less likely to physically collide) from another ITS-S or entity on the road. It depends on subjectStation; stationSafeDistanceIndication; and timeToCollision. This DF is presented as specified in clause F.7.4 of [TS103300-3].
The stationSafeDistanceIndication DE includes or indicates an indication when the conditional relations LaD<MSLaD, LoD<MSLoD, and VD<MSVD are simultaneously satisfied. This DE is mandatory within the VruSafeDistanceIndication in some implementations. The DE shall be presented as specified in clause F.7.5 of [TS103300-3]. The timeToCollision DF includes or indicates the time to collision (TTC) DE shall reflect the estimated time taken for collision based on the latest onboard sensor measurements and VAMs. This DF is presented as specified in clause F.7.14 of [TS103300-3], by DE_ActionDeltaTime.
The trajectoryInterception DF provides the indication for possible trajectory interception with up to 8 VRUs or other objects on the road. This DF is presented as specified in clause F.7.6 of [TS103300-3] and/or Table 2.2-F.7.6, and is a sequence of VruTrajectoryInterceptionIndication. The VrutrajectoryInterceptionIndication is defined as an indicator of the ego-VRU trajectory and its potential interception with another station or object on the road. It depends on subjectStation; trajectoryInterceptionProbability; and/or trajectoryInterceptionConfidence. This DF is presented as specified in clause F.7.7 of [TS103300-3] and/or Table 2.2-F.7.7.
The trajectoryInterceptionProbability DE defines the probability for the ego-VRU's trajectory intercepts with any other object's trajectory on the road. In some implementations, this DE is mandatory within VruTrajectoryInterceptionIndication, and this DE is presented as specified in clause F.7.8 of [TS103300-3] and/or Table 2.2-F.7.8. The trajectoryInterceptionConfidence DE defines the confidence level of trajectoryInterceptionProbability calculations, and is presented as specified in clause F.7.9 of [TS103300-3] and/or Table 2.2-F.7.9.
The SequenceOfTrajectoryInterceptionIndication DF contains ego-VRU's possible trajectory interception with up to 8 other stations in the vicinity of the ego-VRU. The trajectory interception of a VRU is indicated by VruTrajectoryInterceptionIndication DF. The other ITS-S involved are designated by StationID DE. The trajectory interception probability and its confidence level metrics are indicated by TrajectoryInterceptionProbability and TrajectoryInterceptionConfidence DEs. The Trajectory Interception Indication (TII) DF corresponds to the TII definition in [TS103300-2].
The HeadingChangeIndication DF contains ego-VRU's change of heading in the future (left or right) for a time period. This DF provides additional data elements associated to heading change indicators such as a change of travel direction (left or right). The DE LeftOrRight gives the choice between heading change in left and right directions. The direction change action is performed for a period of actionDeltaTime. The DE_ActionDeltaTime indicates the time duration. When present the DF includes the following data elements: LeftOrRight; and actionDeltaTime. The DF is presented as specified in clause F.7.10 of [TS103300-3] and/or Table 2.2-F.7.10.
The leftOrRight DE provides the actions turn left or turn right performed by the VRU when available. A turn left or turn right is performed for time period specified by actionDeltaTime. This DE is presented as specified in clause F.7.11 of [TS103300-3] and/or as shown by Table 2.2-F.7.11. The actionDeltaTime DE provides set of equally spaced time instances when available. The DE defines set of time instances 100 ms granularity starting from 0 (current instant) up to 12.6 seconds. The actionDeltaTime DE is presented as specified in clause F.7.14 of [TS103300-3].
The AccelerationChangeIndication DF provides an acceleration change indication of the VRU. This DF contains ego-VRU's change of acceleration in the future (acceleration or deceleration) for a time period. When present this DF indicates an anticipated change in the VRU speed. Speed changes can be: decelerating for period of actionDeltaTime, or accelerating for period of actionDeltaTime. The DE AccelOrDecel gives the choice between acceleration and deceleration. The DE ActionDeltaTime indicates the time duration. The DF shall be presented as specified in clause F.7.12 of [TS103300-3] and/or as shown by Table 2.2-F.7.12. The accelOrDecel DE provides the actions Acceleration or Deceleration performed by the VRU when available. Acceleration or Deceleration is performed for time period specified by actionDeltaTime. This DE is presented as specified in clause F.7.13 of [TS103300-3] and/or as shown by Table 2.2-F.7.13.
The StabilityChangeIndication DF provides an estimation of the VRU stability. This DF contains ego-VRU's change in stability for a time period. When present, this The StabilityChangeIndication DF provides information about the VRU stability. It is expressed in the estimated probability of a complete VRU stability loss which may lead to a VRU ejection of its VRU vehicle. The DE StabilityLossProbability or vruStabilityLossProbability gives the probability indication of the stability loss of the ego-VRU. The loss of stability is projected for a time period actionDeltaTime. The DE ActionDeltaTime indicates the time duration. The description of the container is provided in clause B.7 of [TS103300-3] and the corresponding DFs and DEs to be added to [TS102894-2] are provided in clause F.7.15 of [TS103300-3].
The vruStabilityLossProbability DE provides an estimation of the VRU stability probability. When present this DE provides the stability loss probability of the VRU in the steps of 2% with 0 for full stability and 100% loss of stability. This DE is presented as specified in clause F.7.16 of [TS103300-3].
Table 2.2-16 shows the parameters for a VAM generation. The parameters may be set on individual devices or system wide and may depend on external conditions or be independent of them.
The parameters in Table 2.2-17 govern the VAM generation triggering. The parameters may be set on individual devices or system wide and may depend on external conditions or be independent of them.
According to various embodiments, a procedure for VRU profile awareness capturing the functional system and communication aspects are elaborated as follows.
Step 1: IDLE/ACTIVE state Detection. When the VRU ITS-S 117 equipped with sensors (such as magnetometer, gyroscope, etc.) can sense even the slightest of VRU motions of any sorts, the movement sensing (countdown) timer defined in short as MST gets started at the VRU ITS-S 117 which initiates sensing of the possible change in position, heading direction and speed. The decision to make is whether the motion leads to any movement that starts changing the position, has a specific directional heading and non-zero speed. Subsequently, if the VRU is within, say, X meters of any designated street (where X≤5). When these conditions are met, the VRU is declared to be ACTIVE. In ACTIVE state, the VRU ITS-S 117 must keep transmitting VAM with a periodicity of TVAMperiod depending upon the state of the VRU motion as follows: If the VRU is on the road (pedestrian VRU), must be at most 100 ms, e.g., TVAMperiod≤100 ms. If the VRU gets into a moving vehicle, Tperiod is larger than 100 ms, e.g., TVAMperiod>100 ms. If the VRU is in IDLE mode (for instance, inside a building), then Tperiod>>100 ms may be countably infinite, meaning, there may not be any need for VAM transmissions.
Step 2: VRU Initial Profile and Sub-Profile Designation. This step focuses on utilizing the following parameters for determining the initial VRU Profile Category along with the sub-profile parameters such as, for example, VRU ACTIVE/IDLE; VRU Unique ID; VRU Position (global coordinates); VRU Speed; VRU Heading (Direction); VRU Initial Profile ID; VRU Sub-Profile ID; and/or some other sub-profile parameters such as those discussed herein.
The sub-profile parameters estimated in this stage are based on the VRU ITS-S 117 on-board sensor capabilities. In embodiments, a profile as well as sub-profile categorization to assign the initial VRU profile based on the estimated VRU speed, environment, weight class by comparison against a pre-defined corresponding threshold speed/environment/weight ranges as defined in Table 2.2-2. Thus, based on the estimated VRU speed, environment and weight class, the VRU profile can be initialized to be one of the four profiles defined in Section 6.1 of [TS103300-2]. Furthermore, the sub-profiles are also initialized for the VRU based on the above three parameters (speed, environment and weight class). Such sub-profiling helps in robustly predicting the VRU profile transition. Furthermore, how the VRU sub-profile parameters can enable prediction of VRU profile transition more accurately along with dynamic motion prediction of the VRU are elaborated in Step 4 below.
Step 3: Broadcast VAM with VRU Profile Awareness Message Parameters. Step 2 then leads to VRU device WAKE-UP and broadcasting of a VAM that may be listened to by both the nearby V-ITS-S 110 as well as any R-ITS-S 130 within the vicinity of the broadcast range (for instance, up to 300m). The VAM is then constructed as shown in
Step 4: VRU Profile Transition Update based on Motion State Prediction. At this stage, the key function of updating the VRU current profile based on most recent VRU profile parameters defined in Step 2 is undertaken. In embodiments, profile transition awareness and update is based on utilization of the instantaneous speed and environment (and weight, if applicable) classification along with the dynamic motion state prediction of the VRU by utilizing on-board sensors such as accelerometer, gyroscope, compass, GPS, gravity senor, speedometer, and others in the VRU (see e.g., R. A. Voicu et al., “Human Physical Activity Recognition Using Smartphone Sensors,” Sensors 2019, 458 (23 Jan. 2019), which is hereby incorporated by reference in its entirety). For instance, the possible states that the VRU may currently be in are as follows:
Once the dynamic motion state is estimated, the estimation is utilized to decide upon whether the existing VRU profile has changed or it remains the same. For instance, if there is constant high acceleration of a slow-moving VRU detected after changes in its movement, then there is a high probability that a pedestrian VRU (Profile 1) has transitioned into a motorcyclist VRU (Profile 3). Thus, the dynamic motion prediction outcome serves as an input to probabilistically estimate such transition. Similarly, a constant deceleration also provides a hint at a potential upcoming change in the VRU profile, for instance, when a VRU motorcyclist or bicyclist is braking to come to a stop following which it may park the motorcycle or bike and start walking thus transitioning from Profile 2 (or Profile 3) to Profile 1. At the end of Step 3, the VRU ITS-S 117 is responsible for updating the initial profile based on all the sensor input. Additionally, the VRU ITS-S 117 could easily come up with trajectory related predictions of the VRU via time-series analysis of the sensory data which can be used to additional improve the dynamic state motion prediction thus helping to increase the robustness of VRU profile transition awareness.
In another embodiment, the profile prediction is based on the Deep neural networks (DNN) based classification. The onboard sensor inputs are fed in to the DNN and it infers the profile type. The training data sets are created for different profiles with various environment conditions.
Step 5: VAM fields update and transmission. Following Step 4, the VRU ITS-S 117 constructs and transmits a VAM to indicate the updated profile as shown in
Step 6: VRU profile Category Update at V-ITS-S and/or R-ITS-S for Collision Risk Analysis and VAM-based notification to VRU. On reception of the VAM with the profile update, the V-ITS-S 110 and R-ITS-S 130 receive the most recent profile category for the respective VRU's profile category at their end. Followed by the VAM reception 903, the V-ITS-S 110 or R-ITS-S 130 check for any changes in the profile. Regardless of the VRU profile category change/no-change the V-ITS-S 110 and R-ITS-S 130 stations perform a functional check on the Collision Risk Analysis (see e.g., CRA function 816 of
As depicted in
To enhance the VRU profile awareness at the V-ITS-S 110 and R-ITS-S 130 via cooperative sharing of the VRU profile related awareness aiming to enhance the robustness of the VRU profile transition awareness.
To aid in VRU ITS-S 117 (e.g., including P-ITS-S 1200 of
Transfer learning based behavioral model sharing/building between VRU ITS-S 117 and/or R-ITS-S 130 in different geo-areas to collaboratively maintain awareness of the VRU profile parameters. VRU device maintains its specific behavioral model for the current profile it is in and uploads its behavioral data to the V-ITS-S 110 and/or R-ITS-S 130 periodically.
VRU ITS-S 117 may also be directly queried by the V-ITS-S 110 and/or R-ITS-S 130, enabling two-way handshaking for the model building/update
Collaborative V-ITS-S 110 and R-ITS-S 130 profiling based on collective perception without direct VRU involvement may also be possible when V-ITS-S 110 and/or R-ITS-S 130 are equipped with HD cameras, LIDAR and RADAR sensors via video/sensory analytics to identify the switch in VRU profile without directly querying the VRU device. In cases when the V-ITS-S 110 does not have such video/sensory analytics capability, V-ITS-S 110 may download VRU profile directly from the connected RSU-ITS-S in real-time to enable VRU profile awareness at the V-ITS-S 110.
The VAM originated from a VRU ITS-S 117 does not address awareness of non-equipped VRUs 116 effectively. Here, non-equipped VRUs 116 are VRUs 116 without any ITS-S for Tx, Rx or both Tx/Rx (e.g., VRUs 116 that are not VRU-Tx, VRU-Rx, or VRU-St; see e.g., Table 2-1). In many crowded situations such as busy intersection, zebra crossing, school drop off and pick up area, public bus stops, school bus stops, busy crossing near shopping mall, construction work area, and others, both equipped and non-equipped VRUs 116 will be present. Cluster formation and management by an individual VRU ITS-S 117 (as the cluster leader or cluster head) is limited by the available resources (e.g., computational, communication, sensing) VRU cluster formed by an individual VRU 116/117 cannot include non-equipped VRUs 116 in the cluster. In such cases, the VRUs 116/117 should be able to decode and interpret the collective perception message (CPM) to obtain the full environment awareness for safety. To this end, infrastructure (e.g., R-ITS-Ss 130) can play a role in detecting (e.g., via sensors) potential VRUs 116/117 and grouping them together into clusters in such scenarios including both equipped VRUs 117 and non-equipped VRUs 116. For example, a static R-ITS-S 130 may be installed at busy intersection, zebra crossing, school drop off and pick up area, busy crossing near shopping mall, and the like while a mobile R-ITS-S 130 can be installed on designated vehicles (e.g., school bus, city bus, service vehicle, drones/robots, etc.) to serve as infrastructure/R-ITS-S 130 on public bus stops, school bus stops, construction work area, etc., for this purpose.
In some cases, non-VRU ITS-S(e.g., Static R-ITS-S 130 or Mobile R-ITS-S 130 on designated vehicles like school bus, construction work vehicle, police cars) may need to transmit a VAM (e.g., infrastructure VAM) specifically when non-equipped VRUs 116 are detected. Such infrastructure VAM may be transmitted for reporting either individual detected VRUs or cluster(s) of VRUs. Non-VRU ITS-S may select to transmit infrastructure VAM reporting individual detected VRUs 116/117 and cluster(s) of VRUs in the same infrastructure VAM by including zero or more individual detected VRUs and zero or more clusters of VRUs 116/117 in the same infrastructure VAM.
Existing VAMs allow information sharing of either one ego-VRU 116/117 or one VRU cluster. However, in case of non-VRU ITS-Ss (e.g., R-ITS-Ss 130 or designated V-ITS-Ss 110) VAM, non-VRU ITS-S may be able to detect one or more individual VRUs 116/117, and/or one or more VRU clusters in the field of view (FOV), which need to be reported in the VAM.
In some embodiments, existing VAM format may be modified to enable non-VRU ITS-S VAMs. In a non-VRU ITS-S VAM, the VRU awareness contents of one or more VRUs 116/117 and/or one or more VRU clusters are carried. In addition, detailed mechanisms for non-VRU ITS-S assisted VRU clustering including both equipped VRUs 116/117 and non-equipped VRUs 116 are considered where a non-VRU ITS-S(e.g., R-ITS-S 130) acts as a cluster leader and transmits non-VRU ITS-S VAMs.
Reporting all detected VRUs 116/117 and/or VRU clusters individually by non-VRU ITS-Ss can be inefficient in certain scenarios such as presence of large number of VRUs 116/117 or overlapping view of VRUs or occlusion of VRUs 116/117 in the FOV of sensors at the originating non-VRU ITS-S. Such reporting via existing DFs/DEs in the VAM in case of large number of perceived VRUs 116/117 and/or VRU clusters may require large communication overhead and increased delay in reporting all VRUs 116/117 and/or VRU clusters. The non-VRU ITS-S may need to use self-admission control, redundancy mitigation or self-contained segmentation to manage the congestion in the access layers. The self-contained segments are independent VAM messages and can be transmitted in each successive VAM generation events.
For VAM Transmission Management by VBS at Non-VRU ITS-S, if a non-VRU ITS-S is not already transmitting consecutive (such as periodic) infrastructure VAM and the infrastructure VAM transmission does not subject to redundancy mitigation techniques, first time infrastructure VAM should be generated immediately or at earliest time for transmission when any of the following conditions is satisfied:
(1) At least one VRU is detected by originating Non-VRU ITS-S where the detected VRU has not transmitted VAM for at least T_GenVamMax duration; the perceived location of the detected VRU does not fall in a bounding box of Cluster specified in any VRU Cluster VAMs received by originating Non-VRU ITS-S during last T_GenVamMax duration; and the detected VRU is not included in any infrastructure VAMs received by originating Non-VRU ITS-S during last T_GenVamMax duration.
(2) At least one VRU Cluster is detected by originating Non-VRU ITS-S where the Cluster head of the detected VRU Cluster has not transmitted VRU Cluster VAM for at least T_GenVamMax duration; the perceived bounding box of the detected VRU cluster does not overlap more than a pre-defined threshold maxInterVRUClusterOverlapInfrastructureVAM with the bounding box of any VRU Clusters specified in VRU Cluster VAMs or infrastructure VAMs received by originating Non-VRU ITS-S during last T_GenVamMax duration.
Consecutive infrastructure VAM transmission is contingent to conditions as described here. Consecutive infrastructure VAM generation events should occur at an interval equal to or larger than T_GenVam. An infrastructure VAM should be generated for transmission as part of a generation event if the originating non-VRU ITS-S has at least one selected perceived VRU or VRU Cluster to be included in current infrastructure VAM.
For perceived VRU inclusion Management in Current Non-VRU ITS-S VAM, the perceived VRUs considered for inclusion in current infrastructure VAM should fulfil all these conditions: (1) originating Non-VRU ITS-S has not received any VAM from the detected VRU for at least T_GenVamMax duration; (2) the perceived location of the detected VRU does not fall in a bounding box of VRU Clusters specified in any VRU Cluster VAMs received by originating Non-VRU ITS-S during last T_GenVamMax duration; (3) the detected VRU is not included in any infrastructure VAMs received by originating Non-VRU ITS-S during last T_GenVamMax duration; and (4) the detected VRU does not fall in bounding box of any VRU clusters to be included in the current infrastructure VAM by originating Non-VRU ITS-S.
A VRU perceived with sufficient confidence level fulfilling above conditions and not subject to redundancy mitigation techniques should be selected for inclusion in the current VAM generation event if the perceived VRU additionally satisfy one of the following conditions:
(1) The VRU has first been detected by originating Non-VRU ITS-S after the last infrastructure VAM generation event.
(2) The time elapsed since the last time the perceived VRU was included in an infrastructure VAM exceeds T_GenVamMax.
(3) the Euclidian absolute distance between the current estimated position of the reference point for the perceived VRU and the estimated position of the reference point for the perceived VRU lastly included in the infrastructure VAM exceeds minReferencePointPositionChangeThreshold.
(4) The difference between the current estimated ground speed of the reference point for the perceived VRU and the estimated absolute speed of the reference point for the perceived VRU lastly included in the infrastructure VAM exceeds minGroundSpeedChangeThreshold.
(5) The difference between the orientation of the vector of the current estimated ground velocity of the reference point for the perceived VRU and the estimated orientation of the vector of the ground velocity of the reference point for the perceived VRU lastly included in the infrastructure VAM exceeds minGroundVelocityOrientationChangeThreshold.
(6) The infrastructure or vehicles has determined that there is difference between the current estimated trajectory interception indication with vehicle(s) or other VRU(s) and the trajectory interception indication with vehicle(s) or other VRU(s) lastly reported in an infrastructure VAM.
(7) One or more new vehicles or other VRUs (e.g. VRU Profile 3—Motorcyclist) have satisfied the following conditions simultaneously after the lastly transmitted VAM. The conditions are: coming closer than minimum safe lateral distance (MSLaD) laterally, coming closer than minimum safe longitudinal distance (MSLoD) longitudinally and coming closer than minimum safe vertical distance (MSVD) vertically to the VRU after the lastly transmitted infrastructure VAM.
For perceived VRU Cluster inclusion Management in Current Non-VRU ITS-S VAM, the perceived VRU Clusters considered for inclusion in current infrastructure VAM should fulfil all of the following conditions: The perceived bounding box of the detected VRU cluster does not overlap more than maxInterVRUClusterOverlapInfrastructureVAM with the bounding box of VRU Cluster specified in any of the VRU Cluster VAMs or infrastructure VAMs received by originating Non-VRU ITS-S during last T_GenVamMax duration.
A VRU Cluster perceived with sufficient confidence level fulfilling above conditions and not subject to redundancy mitigation techniques should be selected for inclusion in the current VAM generation if the perceived VRU Cluster additionally satisfy one of the following conditions:
(1) The VRU Cluster has first been detected by originating Non-VRU ITS-S after the last infrastructure VAM generation event.
(2) The time elapsed since the last time the perceived VRU Cluster was included in an infrastructure VAM exceeds T_GenVamMax.
(3) The Euclidian absolute distance between the current estimated position of the reference point of the perceived VRU Cluster and the estimated position of the reference point of the perceived VRU Cluster lastly included in an infrastructure VAM exceeds minReferencePointPositionChangeThreshold.
(4) The difference between the current estimated Width of the perceived VRU Cluster and the estimated Width of the perceived VRU Cluster included in the lastly transmitted VAM exceeds minClusterWidthChangeThreshold.
(5) The difference between the current estimated Length of the perceived VRU Cluster and the estimated Length of the perceived VRU Cluster included in the lastly transmitted VAM exceeds minClusterLengthChangeThreshold.
(6) The difference between the current estimated ground speed of the reference point of the perceived VRU Cluster and the estimated absolute speed of the reference point included in the lastly transmitted VAM exceeds minGroundSpeedChangeThreshold.
(7) The difference between the orientation of the vector of the current estimated ground velocity of the reference point of the perceived VRU Cluster and the estimated orientation of the vector of the ground velocity of the reference point included in the lastly transmitted infrastructure VAM exceeds minGroundVelocityOrientationChangeThreshold.
(8) The infrastructure or vehicles determined that there is difference between the current estimated trajectory interception indication with vehicle(s) or other VRU(s) and the trajectory interception indication with vehicle(s) or other VRU(s) lastly reported in an infrastructure VAM.
(9) Originating Non-VRU ITS-S has determined to merge the perceived cluster with other cluster(s) after previous infrastructure VAM generation event.
(10) Originating Non-VRU ITS-S has determined to split the current cluster after previous infrastructure VAM generation event.
(11) Originating Non-VRU ITS-S has determined change in type of perceived VRU cluster (e.g. from Homogeneous to Heterogeneous Cluster or vice versa) after previous infrastructure VAM generation event.
(12) Originating Non-VRU ITS-S has determined that one or more new vehicles or non-member VRUs (e.g. VRU Profile 3—Motorcyclist) have satisfied the following conditions simultaneously after the lastly transmitted VAM. The conditions are: coming closer than minimum safe lateral distance (MSLaD) laterally, coming closer than minimum safe longitudinal distance (MSLoD) longitudinally and coming closer than minimum safe vertical distance (MSVD) vertically to the Cluster bounding box after the lastly transmitted infrastructure VAM.
Embodiments also include a VAM Extension container. The VRU Extension container of type VamExtension should carry VRU low frequency, VRU high frequency, cluster information container, cluster operation container, motion prediction container for each of the VRU and VRU Clusters reported in a non-VRU ITS-S originated VAM. Extension additionally carry totalIndividualVruReported, total VruClusterReported, VruRoadGridOccupancy containers for in a non-VRU ITS-S originated VAM.
The Road Grid Occupancy DF is of type VruRoadGridOccupancy and should provide an indication of whether the cells are occupied (by another VRU ITS-station or object) or free. The indication should be represented by the VruGridOccupancyStatusIndication DE and the corresponding confidence value of should be given by ConfidenceLevelPerCell DE. Additional DF/DE s are included for carrying the grid and cell sizes, road segment reference ID and reference point of the grid.
Table 2.6-1 shows an example VRU Profile Awareness VAM, which may be used in the VRU Profile Awareness embodiments discussed previously. The example VRU Profile Awareness VAM is structured in the message formats according to SAE International, “Dedicated Short Range Communications (DSRC) Message Set Dictionary”, J2735 201603 (2016 Mar. 30) (hereinafter “[SAEJ2735]”).
Some new DEs and DFs in vruHighFrequencyContainer according to the example of Table 2.6-1 include DE VruEnvironment and DE VruMovementControl, which are further detailed by Table 2.6-2 and Table 2.6-3.
In these embodiments, the new V2X message or existing V2X/ITS messages may be generated by a suitable service or facility in the facilities layer (see e.g.,
Embodiments herein include VRU Maneuver Coordination Mechanisms for Collision Risk Analysis (see e.g., CRA function 816 of
Maneuver Coordination Service (MCS) enables proximate ITS-S′ (including between vehicles and infrastructure) to exchange information that facilitates and supports driving automation functions of automated and connected vehicles. In particular, MCS enables proximate vehicles to share their maneuver intentions (e.g., lane change, lane passes, overtakes, cut-ins, drift into Ego Lane, and the like), planned trajectory, detected traffic situations, ITS-S state, and/or other like information. MCS provides a way of maneuver negotiation and interaction among proximate vehicles for safe, reliable, efficient, and comfortable driving. MCS may utilize a message type referred to as a Maneuver Coordination Message (MCM). MCMs include a set of DEs and/or DFs to transmit vehicle status, trajectory, and maneuver intention. Examples of MCMs are discussed in more detail in U.S. Provisional App. No. 62/930,354, “Maneuver Coordination Service For Vehicular Networks”, filed on Nov. 4, 2019 (“[a1]”) and U.S. Provisional App. No. 62/962,760, “Maneuver Coordination Service For Intelligent Transportation System”, filed on Jan. 17, 2020 (“[a2]”). MCS assists in Traffic Congestion Avoidance coordination (e.g., in case a vehicle is in virtual deadlock due to parallel slow vehicles in front of it in all lanes), traffic efficiency enhancement (e.g., merging into a highway, Exiting a Highway, roundabout entering/exiting, confirming vehicle's intension such as false right turn indication of an approaching vehicle, etc.), safety enhancement in maneuver (e.g., safe and efficient lane changes, overtake, etc.), smart intersection management, emergency trajectory coordination (e.g., in case when an obstacle, animal, kid suddenly comes in a lane and more than one vehicles are required to agree on a collective maneuver plan), etc. MCS can also help in enhancing user experience by avoiding frequent hard breaks as front and other proximity (proximate) vehicles indicate their intention in advance whenever possible.
The present disclosure provides various embodiments for enabling MCS in VRU sub-systems and the corresponding VAM message exchange protocol(s) and format(s) to support MCS. The present disclosure cover use cases including emergency and unpredictable situations as exemplified in [TR103300-1] (but not limited only to the cases in [TR103300-1]). Some use case examples of the emergency or unpredictable situations which require the need for maneuver coordination among VRUs 116 are shown in Table 3-1.
In particular, the embodiments herein coordinate the maneuvers among the ego VRU 116, other VRUs 116 and non-VRUs 605 sharing a road/environment scene by defining VRU MCS mechanisms to cover for emergency situations where the collision is very likely (as exemplified in example use cases 1 to 10 in Table 3-1). The mechanisms lead to extensions of the functional system, functional communications and operational communications architecture of the VRU ITS-S 117. Embodiments also include VAM format extension to define: (i) MCS related data field for enabling MCS in both emergency and non-emergency situations (ii) potential trajectory interception (of the ego VRU with the other VRUs 116 and/or non-VRUs 605 and/or objects/obstacles on the road) related awareness indication. Embodiments also include a VAM exchange protocol (multiple two-way handshaking) for enabling MCS among VRU ITS-Ss 117 and other road ITS-Ss such as V-ITS-Ss 110, R-ITS-Ss 130 for cases when the VRU may not be equipped with any Tx/Rx capability, e.g., VRU Profile 1 (small kids) or VRU Profile 4 (wild animals). The embodiments herein provide VRU safety in ITS, which enhances vehicle robustness in timely collision risk analysis and collision avoidance. The embodiments herein also enable road user safety.
In VRUs 116, MCS is a crucial feature to address the issues outlined above for VRU collision avoidance sub-system of ITS for enabling cooperative collision risk analysis in the vicinity of the VRU environment and to trigger maneuver related actions for the ego VRU as well as neighboring VRUs 116 (and non-VRUs 605) at risk. In embodiments, a collision risk analysis module suggests a high collision risk, the maneuver related actions resulting from the outcome of the MCS need to be executed. Some examples of such actions are emergency stopping, deceleration, acceleration, trajectory change as well as VRU dynamic motion/momentum related actions. Such actions need to be executed in time to avoid potential collisions. Furthermore, the maneuver related actions at the ego VRU (e.g., under direct danger) also need to be shared among the immediate neighbors of the ego VRU (e.g., other VRUs 116 and non-VRUs 605 around or proximate to the ego VRU) for triggering coordinated maneuvering across the users of the road so that all sorts of potential collision can be avoided. Additionally, the MCS should be enabled to cover for all kinds of VRU profiles as well as VRU types. The MCS should also take into consideration the sensor data of all the involved ITS-S, timely exchange of messages to enable collision risk analysis at each ITS-S and the resulting maneuvering action coordination among the ITS-Ss.
Based on the above, functional features for VRU system with well-defined system-level, communications-level, and operational-level mechanisms should be defined and developed to enable VRU MCS in ITS for enhancing Collision Risk Analysis and Collision Avoidance Actions. Various embodiments including message exchange protocol(s), message construction data fields influencing the functional, system and operational requirements update for enabling MCS in VRU are discussed in more detail below.
The VRU Maneuver Coordination function executes the collision avoidance actions which are associated to the collision avoidance strategy that has been decided. This function should be present at the vehicle level, depending also on the vehicle level of automation (e.g., not present in non-automated vehicles), and may be present at the VRU device level according to the VRU profile. At the vehicle level, this function interfaces the vehicle electronics controlling the vehicle dynamic state in terms of heading and velocity. At the VRU device level, this function may interface the HMI support function, according to the VRU profile, to be able to issue a warning or alert to the VRU according to the TTC.
maneuver coordination can be proposed to vehicles from an infrastructure element, which may be able to obtain a better perception of the motion dynamic of the involved moving objects, by means of its own sensors or by the fusion of their data with the remote perception obtained from standard messages such as CAMs.
The man oeuvre coordination at VRU may be enabled by sharing among the ego-VRU and the neighboring ITSs, first the TII reflecting how likely is the ego-VRU ITS-S trajectory going to be intercepted by the neighboring ITSs (other VRU or non-VRU ITSs such as vehicles), and second, MI to indicate the type of VRU maneuvering needed.
Depending upon the analysis of the scene in terms of the sensory as well as shared inputs, simple TII ranges can be defined to indicate the likelihood of the ego-VRU's path to be intercepted by another entity. Such indication helps to trigger timely maneuvering. For instance, TII could be defined in terms of TII index that may simply indicate the chances of potential trajectory interception (low, medium, high or very high) for collision risk analysis. If there are multiple other entities, the TII may be indicated for the specific entity differentiable via a simple ID which depends upon the simultaneous number of entities in the vicinity at that time. The vicinity could even be just one cluster that the current VRU is located in. For example, the minimum number of entities or users in a cluster is 50 per cluster (worst case). However, the set of users that may have the potential to collide with the VRU could be much less than 50 thus possible to indicate via few bits in say, VAM.
On the other hand, the MI parameter can be helpful in collision risk avoidance 817 (see e.g.,
Embodiments include a protocol to enable VRU MCS, VAM data fields construction and VAM exchange between the ego VRU ITS-S 117, other VRU ITS-Ss 117, and non-VRU ITSs such as V-ITS-Ss 110 and R-ITS-Ss 130 which are in vicinity of the VRU. The techniques for enabling MCS from the perspective of an ego VRU ITS-S 117 co-located in the vicinity of other VRUs 116 and non-VRUs 605 are discussed in more detail infra.
Referring to the other VRU ITS-S 117, at step 0, the other VRU ITS-S 117 collects and processes sensor data of the other VRU ITS-S 117 (e.g., ID, Position, Profile, Speed, Direction, Orientation, Trajectory, Velocity, etc.). At step 1, an initial VAM transmission for aiding awareness at the ego VRU ITS-S 117 takes place including: step 1(a) where the other VRU ITS-S 117 receives VAM from Ego VRU ITS-S 117; step 1(b) where the other VRU ITS-S 117 transmits a VAM to Ego VRU ITS-S 117, and step 1(c) where a VAM/DENM exchange takes place between the other VRU ITS-S 117 and non-VRU ITS-S 605. At step 2, the other VRU ITS-S 117 performs Trajectory Interception Probability Computation (TIPC). At step 3, the other VRU ITS-S 117 performs Collision Risk Analysis (CRA) 816 (see e.g.,
Referring to the ego VRU ITS-Ss 117, at step 0, the ego VRU ITS-Ss 117 collects VRU sensor data from its on-board sensors. In examples, the sensor data includes one or more of a VRU ID, Position, Profile, Speed, Direction, Orientation, Trajectory, Velocity, etc. At step 1, an initial VAM transmission for aiding other road users with VRU awareness takes place including steps 1(a) and 1(b). At step 1(a), the ego VRU ITS-Ss 117 transmits a VAM to the other VRU 116/117 and the VAM to the non-VRU ITS-S 605. At step 1(b), the ego VRU ITS-Ss 117 receives a VAM from the other VRU ITS-Ss 117 and receives CAM/DENM from the non-VRU ITS-S 605. At step 2, the ego VRU ITS-Ss 117 performs TIPC. At step 3, the ego VRU ITS-Ss 117 performs a CRA 816 (see e.g.,
Referring to the non-VRU ITS-S 605 (e.g., one or more V-ITS-Ss 110 and/or one or more R-ITS-Ss 130), at step 0, the non-VRU ITS-S 605 collects non-VRU 605 sensor data (e.g., image data from image capture sensors (e.g., cameras), LIDAR data, radar data, etc.). At step 1, an initial CAM/DENM Transmission for aiding awareness at ego VRU ITS-S 117 takes place including steps 1(a), 1(b), and 1(c). At step 1(a), the non-VRU ITS-S 605 receives VAM from Ego VRU; at step 1(b), the non-VRU ITS-S 605 transmits CAM/DENM to Ego VRU; and at step 1(c), the non-VRU ITS-S 605 a VAM/DENM exchange takes place between other VRU ITS-S 117 and non-VRU ITS-S 605. At step 2, the non-VRU ITS-S 605 performs TIPC. At step 3, the non-VRU ITS-S 605 performs CRA 816 (see e.g.,
Details for the procedure 600 shown in
Step 0: Acquisition and processing of local sensor data. The ego VRU ITS-S 117 relies on its sensory inputs for determining its parameters related to position, speed, direction, orientation, trajectory, velocity, etc. and starts the construction of the initial VAM message transmission for informing about itself among neighboring VRUs 116 and non-VRUs 605. Similar step applies to the neighboring VRUs 116/117 as well non-VRUs 605. Note that the non-VRUs 605 such as R-ITS-Ss 130 and V-ITS-Ss 110 may have additional advanced sensor capability (e.g., camera, LIDAR, Radar, etc.) based sensory outcomes for sharing. Furthermore, the collaboration among the non-VRUs 605 sharing such data can aid in analyzing the environment and enabling MCS even when VRUs 116 with no Tx/Rx capability are involved (e.g., small children, dogs, etc.)
Step 1: Initial VAM transmission from/to ego VRU for Collaborative Awareness. After step 0, the message format construction and actual message exchange among the ego VRU and neighboring VRUs 116 and/or non-VRUs 605 occurs in this step. The ego VRU 116/117 and other VRUs 116/117 transmit initial VAM messages inclusive of their VRU ID to share parameters such as position, heading, speed, trajectory, velocity, and other fields shown in the message construction in
Step 2: Computation of Trajectory Interception Probability of ego VRU with other VRUs and/or non-VRUs 605 or obstacles. Next, based the shared collaborative data incoming from other VRUs 116 as well as non-VRUs 605, the ego VRU ITS-Ss 117 invokes the collision risk analysis function for the assessment of potential collision risk especially in the emergency situation examples in Table 1. In this step, computation of TIP is performed and is used to provide details on how it plays a role in predicting the amount of uncertainty associated with the trajectory of the ego VRU and that of the neighboring VRU ITSs 117 and/or non-VRU ITS-Ss 605. Additionally, the trajectory interception probability covers for the situation when the ego VRU's 116/117 trajectory is going to intersect with an obstacle, object or suddenly appearing entities on the road. Quantification of such uncertainty in a probabilistic manner essentially helps in the dynamic motion prediction of the ego VRU and sharing of it with the neighboring VRU 116/117 or non-VRU ITS-Ss 605. The TIP computation details and how to leverage it for maneuver coordination triggering are elaborated in the next two sub-sections.
Trajectory Interception Probability (TIP) computation. One function of TIP is to reflect the dynamic motion state prediction of the VRU 116/117. The on-board sensors at the VRU 116/117 are responsible for estimating the dynamic motion state. For instance, the possible states that the VRU 116/117 may currently be in are as follows:
Once the dynamic motion state is estimated, the estimation is utilized to differentiate between gradual or abrupt changes in the trajectory of the VRU and even may be used to estimate the direction, heading, intention, and other similar motion features of the VRU. For instance, if there is constant high acceleration of a slow-moving VRU detected after changes in its movement, then there is a high probability that a VRU is accelerating. Similarly, a constant high deceleration could mean that there is an obstacle in the path of the VRU following which it may either come to a complete stop or change its trajectory with a maneuver to avoid the obstacle.
For dynamic motion prediction, the trajectory estimation including an upcoming abrupt trajectory change is one of the key functional features. For instance, let Pk be the current position at time k. Then, K past positions of the VRU expressed as a vector, Ptp={Pk−K,Pk−K+1, . . . , Pk} can be as observed trajectory reference input for predicting the trajectory of N future positions PtF={Pk+1, Pk+2, . . . , Pk+N} where each position Pi∀i∈{k−K, k−K+1, . . . , k, . . . , k+N} is a 2D global coordinate of the form Pi=(xi,yi). Then, based on time series representation (approximation) with knowledge of its absolute current position, speed, heading (direction), the next trajectory point can be predicted via Kalman Filtering (KF) or advanced KF such as Multi-Modal KF. Note the KF or Multi-Modal KF are good methods to estimate or predict the trajectory that is not changing drastically within a specified filtering window. However, for abrupt transition from one trajectory to another, the KF may need to be re-initialized after acquiring updated filter input parameters. Then, such trajectory estimation can be utilized along with the similar metric obtained from VAM message exchange with other VRUs 116 (or CAM/DENM message exchange with non-VRUs 605) to finally compute TIP for the VRU-ITS-S. The higher the value of TIP, the higher chances potential collision.
Step 4: Collision Risk Analysis. The TIP may then be combined with other available and relevant functional inputs including the VRU ITS-S ID and/or other non-VRU ITSs IDs available at the VBS following the earlier VAM (or DENM or CAM) message exchange to evaluate the collision risk analysis for classification of the collision risk level as either LOW or HIGH (or even more sophisticated multiple level classifications with finer granularity could be supported).
Step 5: Decision on Maneuvering Action for Collision Avoidance and MCC index assignment/update. If the collision risk level is not too high to trigger maneuvering action, the MCS state goes back to step 0 (see e.g.,
Step 6: Triggering MCS for Maneuvering Coordination Message Exchange. Following step 5, a joint maneuvering action may be necessary at all the involved ITS-Ss in the path of possible collision. Hence, the MCS is triggered at the ego VRU, neighboring VRUs 116 and non-VRUs 605 for exchanging the VAM including VRU IDs, MCC and TIP data fields for triggering potential maneuvering coordination actions at the involved ITS-Ss.
Step 7: Transmit (exchange) VAM TIP and MCC Data Fields. In this step, the VAMs with ID, TIP and MCC data field (or CAM/DENM or VAM-like message with MCC data field in case of non-VRUs 605) are exchanged among ego VRUs 116, other VRUs 116 and non-VRUs 605 in the neighboring areas for triggering coordinated maneuvering action between the respective ITS-Ss. Following this step, the ego VRU 116/117, other VRUs 116 and non-VRUs 605 may take a coordinated maneuvering action to avoid the potential collision in the current path or trajectory.
In order to support handshaking between VRU 116/117 and non-VRUs 605 during the message exchange process, the non-VRUs 605 may have to transmit DENM or CAM (or VAM-like) messages in response. Thus, the mechanisms and data fields may also be extended for DENM or CAM or VAM-like message transmissions as an additional field for supporting MCS in VRU sub-systems.
In various embodiments, the VAM message format structure includes a Trajectory Interception Probability (TIP) field that includes a probabilistic indicator of the estimation uncertainty of the ego VRU trajectory and its potential interception with any other object or people on the road ranging from other VRUs 116, non-VRUs 605, objects on the road, and other examples that were outlined in Table 3-1. Depending upon the analysis of the scene in terms of the sensory as well as shared inputs, different TIP ranges can be defined as in Table 3.3.1-1 to indicate the level of likelihood of the ego VRU's 116/117 path to be intercepted by something else thus leading to potential maneuvering (see e.g., Table 3.3.2-1). The TIP index, 2-bit construction of the TIP, is defined along with the range and the classification of levels/index for TIP in Table 3.3.1-1.
The TIP/TII 701 is used to indicate the likelihood that the VRU 116/117 and one or more other VRUs 116/117, non-VRUs 605, or even objects on the road are going to collide (see also clauses 6.5.10.6 and 6.5.10.9 of [TS103300-2]). The exchange of the TIP/TII 701 among the ego VRU 116/117 and neighboring ITS-Ss helps collision risk analysis and collision risk avoidance 817 by subsequently coordinated maneuvering. The details on how the TIP is computed is elaborated infra (see e.g., Table 3.3.1-1).
In embodiments, the message exchange mechanism for MCS includes a data field in the VAM structure called maneuver coordination context (MCC), which is generated locally based on the available sensor data at the ego VRU ITS-Ss 117. Additionally, the MCC is shared with neighboring ITS-Ss (which may be VRUs 116 or non-VRUs 605) in its vicinity so that it can be augmented with additional data coming from other ITS-Ss in the vicinity. In some embodiments, the VAM including the MCC data field is may be sent in a periodic manner to broadcast an awareness of the VRU environment and context to the neighboring ITS-Ss. In other embodiments, the VAM including the MCC data field is may be sent in an event triggered manner due to appearance of potential emergency situations (as described in Table 3-1).
The protocol and message exchange mechanisms for enabling MCS are discussed infra. In some embodiments, for designation of the MCC, TIP computation based on the sensory inputs serves as one of the triggers for classification of various MCC levels.
In various embodiments, the TIP field is extended to include user specific indication of the TIP. This embodiment serves the cases where the ego VRU may want to indicate to specific users (VRUs or non-VRUs 605) the likelihood of interception of their respective trajectories thus enabling more accurate users-specific collision risk analysis. Such user specific indication of the trajectory interception likelihood would reduce the false alarm that can be caused due to a generic TIP indication that is intended to all ITS-Ss in the vicinity of the ego VRU rather than a specific user. Additionally, the user specific TIP indication is be more relevant for enabling maneuver coordination for collision avoidance among a specific group of users identified to have a high collision risk. An example extended TIP field 701 is shown in
Note that the number of possible IDs of the intercepting users is determined by how many users are in the vicinity of the ego VRU, which primarily depends upon the typical transmission range of the VRU profile as well as the deployment scenario, topology and others. For VRU Profile 1 such as pedestrians, the maximum transmission range is 50m for urban and suburban while it is 250m for rural (if capable). Furthermore, the maximum number of users within the coverage area can be up to 50 per cluster (see e.g., [TS103300-2]). However, the embodiments herein are not limited by the number of users and can be extended to any number of users as permitted by the availability of the radio resources.
Table 3.5-1 shows an example VAM extended to include MCS-related data fields (DFs) and data elements (DEs), which may be used in the VRU MCS embodiments discussed previously. The two additional DFs include the Trajectory Interception Probability (TIP) and Maneuver Coordination Context (MCC) are defined for maneuver coordination between an ego VRU ITS-S 117, other VRU ITS-Ss 117, and non-VRU ITS-Ss 117 such as V-ITS-Ss 110 and R-ITS-Ss 130. The example MCS-VAM of Table 3.5-1 is structured in the message formats according to [SAEJ2735].
The applications layer 801 provides ITS services, and ITS applications are defined within the application layer 801. An ITS application is an application layer entity that implements logic for fulfilling one or more ITS use cases. An ITS application makes use of the underlying facilities and communication capacities provided by the ITS-S. Each application can be assigned to one of the three identified application classes: road safety, traffic efficiency, and other applications (see e.g., [EN302663]), ETSI TR 102 638 V1.1.1 (2009 June) (hereinafter “[TR102638]”)). Examples of
ITS applications may include driving assistance applications (e.g., for cooperative awareness and road hazard warnings) including AEB, EMA, and FCW applications, speed management applications, mapping and/or navigation applications (e.g., turn-by-turn navigation and cooperative navigation), applications providing location based services, and applications providing networking services (e.g., global Internet services and ITS-S lifecycle management services). A V-ITS-S 110 provides ITS applications to vehicle drivers and/or passengers, and may require an interface for accessing in-vehicle data from the in-vehicle network or in-vehicle system. For deployment and performances needs, specific instances of a V-ITS-S 110 may contain groupings of Applications and/or Facilities.
The facilities layer 802 comprises middleware, software connectors, software glue, or the like, comprising multiple facility layer functions (or simply a “facilities”). In particular, the facilities layer contains functionality 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., inter-host communication). A facility is a component that provides functions, information, and/or services to the applications in the application layer and exchanges data with lower layers for communicating that data with other ITS-Ss. Example facilities include Cooperative Awareness Services, Collective Perception Services, Device Data Provider (DDP), Position and Time management (POTI), Local Dynamic Map (LDM), collaborative awareness basic service (CABS) and/or cooperative awareness basic service (CABS), signal phase and timing service (SPATS), vulnerable road user basic service (VBS), Decentralized Environmental Notification (DEN) basic service, maneuver coordination services (MCS), and/or the like. For a vehicle ITS-S, the DDP is connected with the in-vehicle network and provides the vehicle state information. The POTI entity provides the position of the ITS-S and time information. A list of the common facilities is given by ETSI TS 102 894-1 V1.1.1 (2013 August) (hereinafter “[TS102894-1]”).
Each of the aforementioned interfaces/Service Access Points (SAPs) may provide the full duplex exchange of data with the facilities layer, and may implement suitable APIs to enable communication between the various entities/elements.
For a vehicle ITS-S, the facilities layer 802 is connected to an in-vehicle network via an in-vehicle data gateway as shown and described in [TS102894-1]. The facilities and applications of a vehicle ITS-S receive required in-vehicle data from the data gateway in order to construct messages (e.g., CSMs, VAMs, CAMs, DENMs, MCMs, and/or CPMs) and for application usage. For sending and receiving CAMs, the CA-BS includes the following entities: an encode CAM entity, a decode CAM entity, a CAM transmission management entity, and a CAM reception management entity. For sending and receiving DENMs, the DEN-BS includes the following entities: an encode DENM entity, a decode DENM entity, a DENM transmission management entity, a DENM reception management entity, and a DENM keep-alive forwarding (KAF) entity. The CAM/DENM transmission management entity implements the protocol operation of the originating ITS-S including activation and termination of CAM/DENM transmission operation, determining CAM/DENM generation frequency, and triggering generation of CAMs/DENMs. The CAM/DENM reception management entity implements the protocol operation of the receiving ITS-S including triggering the decode CAM/DENM entity at the reception of CAMs/DENMs, provisioning received CAM/DENM data to the LDM, facilities, or applications of the receiving ITS-S, discarding invalid CAMs/DENMs, and checking the information of received CAMs/DENMs. The DENM KAF entity KAF stores a received DENM during its validity duration and forwards the DENM when applicable; the usage conditions of the DENM KAF may either be defined by ITS application requirements or by a cross-layer functionality of an ITSC management entity 806. The encode CAM/DENM entity constructs (encodes) CAMs/DENMs to include various, the object list may include a list of DEs and/or DFs included in an ITS data dictionary.
The ITS station type/capabilities facility provides information to describe a profile of an ITS-S to be used in the applications and facilities layers. This profile indicates the ITS-S type (e.g., vehicle ITS-S, road side ITS-S, personal ITS-S, or central ITS-S), a role of the ITS-S, and detection capabilities and status (e.g., the ITS-S's positioning capabilities, sensing capabilities, etc.). The station type/capabilities facility may store sensor capabilities of various connected/coupled sensors and sensor data obtained from such sensors.
The Position and Time management entity (PoTi) 822 manages the position and time information for use by ITS applications, facility, network, management, and security layers. For this purpose, the PoTi 822 gets information from sub-system entities such as GNSS, sensors and other subsystem of the ITS-S. The PoTi 822 ensures ITS time synchronicity between ITS-Ss in an ITS constellation, maintains the data quality (e.g., by monitoring time deviation), and manages updates of the position (e.g., kinematic and attitude state) and time. An ITS constellation is a group of ITS-S's that are exchanging ITS data among themselves. The PoTi entity 822 may include augmentation services to improve the position and time accuracy, integrity, and reliability. Among these methods, communication technologies may be used to provide positioning assistance from mobile to mobile ITS-Ss and infrastructure to mobile ITS-Ss. Given the ITS application requirements in terms of position and time accuracy, PoTi 822 may use augmentation services to improve the position and time accuracy. Various augmentation methods may be applied. PoTi 822 may support these augmentation services by providing messages services broadcasting augmentation data. For instance, a roadside ITS-S may broadcast correction information for GNSS to oncoming vehicle ITS-S; ITS-Ss may exchange raw GPS data or may exchange terrestrial radio position and time relevant information. PoTi 822 maintains and provides the position and time reference information according to the application and facility and other layer service requirements in the ITS-S. In the context of ITS, the “position” includes attitude and movement parameters including velocity, heading, horizontal speed and optionally others. The kinematic and attitude state of a rigid body contained in the ITS-S included position, velocity, acceleration, orientation, angular velocity, and possible other motion related information. The position information at a specific moment in time is referred to as the kinematic and attitude state including time, of the rigid body. In addition to the kinematic and attitude state, PoTi 822 should also maintain information on the confidence of the kinematic and attitude state variables.
The VBS 821 is also linked with other entities such as application support facilities including, for example, the collaborative/cooperative awareness basic service (CABS), signal phase and timing service (SPATS), Decentralized Environmental Notification (DEN) service, Collective Perception Service (CPS), Maneuver Coordination Service (MCS), Infrastructure service 812, etc. The VBS 821 is responsible for transmitting the VAMs, identifying whether the VRU is part of a cluster, and enabling the assessment of a potential risk of collision. The VBS 821 may also interact with a VRU profile management entity in the management layer to VRU-related purposes.
The VBS 821 interfaces through the Network—Transport/Facilities (NF)-Service Access Point (SAP) with the N&T for exchanging of CPMs with other ITS-Ss. The VBS 821 interfaces through the Security-Facilities (SF)-SAP with the Security entity to access security services for VAM transmission and VAM reception 903. The VBS 821 interfaces through the Management-Facilities (MF)-SAP with the Management entity and through the Facilities-Application (FA)-SAP with the application layer if received VAM data is provided directly to the applications. Each of the aforementioned interfaces/SAPs may provide the full duplex exchange of data with the facilities layer, and may implement suitable APIs to enable communication between the various entities/elements.
In some embodiments, the embodiments discussed herein may be implemented in or by the VBS 821. In particular, the VBS module/entity 821 may reside or operate in the facilities layer, generates VAMs, checks related services/messages to coordinate transmission of VAMs in conjunction with other ITS service messages generated by other facilities and/or other entities within the ITS-S, which are then passed to the N&T and access layers for transmission to other proximate ITS-Ss. In embodiments, the VAMs are included in ITS packets, which are facilities layer PDUs that may be passed to the access layer via the N&T layer or passed to the application layer for consumption by one or more ITS applications. In this way, VAM format is agnostic to the underlying access layer and is designed to allow VAMs to be shared regardless of the underlying access technology/RAT.
The application layer recommends a possible distribution of functional entities that would be involved in the protection of VRUs 116, based on the analysis of VRU use cases. The application layer also includes device role setting function/application (app) 811, infrastructure services function/app 812, maneuver coordination function/app 813, cooperative perception function/app 814, remote sensor data fusion function/app 815, collision risk analysis (CRA) function/app 816, collision risk avoidance function/app 817, and event detection function/app 818.
The device role setting module 811 takes the configuration parameter settings and user preference settings and enables/disables different VRU profiles depending on the parameter settings, user preference settings, and/or other data (e.g., sensor data and the like). A VRU can be equipped with a portable device which needs to be initially configured and may evolve during its operation following context changes which need to be specified. This is particularly true for the setting-up of the VRU profile and type which can be achieved automatically at power on or via an HMI. The change of the road user vulnerability state needs to be also provided either to activate the VBS 821 when the road user becomes vulnerable or to de-activate it when entering a protected area. The initial configuration can be set-up automatically when the device is powered up. This can be the case for the VRU equipment type which may be: VRU-Tx (a VRU only with the communication capability to broadcast messages complying with the channel congestion control rules); VRU-Rx (a VRU only communication capability to receive messages); and VRU-St (a VRU with full duplex (Tx and Rx) communication capabilities). During operation the VRU profile may also change due to some clustering or de-assembly. Consequently, the VRU device role will be able to evolve according to the VRU profile changes
The infrastructure services module 812 is responsible for launching new VRU instantiations, collecting usage data, and/or consuming services from infrastructure stations. Existing infrastructure services 812 such as those described below can be used in the context of the VBS 821:
The broadcast of the SPAT (Signal Phase And Timing) & MAP (SPAT relevance delimited area) is already standardized and used by vehicles at intersection level. In principle they protect VRUs 116 crossing. However, signal violation warnings may exist and can be detected and signaled using DENM. This signal violation indication using DENMs is very relevant to VRU devices as indicating an increase of the collision risk with the vehicle which violates the signal. If it uses local captors or detects and analyses VAMs, the traffic light controller may delay the red phase change to green and allow the VRU to safely terminate its road crossing.
The contextual speed limit using IVI (In Vehicle Information) can be adapted when a large cluster of VRUs 116 is detected (ex: limiting the vehicles' speed to 30 km/hour). At such reduced speed a vehicle may act efficiently when perceiving the VRUs 116 by means of its own local perception system
Remote sensor data fusion and actuator applications/functions 815 (including ML/AI) is also included in some implementations. The local perception data obtained by the computation of data collected by local sensors may be augmented by remote data collected by elements of the VRU system (e.g., V-ITS-Ss 110, R-ITS-Ss 130) via the ITS-S. These remote data are transferred using standard services such as the CPS and/or the like. In such case it may be necessary to fuse these data. In some implementations, the data fusion may provide at least three possible results: (i) After a data consistency check, the received remote data are not coherent with the local data, wherein the system element has to decide which source of data can be trusted and ignore the other; (ii) only one input is available (e.g., the remote data) which means that the other source does not have the possibility to provide information, wherein the system element may trust the only available source; and (iii) after a data consistency check, the two sources are providing coherent data which augment the individual inputs provided. The use of ML/AI may be necessary to recognize and classify the detected objects (e.g., VRU, motorcycle, type of vehicle, etc.) but also their associated dynamics. The AI can be located in any element of the VRU system. The same approach is applicable to actuators, but in this case, the actuators are the destination of the data fusion.
Collective perception (CP) involves ITS-Ss sharing information about their current environments with one another. An ITS-S participating in CP broadcasts information about its current (e.g., driving) environment rather than about itself. For this purpose, CP involves different ITS-Ss actively exchanging locally perceived objects (e.g., other road participants and VRUs 116, obstacles, and the like) detected by local perception sensors by means of one or more V2X RATs. In some implementations, CP includes a perception chain that can be the fusion of results of several perception functions at predefined times. These perception functions may include local perception and remote perception functions
The local perception is provided by the collection of information from the environment of the considered ITS element (e.g., VRU device, vehicle, infrastructure, etc.). This information collection is achieved using relevant sensors (optical camera, thermal camera, radar, LIDAR, etc.). The remote perception is provided by the provision of perception data via C-ITS (mainly V2X communication). Existing basic services like the Cooperative Awareness (CA) or more recent services such as the Collective Perception Service (CPS) can be used to transfer a remote perception.
Several perception sources may then be used to achieve the cooperative perception function 814. The consistency of these sources may be verified at predefined instants, and if not consistent, the CP function may select the best one according to the confidence level associated with each perception variable. The result of the CP should comply with the required level of accuracy as specified by PoTi. The associated confidence level may be necessary to build the CP resulting from the fusion in case of differences between the local perception and the remote perception. It may also be necessary for the exploitation by other functions (e.g., risk analysis) of the CP result.
The perception functions from the device local sensors processing to the end result at the cooperative perception 814 level may present a significant latency time of several hundred milliseconds. For the characterization of a VRU trajectory and its velocity evolution, there is a need for a certain number of the vehicle position measurements and velocity measurements thus increasing the overall latency time of the perception. Consequently, it is necessary to estimate the overall latency time of this function to take it into account when selecting a collision avoidance strategy.
The CRA function 816 analyses the motion dynamic prediction of the considered moving objects associated to their respective levels of confidence (reliability). An objective is to estimate the likelihood of a collision and then to identify as precisely as possible the Time To Collision (TTC) if the resulting likelihood is high. Other variables may be used to compute this estimation.
In embodiments, the VRU CRA function 816, and dynamic state prediction are able to reliably predict the relevant road users maneuvers with an acceptable level of confidence for the purpose of triggering the appropriate collision avoidance action, assuming that the input data is of sufficient quality. The CRA function 816 analyses the level of collision risk based on a reliable prediction of the respective dynamic state evolution. Consequently, the reliability level aspect may be characterized in terms of confidence level for the chosen collision risk metrics as discussed in clauses 6.5.10.5 and 6.5.10.9 of [TS103300-2]. The confidence of a VRU dynamic state prediction is computed for the purpose of risk analysis. The prediction of the dynamic state of the VRU is complicated especially for some specific VRU profiles (e.g., animal, child, disabled person, etc.). Therefore, a confidence level may be associated to this prediction as explained in clauses 6.5.10.5, 6.5.10.6 and 6.5.10.9 of [TS103300-2]. The VRU movement reliable prediction is used to trigger the broadcasting of relevant VAMs when a risk of collision involving a VRU is detected with sufficient confidence to avoid false positive alerts (see e.g., clauses 6.5.10.5, 6.5.10.6 and 6.5.10.9 of [TS103300-2]).
The following two conditions are used to calculate the TTC. First, two or more considered moving objects follow trajectories which intersect somewhere at a position which can be called “potential conflict point”. Second, if the moving objects maintain their motion dynamics (e.g., approaches, trajectories, speeds, etc.) it is possible to predict that they will collide at a given time which can be estimated through the computation of the time (referred to as Time To Collision (TTC)) necessary for them to arrive simultaneously at the level of the identified potential conflict point. The TTC is a calculated data element enabling the selection of the nature and urgency of a collision avoidance action to be undertaken.
A TTC prediction may only be reliably established when the VRU 116 enters a collision risk area. This is due to the uncertainty nature of the VRU pedestrian motion dynamic (mainly its trajectory) before deciding to cross the road.
At the potential conflict point level, another measurement, the ‘time difference for pedestrian and vehicle travelling to the potential conflict point’ (TDTC) can be used to estimate the collision risk level. For example, if it is not acted on the motion dynamic of the pedestrian or/and on the motion dynamic of the vehicle, TDTC is equal to 0 and the collision is certain. Increasing the TDTC reduces the risk of collision between the VRU and the vehicle. The potential conflict point is in the middle of the collision risk area which can be defined according to the lane width (e.g., 3.5 m) and vehicle width (maximum 2 m for passenger cars).
The TTC is one of the variables that can be used to define a collision avoidance strategy and the operational collision avoidance actions to be undertaken. Other variables may be considered such as the road state, the weather conditions, the triple of {Longitudinal Distance (LoD), Lateral Distance (LaD), Vertical Distance (VD)} along with the corresponding threshold triple of {MSLaD, MSLoD, MSVD}, Trajectory Interception Indicator (TII), and the mobile objects capabilities to react to a collision risk and avoid a collision (see e.g., clause 6.5.10.9 in [TS103300-2]). The TII is an indicator of the likelihood that the VRU 116 and one or more other VRUs 116, non-VRUs 605, or even objects on the road are going to collide.
The CRA function 816 compares LaD, LoD and VD, with their respective predefined thresholds, MSLaD, MSLoD, MSVD, respectively, if all the three metrics are simultaneously less than their respective thresholds, that is LaD <MSLaD, LoD <MSLoD, VD<MSVD, then the collision avoidance actions would be initiated. Those thresholds could be set and updated periodically or dynamically depending on the speed, acceleration, type, and loading of the vehicles and VRUs 116, and environment and weather conditions. On the other hand, the TII reflects how likely is the ego-VRU ITS-S 117 trajectory going to be intercepted by the neighboring ITSs (other VRUs 116 and/or non-VRU ITSs such as vehicles 110).
The likelihood of a collision associated with the TTC may also be used as a triggering condition for the broadcast of messages (e.g., an infrastructure element getting a complete perception of the situation may broadcast DENM, IVI (contextual speed limit), CPM or MCM).
The collision risk avoidance function/application 817 includes the collision avoidance strategy to be selected according to the TTC value. In the case of autonomous vehicles 110, the collision risk avoidance function 817 may involve the identification of maneuver coordination 813/vehicle motion control 1108 to achieve the collision avoidance as per the likelihood of VRU trajectory interception with other road users captured by TII and Maneuver Identifier (MI) as discussed infra.
The collision avoidance strategy may consider several environmental conditions such as visibility conditions related to the local weather, vehicle stability conditions related to the road state (e.g., slippery), and vehicle braking capabilities. The vehicle collision avoidance strategy then needs to consider the action capabilities of the VRU according to its profile, the remaining TTC, the road and weather conditions as well as the vehicle autonomous action capabilities. The collision avoidance actions may be implemented using maneuver coordination 813 (and related maneuver coordination message (MCM) exchange) as done in the French PAC V2X project or other like systems.
In one example, when in good conditions, it is possible to trigger a collision avoidance action when the TTC is greater than two seconds (one second for the driver reaction time and one second to achieve the collision avoidance action). Below two seconds, the vehicle can be considered to be in a “pre-crash” situation and so it needs to trigger a mitigation action to reduce the severity of the collision impact for the VRU 116/117. The possible collision avoidance actions and impact mitigation actions have been listed in requirement FSYS08 in clause 5 of [TS103300-2].
Road infrastructure elements (e.g., R-ITS-Ss 130) may also include a CRA function 816 as well as a collision risk avoidance function 817. In these embodiments, these functions may indicate collision avoidance actions to the neighboring VRUs 116/117 and vehicles 110.
The collision avoidance actions (e.g., using MCM as done in the French PAC V2X project) for VRUs, V-ITS-Ss, and/or R-ITS-Ss may depend on the vehicle level of automation. The collision avoidance action or impact mitigation action are triggered as a warning/alert to the driver or as a direct action on the vehicle 110 itself. Examples of collision avoidance include any combination of: extending or changing the phase of a traffic light; acting on the trajectory and/or velocity of the vehicles 110 (e.g., slow down, change lane, etc.) if the vehicle 110 has a sufficient level of automation; alert the ITS device user through the HMI; disseminate a C-ITS message to other road users, including the VRU 116/117 if relevant. Examples of impact mitigation actions may include any combination of triggering a protective mean at the vehicle level (e.g., extended external airbag); triggering a portable VRU protection airbag.
The road infrastructure may offer services to support the road crossing by VRU such as traffic lights. When a VRU starts crossing a road at a traffic light level authorizing him, the traffic light should not change of phase as long as the VRU has not completed its crossing. Accordingly, the VAM should contain data elements enabling the traffic light to determine the end of the road crossing by the VRU 116/117.
The maneuver coordination function 813 executes the collision avoidance actions which are associated with the collision avoidance strategy that has been decided (and selected). The collision avoidance actions are triggered at the level of the VRU 116/117, the vehicle 110, or both, depending on the VRU capabilities to act (e.g., VRU profile and type), the vehicle type and capabilities and the actual risk of collision. VRUs 116/117 do not always have the capability to act to avoid a collision (e.g., animal, children, aging person, disabled, etc.), especially if the TTC is short (a few seconds) (see e.g., clauses 6.5.10.5 and 6.5.10.6 of [TS103300-2]. This function should be present at the vehicle 110 level, depending also on the vehicle 110 level of automation (e.g., not present in non-automated vehicles), and may be present at the VRU device 117 level according to the VRU profile. At the vehicle 110 level, this function interfaces the vehicle electronics controlling the vehicle dynamic state in terms of heading and velocity. At the VRU device 117 level, this function may interface the HMI support function, according to the VRU profile, to be able to issue a warning or alert to the VRU 116/117 according to the TTC.
Maneuver coordination 813 can be proposed to vehicles from an infrastructure element, which may be able to obtain a better perception of the motion dynamics of the involved moving objects, by means of its own sensors or by the fusion of their data with the remote perception obtained from standard messages such as CAMs.
The maneuver coordination 813 at the VRU 116 may be enabled by sharing among the ego-VRU and the neighboring ITSs, first the TII reflecting how likely is the ego VRU ITS-Ss 117 trajectory going to be intercepted by the neighboring ITSs (other VRU or non-VRU ITSs such as vehicles), and second a Maneuver Identifier (MI) to indicate the type of VRU maneuvering needed. An MI is an identifier of a maneuver (to be) used in a maneuver coordination service (MCS) 813. The choice of maneuver may be generated locally based on the available sensor data at the VRU ITS-S 117 and may be shared with neighboring ITS-S(e.g., other VRUs 116 and/or non-VRUs 605) in the vicinity of the ego VRU ITS-S 117 to initiate a joint maneuver coordination among VRUs 116 (see e.g., clause 6.5.10.9 of [TS103300-3]).
Depending upon the analysis of the scene in terms of the sensory as well as shared inputs, simple TII ranges can be defined to indicate the likelihood of the ego-VRU's 116 path to be intercepted by another entity. Such indication helps to trigger timely maneuvering. For instance, TII could be defined in terms of TII index that may simply indicate the chances of potential trajectory interception (low, medium, high or very high) for CRA 816. If there are multiple other entities, the TII may be indicated for the specific entity differentiable via a simple ID which depends upon the simultaneous number of entities in the vicinity at that time. The vicinity could even be just one cluster that the current VRU is located in. For example, the minimum number of entities or users in a cluster is 50 per cluster (worst case). However, the set of users that may have the potential to collide with the VRU could be much less than 50 thus possible to indicate via few bits in say, VAM.
On the other hand, the MI parameter can be helpful in collision risk avoidance 817 by triggering/suggesting the type of maneuver action needed at the VRUs 116/117. The number of such possible maneuver actions may be only a few. For simplicity, it could also define as the possible actions to choose from as {longitudinal trajectory change maneuvering, lateral trajectory change maneuvering, heading change maneuvering or emergency braking/deceleration} in order to avoid potential collision indicated by the TII. In various embodiments, the TII and MI parameters can also be exchanged via inclusion in part of a VAM DF structure.
The event detection function 818 assists the VBS 821 during its operation when transitioning from one state to another. Examples of the events to be considered include: change of a VRU role when a road user becomes vulnerable (activation) or when a road user is not any more vulnerable (de-activation); change of a VRU profile when a VRU enters a cluster with other VRU(s) or with a new mechanical element (e.g., bicycle, scooter, moto, etc.), or when a VRU cluster is disassembling; risk of collision between one or several VRU(s) and at least one other VRU (using a VRU vehicle) or a vehicle (such event is detected via the perception capabilities of the VRU system); change of the VRU motion dynamic (trajectory or velocity) which will impact the TTC and the reliability of the previous prediction; and change of the status of a road infrastructure piece of equipment (e.g., a traffic light phase) impacting the VRU movements.
Additionally or alternatively, existing infrastructure services 812 such as those described herein can be used in the context of the VBS 821. For example, the broadcast of the Signal Phase And Timing (SPAT) and SPAT relevance delimited area (MAP) is already standardized and used by vehicles at intersection level. In principle they protect VRUs 116/117 crossing. However, signal violation warnings may exist and can be detected and signaled using DENM. This signal violation indication using DENMs is very relevant to VRU devices 117 as indicating an increase of the collision risk with the vehicle which violates the signal. If it uses local captors or detects and analyses VAMs, the traffic light controller may delay the red phase change to green and allow the VRU 116/117 to safely terminate its road crossing. The contextual speed limit using In-Vehicle Information (IVI) can be adapted when a large cluster of VRUs 116/117 is detected (e.g., limiting the vehicles' speed to 30 km/hour). At such reduced speed a vehicle 110 may act efficiently when perceiving the VRUs by means of its own local perception system.
The ITS management (mgmnt) layer includes a VRU profile mgmnt entity. The VRU profile management function is an important support element for the VBS 821 as managing the VRU profile during a VRU active session. The profile management is part of the ITS-S configuration management and is then initialized with necessary typical parameters' values to be able to fulfil its operation. The ITS-S configuration management is also responsible for updates (for example: new standard versions) which are necessary during the whole life cycle of the system.
When the VBS 821 is activated (vulnerability configured), the VRU profile management needs to characterize a VRU personalized profile based on its experience and on provided initial configuration (generic VRU type). The VRU profile management may then continue to learn about the VRU habits and behaviors with the objective to increase the level of confidence (reliability) being associated to its motion dynamic (trajectories and velocities) and to its evolution predictions.
The VRU profile management 861 is able to adapt the VRU profile according to detected events which can be signaled by the VBS management and the VRU cluster management 902 (cluster building/formation or cluster disassembly/disbandenment).
According to its profile, a VRU may or may not be impacted by some road infrastructure event (e.g., evolution of a traffic light phase), so enabling a better estimation of the confidence level to be associated to its movements. For example, an adult pedestrian will likely wait at a green traffic light and then cross the road when the traffic light turns to red. An animal will not take care of the traffic light color and a child can wait or not according to its age and level of education.
Handling VRU role: The VBS 821 receives unsolicited indications from the VRU profile management entity (see e.g., clause 6.4 in [TS103300-2]) on whether the device user is in a context where it is considered as a VRU (e.g., pedestrian crossing a road) or not (e.g., passenger in a bus). The VBS 821 remains operational in both states, as defined by Table 4-1.
There may be cases where the VRU profile management entity provides invalid information, e.g., the VRU device user is considered as a VRU, while its role should be VRU_ROLE_OFF. This is implementation dependent, as the receiving ITS-S should have very strong plausibility check and take into account the VRU context during their risk analysis. The precision of the positioning system (both at transmitting and receiving side) would also have a strong impact on the detection of such cases
Sending VAMs includes two activities: generation of VAMs and transmission of VAMs. In VAM generation, the originating ITS-S 117 composes the VAM, which is then delivered to the ITS networking and transport layer for dissemination. In VAM transmission, the VAM is transmitted over one or more communications media using one or more transport and networking protocols. A natural model is for VAMs to be sent by the originating ITS-S to all ITS-Ss within the direct communication range. VAMs are generated at a frequency determined by the controlling VBS 821 in the originating ITS-S. If a VRU ITS-S is not in a cluster, or is the leader of a cluster, it transmits the VAM periodically. VRU ITS-S 117 that are in a cluster, but not the leader of a cluster, do not transmit the VAM. The generation frequency is determined based on the change of kinematic state, location of the VRU ITS-S 117, and congestion in the radio channel. Security measures such as authentication are applied to the VAM during the transmission process in coordination with the security entity.
Upon receiving a VAM, the VBS 821 makes the content of the VAM available to the ITS applications and/or to other facilities within the receiving ITS-S 117/130/110, such as a Local Dynamic Map (LDM). It applies all necessary security measures such as relevance or message integrity check in coordination with the security entity.
The VBS 821 includes a VBS management function 901, a VRU cluster management function 902, a VAM reception management function 903, a VAM transmission management function 904, VAM encoding function 905, and VAM decoding function 906. The presence of some or all of these functions depends on the VRU equipment type (e.g., VRU-Tx, VRU-Rx, or VRU-St), and may vary from embodiment to embodiment.
The VBS management function 901 executes the following operations: store the assigned ITS AID and the assigned Network Port to use for the VBS 821; store the VRU configuration received at initialization time or updated later for the coding of VAM data elements; receive information from and transmit information to the HMI; activate/deactivate the VAM transmission service 904 according to the device role parameter (for example, the service is deactivated when a pedestrian enters a bus); and manage the triggering conditions of VAM transmission 904 in relation to the network congestion control. For example, after activation of a new cluster, it may be decided to stop the transmission of element(s) of the cluster.
The VRU cluster management function 902 performs the following operations: detect if the associated VRU can be the leader of a cluster; compute and store the cluster parameters at activation time for the coding of VAM data elements specific to the cluster; manage the state machine associated to the VRU according to detected cluster events (see e.g., state machines examples provided in section 6.2.4 of [TS103300-2]); and activate or de-activate the broadcasting of the VAMs or other standard messages (e.g., DENMs) according to the state and types of associated VRU.
The clustering operation as part of the VBS 821 is intended to optimize the resource usage in the ITS system. These resources are mainly spectrum resources and processing resources.
A huge number of VRUs in a certain area (pedestrian crossing in urban environment, large squares in urban environment, special events like large pedestrian gatherings) would lead to a significant number of individual messages sent out by the VRU ITS-S and thus a significant need for spectrum resources. Additionally, all these messages would need to be processed by the receiving ITS-S, potentially including overhead for security operations.
In order to reduce this resource usage, the present document specifies clustering functionality. A VRU cluster is a group of VRUs with a homogeneous behavior (see ETSI TS 103 300-2 [1]), where VAMs related to the VRU cluster provide information about the entire cluster. Within a VRU cluster, VRU devices take the role of either leader (one per cluster) or member. A leader device sends VAMs containing cluster information and/or cluster operations. Member devices send VAMs containing cluster operation container to join/leave the VRU cluster. Member devices do not send VAMs containing cluster information container at any time.
A cluster may contain VRU devices of multiple profiles. A cluster is referred to as “homogeneous” if it contains devices of only one profile, and “heterogeneous” if it contains VRU devices of more than one profile (e.g., a mixed group of pedestrians and bicyclists). The VAM ClusterInformationContainer contains a field allowing the cluster container to indicate which VRU profiles are present in the cluster. Indicating heterogeneous clusters is important since it provides useful information about trajectory and behaviors prediction when the cluster is broken up.
The support of the clustering function is optional in the VBS 821 for all VRU profiles. The decision to support the clustering or not is implementation dependent for all the VRU profiles. When the conditions are satisfied (see clause 5.4.2.4 of [TS103300-3]), the support of clustering is recommended for VRU profile 1. An implementation that supports clustering may also allow the device owner to activate it or not by configuration. This configuration is also implementation dependent. If the clustering function is supported and activated in the VRU device, and only in this case, the VRU ITS-S shall comply with the requirements specified in clause 5.4.2 and clause 7 of [TS103300-3], and define the parameters specified in clause 5.4.3 of [TS103300-3]. As a consequence, cluster parameters are grouped in two specific and conditional mandatory containers in the present document.
The basic operations to be performed as part of the VRU cluster management 902 in the VBS 821 are: Cluster identification: intra-cluster identification by cluster participants in Ad-Hoc mode; Cluster creation: creation of a cluster of VRUs including VRU devices located nearby and with similar intended directions and speeds. The details of the cluster creation operation are given in clause 5.4.2.2 of [TS103300-3]; Cluster breaking up: disbanding of the cluster when it no longer participates in the safety related traffic or the cardinality drops below a given threshold; Cluster joining and leaving: intro-cluster operation, adding or deleting an individual member to an existing cluster; Cluster extension or shrinking: operation to increase or decrease the size (area or cardinality).
Any VRU device shall lead a maximum of one cluster. Accordingly, a cluster leader shall break up its cluster before starting to join another cluster. This requirement also applies to combined VRUs as defined in [TS103300-2] joining a different cluster (e.g., while passing a pedestrian crossing). The combined VRU may then be re-created after leaving the heterogeneous cluster as needed. For example, if a bicyclist with a VRU device, currently in a combined cluster with his bicycle which also has a VRU device, detects it could join a larger cluster, then the leader of the combined VRU breaks up the cluster and both devices each join the larger cluster separately. The possibility to include or merge VRU clusters or combined VRUs inside a VRU cluster is left for further study. In some implementations, a simple in-band VAM signaling may be used for the operation of VRU clustering. Further methods may be defined to establish, maintain and tear up the association between devices (e.g., Bluetooth®, UWB, etc.).
VRU Cluster operation. Depending on its context, the VBS 821 is in one of the cluster states specified in Table 4-5.
In addition to the normal VAM triggering conditions defined in clause 6 of [TS103300-3], the following events trigger a VBS state transition related to cluster operation. Parameters that control these events are summarized in clause 8 of [TS103300-3], Table 1.3-23, and Table 1.3-24.
Entering VRU role: VRU-IDLE. When the VBS 821 in VRU-IDLE determines that the VRU device user has changed its role to VRU ROLE ON (e.g., by exiting a bus), it shall start the transmission of VAMs, as defined in clause 4.2. A VBS 821 executing this transition shall not belong to any cluster. Next state: VRU-ACTIVE-STANDALONE
Leaving VRU role: VRU-ACTIVE-STANDALONE. When the VBS 821 in VRU-ACTIVE-STANDALONE determines that the VRU device user has changed its role to VRU_ROLE_OFF (e.g., by entering a bus or a passenger car), it shall stop the transmission of VAMs, as defined in clause 4.2 of [TS103300-3]. A VBS 821 executing this transition shall not belong to any cluster. Next state: VRU-IDLE.
Creating a VRU cluster Initial state: VRU-ACTIVE STANDALONE. When the VBS 821 in VRU-ACTIVE-STANDALONE determines that it can form a cluster based on the received VAMs from other VRUs (see conditions in clause 5.4.2.4 of [TS103300-3]), it takes the following actions: 1) Generate a random cluster identifier. The identifier shall be locally unique, i.e. it shall be different from any cluster identifier in a VAM received by the VBS 821 in the last timeClusterUniquenessThreshold time, and it shall be non-zero. The identifier does not need to be globally unique, as a cluster is a local entity and can be expected to live for a short time frame. 2) Determine an initial cluster dimension to delimit the cluster bounding box. To avoid false positives, the initial bounding box shall be set to include only the cluster leader VRU. 3) Set the size of the cluster to minClusterSize and the VRU cluster profiles field to its own VRU profile. 4) Transition to the next state, i.e. start transmitting cluster VAMs. The random selection of the cluster ID protects against the case where two cluster leaders, which select an ID simultaneously, select the same identifier. Cluster creation is different from cluster joining as defined in clause 5.4.2.4 of [TS103300-3] in that a VRU device joining a cluster gives an indication that it will join the cluster beforehand, while a VRU device creating a cluster simply switches from sending individual VAMs to sending cluster VAMs. Next state: VRU-ACTIVE-CLUSTER-LEADER
Breaking up a VRU cluster: Initial state: VRU-ACTIVE-CLUSTER-LEADER. When the VBS 821 in VRU-ACTIVE-CLUSTER-LEADER determines that it should break up the cluster, it shall include in the cluster VAMs a VRU cluster operation field indicating that it will disband the cluster with the VRU cluster's identifier and a reason to break up the VRU cluster (see clause 7.3.5 for the list of possible reasons). It shall then shortly stop sending cluster VAMs. This indication is transmitted for timeClusterBreakupWarning in consecutive VAMs. All VRU devices in the cluster shall resume sending individual VAMs (e.g., they transition to state VRU-ACTIVE-STANDALONE). Other VRUs may then attempt to form new clusters with themselves as leaders as specified above. Next state: VRU-ACTIVE-STANDALONE.
Joining a VRU cluster: Initial state: VRU-ACTIVE-STANDALONE. When a VRU device receives cluster VAMs from a cluster leader, the VBS 821 in VRU-ACTIVE-STANDALONE shall analyse the received cluster VAMs and decide whether it should join the cluster or not (see conditions in clause 5.4.2.4 of [TS103300-3]). Joining a cluster is an optional operation. Before joining the cluster, the VRU shall include in its individual VAMs an indication that it is joining the identified cluster along with an indication of the time at which it intends to stop sending individual VAMs. It shall send these indications for a time timeClusterJoinNotification. Once the VRU has sent the appropriate number of notifications, it joins the cluster, i.e. it stops transmission and starts monitoring the cluster VAMs from the cluster leader.
Cancelled-join handling: If the VBS 821 determines that it will not join the cluster after having started the joining operation (for example because it receives a VAM with the maximal cluster size (cardinality) maxClusterSize exceeded), it stops including the cluster join notification in its individual VAMs and includes the cluster leave notification for a time timeClusterLeaveNotification. This allows the cluster leader to track the size of its cluster.
Failed-join handling: If after ceasing to send individual VAMs the VBS 821 determines that the cluster leader has not updated the cluster state to contain that new member (e.g., the device is not inside the bounding box information provided in the received cluster VAM from the cluster leader, or the size is not consistent with observed cluster join and leave notifications), or the cluster it intended to join does not exist anymore, the VBS 821 leaves the cluster (e.g., it starts transmitting individual VAMs again and remain in VRU-ACTIVE-STANDALONE state). The VBS 821 takes this action if the first cluster VAM received after timeClusterJoinSuccess passes does not account for the ego VBS 821. When the ego VBS 821 transmits individual VAMs after a cancelled-join or a failed-join, it: a) uses the same station ID it used before the cancelled-join or failed-join; and b) includes the cluster leave notification for a time timeClusterLeaveNotification. A VRU ITS-S that experiences a “failed join” of this type may make further attempts to join the cluster. Each attempt shall follow the process defined in this transition case. A VRU device may determine that it is within a cluster bounding box indicated by a message other than a VAM (for example a CPM). In that case, it shall follow the cluster join process described here, but shall provide the special value “0” as identifier of the cluster it joins. Next state: VRU-PASSIVE.
Leaving a VRU cluster: Initial state: VRU-PASSIVE. When a VRU in a cluster receives VAMs from the VRU cluster leader, the VBS 821 analyzes the received VAMs and decide whether it should leave the cluster or not (see clause 5.4.2.4 of [TS103300-3]). Leaving the cluster consists of resuming to send individual VAMs. When the VRU ITS-S leaves the cluster, the VAMs that it sends after state VRU-PASSIVE ends, shall indicate that it is leaving the identified cluster with a reason why it leaves the identified cluster (see clause 7.3.5 of [TS103300-3] for the list of reasons). It shall include this indication for time timeClusterLeaveNotification. A VRU is always allowed to leave a cluster for any reason, including its own decision or any safety risk identified. After a VRU leaves a cluster and starts sending individual VAMs, it should use different identifiers (including Station ID in the VAM and pseudonym certificate) from the ones it used in individual VAMs sent before it joined the cluster. Exception, if the VRU experiences a cancelled-join or a failed-join as specified above (in “Joining a VRU cluster” transition), it should use the Station ID and other identifiers that it was using before the failed join to allow better tracking by the cluster leader of the state of the cluster for a numClusterVAMRepeat number of VAMs, and resume the pseudonymization of its Station ID afterwards. A VRU device that is in VRU-PASSIVE state and within a cluster indicated by a message other than a VAM (e.g., a CPM) may decide to resume sending the VAM because it has determined it was within the cluster indicated by the other message, but is now going to leave or has left that cluster bounding box. In that case, it shall follow the cluster leave process described here, indicating the special cluster identifier value “0”. Next state: VRU-ACTIVE-STANDALONE
Determining VRU cluster leader lost: In some cases, the VRU cluster leader may lose communication connection or fail as a node. In this case, the VBS 821 of the cluster leader cannot send VAMs any more on behalf of the cluster. When a VBS 821 in VRU-PASSIVE state because of clustering determines that it did not receive VAMs from the VRU cluster leader for a time timeClusterContinuity, it shall assume that the VRU cluster leader is lost and shall leave the cluster as specified previously. Next state: VRU-ACTIVE-STANDALONE
The following actions do not trigger a state transition but shall cause an update of information.
Extending or shrinking a VRU cluster: State: VRU-ACTIVE-CLUSTER-LEADER. A VAM indicating that a VRU is joining the cluster allows the VRU cluster leader to determine whether the cluster is homogeneous or heterogeneous, its profile, bounding box, velocity and reference position, etc. The cluster data elements in the cluster VAM shall be updated by the VRU cluster leader to include the new VRU. The same applies when a VRU leaves the cluster.
Changing a VRU cluster ID: State: VRU-ACTIVE-CLUSTER-LEADER, VRU-PASSIVE. A cluster leader may change the cluster ID at any time and for any reason. The cluster leader shall include in its VAMs an indication that the cluster ID is going to change for time timeClusterIdChangeNotification before implementing the change. The notification indicates the time at which the change will happen. The cluster leader shall transmit a cluster VAM with the new cluster ID as soon as possible after the ID change. VRU devices in the cluster shall observe at that time whether there is a cluster with a new ID that has similar bounding boxes and dynamic properties to the previous cluster. If there is such a cluster, the VRU devices shall update their internal record of the cluster ID to the newly observed cluster ID. If there is no such cluster, the VRU devices shall execute the leave process with respect to the old cluster. VRU devices that leave a cluster that has recently changed ID may use either the old or the new cluster ID in their leave indication for time timeClusterIdPersist. After that time, they shall only use the new cluster ID. If the VBS 821 of a cluster leader receives a VAM from another VRU with the same identifier as its own, it shall immediately trigger a change of the cluster ID complying with the process described in the previous paragraph.
The transmission of intent to change cluster ID does not significantly impact privacy. This is because an eavesdropper who is attempting to track a cluster and is listening to the cluster VAMs at the time of an ID change will be able to determine continuity of the cluster anyway, by “joining the dots” of its trajectory through the ID change using the dynamic information. ID change is intended mainly to protect against an eavesdropper who is not continually listening, but instead has the capability to listen only in discrete, isolated locations. For this eavesdropper model, including a “change prepare” notification for a short time does not significantly increase the likelihood that the eavesdropper will be able to track the cluster through the ID change. The new cluster ID is not provided in the notification, only the time when the ID is intended to change.
Conditions to determine whether to create a cluster: a VRU device with a VBS 821 in VRU-ACTIVE-STANDALONE can create a cluster if all these conditions are met: It has sufficient processing power (indicated in the VRU configuration received from the VRU profile management function). It has been configured with VRU equipment type VRU-St (as defined in clause 4.4 of [TR103300-1]). It is receiving VAMs from numCreateCluster different VRUs not further away than maxClusterDistance. It has failed to identify a cluster it could join. Another possible condition is that the VRU-ITS-S has received an indication from a neighbouring V-ITS-S or R-ITS-S that a cluster should be created.
Conditions to determine whether to join or leave a cluster in normal conditions: a VRU device whose VBS 821 is in VRU-ACTIVE-STANDALONE state shall determine whether it can join or should leave a cluster by comparing its measured position and kinematic state with the position and kinematic state indicated in the VAM of the VRU cluster leader. Joining a cluster is an optional operation.
If the compared information fulfils certain conditions, i.e. the cluster has not reached its maximal size (cardinality) maxClusterSize, the VRU is within the VRU cluster bounding box or at a certain distance maxClusterDistance away from the VRU cluster leader and velocity difference less than maxClusterVelocityDifference of own velocity, the VRU device may join the cluster.
After joining the cluster, when the compared information does not fulfil the previous conditions any longer, the VRU device shall leave the cluster. If changing its role to non-VRU (e.g., by entering a bus or a passenger car), the VRU device shall also follow the leaving process described in clause 5.4.2.2 of [TS103300-3]. If the VRU device receives VAMs from two different clusters that have the same cluster ID (e.g., due to hidden node situation), it shall not join any of the two clusters. In the case the VBS 821, after leaving a VRU cluster, determines that it has entered a low-risk geographical area as defined in clause 3.1 of [TS103300-3] (e.g., through the reception of a MAPEM), according to requirement FCOM03 in [TS103300-2], it shall transition to the VRU-PASSIVE state (see clause 6 of [TS103300-3]). The VBS 821 indicates in the VAM the reason why it leaves a cluster, as defined in clause 7.3.5 of [TS103300-3].
In some cases, merging VRU clusters can further reduce VRU messaging in the network. For example, moving VRU clusters on a sidewalk with similar coherent cluster velocity profiles may have fully or partially overlapped bounding boxes (see clause 5.4.3 of [TS103300-3]) and so may merge to form one larger cluster. This shall be done as specified in clause 5.4.1 of [TS103300-3], i.e. the second cluster leader shall break up its cluster, enter VRU-ACTIVE-STANDALONE state and join the new cluster as an individual VRU. All devices that were part of the cluster led by the second cluster leader become individual VRUs (i.e. enter VRU-ACTIVE-STANDALONE state) and may choose individually to join the cluster led by the first cluster leader.
The VAM reception management function 903 performs the following operations after VAM messages decoding: check the relevance of the received message according to its current mobility characteristics and state; check the consistency, plausibility and integrity (see the liaison with security protocols) of the received message semantic; and destroy or store the received message data elements in the LDM according to previous operations results.
The VAM Transmission management function 904 is only available at the VRU device level, not at the level of other ITS elements such as V-ITS-Ss 110 or R-ITS-Ss 130. Even at the VRU device level, this function may not be present depending on its initial configuration (see device role setting function 811). The VAM transmission management function 904 performs the following operations upon request of the VBS management function 901: assemble the message data elements in conformity to the message standard specification; and send the constructed VAM to the VAM encoding function 905. The VAM encoding function 905 encodes the Data Elements provided by the VAM transmission management function 904 in conformity with the VAM specification. The VAM encoding function 905 is available only if the VAM transmission management function 904 is available.
The VAM decoding function 906 extracts the relevant Data Elements contained in the received message. These data elements are then communicated to the VAM reception management function 903. The VAM decoding function 906 is available only if the VAM reception management function 903 is available.
A VRU may be configured with a VRU profile. VRU profiles are the basis for the further definition of the VRU functional architecture. The profiles are derived from the various use cases discussed herein. VRUs 116 usually refers to living beings. A living being is considered to be a VRU only when it is in the context of a safety related traffic environment. For example, a living being in a house is not a VRU until it is in the vicinity of a street (e.g., 2m or 3m), at which point, it is part of the safety related context. This allows the amount of communications to be limited, for example, a C-ITS communications device need only start to act as a VRU-ITS-S when the living being associated with it starts acting in the role of a VRU.
A VRU can be equipped with a portable device. The term “VRU” may be used to refer to both a VRU and its VRU device unless the context dictates otherwise. The VRU device may be initially configured and may evolve during its operation following context changes that need to be specified. This is particularly true for the setting-up of the VRU profile and VRU type which can be achieved automatically at power on or via an HMI. The change of the road user vulnerability state needs to be also provided either to activate the VBS when the road user becomes vulnerable or to de-activate it when entering a protected area. The initial configuration can be set-up automatically when the device is powered up. This can be the case for the VRU equipment type which may be: VRU-Tx with the only communication capability to broadcast messages and complying with the channel congestion control rules; VRU-Rx with the only communication capability to receive messages; and/or VRU-St with full duplex communication capabilities. During operation, the VRU profile may also change due to some clustering or de-assembly. Consequently, the VRU device role will be able to evolve according to the VRU profile changes.
The following profile classification parameters may be used to classify different VRUs 116:
These profile parameters are not dynamic parameters maintained in internal tables, but indications of typical values to be used to classify the VRUs 116 and evaluate the behavior of a VRU 116 belonging to a specific profile. Example VRU profiles may be as follows:
Point-to-multipoint communication as discussed in ETSI EN 302 636-4-1 v 1.3.1 (2017 August) (hereinafter “[EN302634-4-1]”), ETSI EN 302 636-3 v1.1.2 (2014 March) (hereinafter “[EN302636-3]”) may be used for transmitting VAMs, as specified in ETSI TS 103 300-3 V0.1.11 (2020 May) (hereinafter “[TS103300-3]”).
VRUs 116/117 present a diversity of profiles which lead to random behaviors when moving in shared areas. Moreover, their inertia is much lower than vehicles (for example a pedestrian can do a U turn in less than one second) and as such their motion dynamic is more difficult to predict.
The VBS enables the dissemination of VRU Awareness Messages (VAM), whose purpose is to create awareness at the level of other VRUs or vehicles, with the objective to solve conflicting situations leading to collisions. The vehicle possible action to solve a conflict situation is directly related to the time left before the conflict, the vehicle velocity, vehicle deceleration or lane change capability, weather and vehicle condition (for example state of the road and of the vehicle tires). In the best case, a vehicle needs 1 to 2 seconds to be able to avoid a collision, but in worst cases, it can take more than 4 to 5 seconds to be able to avoid a collision. If a vehicle is very close to a VRU and with constant velocity (for example time-to-collision between 1 to 2 seconds), it is not possible any more to talk about awareness as this becomes really an alert for both the VRU and the vehicle.
VRUs and vehicles which are in a conflict situation need to detect it at least 5 to 6 seconds before reaching the conflict point to be sure to have the capability to act on time to avoid a collision. Generally, collision risk indicators (for example TTC, TDTC, PET, etc., see e.g., [TS103300-2]) are used to predict the instant of the conflict. These indicators need a prediction of: the trajectory (path) followed by the subject VRU and the subject vehicle; and/or the time required by the subject VRU and the subject vehicle to reach together the conflict point.
These predictions should be derived from data elements which are exchanged between the subject VRU and the subject vehicle. For vehicles, the trajectory and time predictions can be better predicted than for VRUs, because vehicles' trajectories are constrained to the road topography, traffic, traffic rules, etc., while VRUs have much more freedom to move. For vehicles, their dynamics is also constrained by their size, their mass and their heading variation capabilities, which is not the case for most of the VRUs.
Accordingly, it is not possible, in many situations, to predict the VRUs exact trajectory or their velocity only based on their recent path history and on their current position. If this is performed, a lot of false positive and false negative results can be expected, leading to decisions of wrong collision avoidance action.
A possible way to avoid false positive and false negative results is to base respectively the vehicle and VRU path predictions on deterministic information provided by the vehicle and by the VRU (motion dynamic change indications) and by a better knowledge of the statistical VRU behavior in repetitive contextual situations. A prediction can always be verified a-posteriori when building the path history. Detected errors can then be used to correct future predictions.
VRU Motion Dynamic Change Indications (MDCI) are built from deterministic indicators which are directly provided by the VRU device itself or which result from a mobility modality state change (e.g., transiting from pedestrian to bicyclist, transiting from pedestrian riding his bicycle to pedestrian pushing his bicycle, transiting from motorcyclist riding his motorcycle to motorcyclist ejected from his motorcycle, transitioning from a dangerous area to a protected area, for example entering a tramway, a train, etc.).
In the present document, the VRUs 116/117 can be classified into four profiles which are defined in clause 4.1 of [TS103300-3]. The SAE J3194 also proposes a taxonomy and classification of powered micro-mobility vehicles: powered bicycle (e.g., electric bikes); powered standing scooter (e.g., Segway®); powered seated scooter; powered self-balancing board sometimes referred to as “self-balancing scooter” (e.g., Hoverboard® self-balancing board, and Onewheel® self-balancing single wheel electric board.); powered skates; and/or the like. Their main characteristics are their kerb weight, vehicle width, top speed, power source (electrical or combustion). Human powered micro-mobility vehicles (bicycle, standing scooter) should be also considered. Transitions between engine powered vehicles and human powered vehicles may occur, changing the motion dynamic of the vehicle. Both, human powered and engine powered may also occur in parallel, also impacting the motion dynamic of the vehicle.
In [TS103300-2] and in clause 5.4.2.6 of [TS103300-3], a combined VRU 116/117 is defined as the assembly of a VRU profile 1, potentially with one or several additional VRU(s) 116/117, with one VRU vehicle or animal. Several VRU vehicle types are possible. Even if most of them can carry VRUs, their propulsion mode can be different, leading to specific threats and vulnerabilities: they can be propelled by a human (human riding on the vehicle or mounted on an animal); they can be propelled by a thermal engine. In this case, the thermal engine is only activated when the ignition system is operational; and/or they can be propelled by an electrical engine. In this case, the electrical engine is immediately activated when the power supply is on (no ignition).
A combined VRU 116/117 can be the assembly of one human and one animal (e.g., human with a horse or human with a camel). A human riding a horse may decide to get off the horse and then pull it. In this case, the VRU 116/117 performs a transition from profile 2 to profile 1 with an impact on its velocity.
This diversity of VRUs 116/117 and cluster association leads to several VBS state machines conditioning standard messages dissemination and their respective motion dynamics. These state machines and their transitions can be summarized as in
In the future, profile 2 1002, profile 1 1001, and profile 4 1004 VRUs may become members of a cluster, thus adding to their own state the state machine associated to clustering operation. This means that they need to respect the cluster management requirements while continuing to manage their own states. When transitioning from one state to another, the combined VRU may leave a cluster if it does not comply anymore with its requirements.
The machine states' transitions which are identified in
T1 is a transition from a VRU profile 1 1001 to profile 2 1002. This transition is manually or automatically triggered when the VRU takes the decision to use actively a VRU vehicle (riding). The motion dynamic velocity parameter value of the VRU changes from a low speed (pushing/pulling his VRU vehicle) to a higher speed related to the class of the selected VRU vehicle.
T2 is a transition from a VRU profile 2 1002 to profile 1 1001. This transition is manually or automatically triggered when the VRU gets off his VRU vehicle and leaves it to become a pedestrian. The motion dynamic velocity parameter value of the VRU changes from a given speed to a lower speed related to the class of the selected VRU vehicle.
T3 is a transition from a VRU profile 2 1002 to profile 1 1001. This transition is manually or automatically triggered when the VRU gets off his VRU vehicle and pushes/pulls it for example to enter a protected environment (for example tramway, bus, train). The motion dynamic velocity parameter value of the VRU changes from a given speed to a lower speed related to the class of the selected VRU vehicle.
T4 is a transition from a VRU profile 2 1002 to profile 1 1001. This transition is automatically triggered when a VRU is detected to be ejected from his VRU vehicle. The motion dynamic velocity parameter value of the VRU changes from a given speed to a lower speed related to the VRU state resulting from his ejection. In this case, the VRU vehicle is considered as an obstacle on the road and accordingly should disseminate DENMs until it is removed from the road (its ITS-S is deactivated).
The ejection case can be detected by stability indicators including inertia sensors and the rider competence level derived from its behavior. The stability can then be expressed in terms of the risk level of a complete stability lost. When the risk level is 100% this can be determined as a factual ejection of the VRU.
From the variation of the motion change dynamic velocity parameter value, a new path prediction can be provided from registered “contextual” past path histories (average VRU traces). The contextual aspects consider several parameters which are related to a context similar to the context in which the VRU is evolving.
Adding to the state transitions identified above, which may drastically impact the VRU velocity, the following VRU indications also impact the VRU velocity and/or the VRU trajectory (in addition to the parameters already defined in the VAM).
Stopping indicator. The VRU or an external source (a traffic light being red for the VRU) may indicate that the VRU is stopping for a moment. When this indicator is set, it could also be useful to know the duration of the VRU stop. This duration can be estimated either when provided by an external source (for example the SPATEM information received from a traffic light) or when learned through an analysis of the VRU behavior in similar circumstances.
Visibility indicators. Weather conditions may impact the VRU visibility and accordingly change its motion dynamic. Even if the local vehicles may detect these weather conditions, in some cases, the impact on the VRU could be difficult to estimate by vehicles. A typical example is the following: according to its orientation, a VRU can be disturbed by a severe glare of the sun (for example, in the morning when the sun rises, or in the evening when sun goes down), limiting its speed
Referring back to
The access layer includes a physical layer (PHY) 804 connecting physically to the communication medium, a data link layer (DLL), which may be sub-divided into a medium access control sub-layer (MAC) managing the access to the communication medium, and a logical link control sub-layer (LLC), management adaptation entity (MAE) to directly manage the PHY 804 and DLL, and a security adaptation entity (SAE) to provide security services for the access layer. The access layer may also include external communication interfaces (CIs) and internal CIs. The CIs are instantiations of a specific access layer technology or RAT and protocol such as 3GPP LTE, 3GPP 5G/NR, C-V2X (e.g., based on 3GPP LTE and/or 5G/NR), WiFi, W-V2X (e.g., including ITS-G5 and/or DSRC), DSL, Ethernet, Bluetooth, and/or any other RAT and/or communication protocols discussed herein, or combinations thereof. The CIs provide the functionality of one or more logical channels (LCHs), where the mapping of LCHs on to physical channels is specified by the standard of the particular access technology involved. As alluded to previously, the V2X RATs may include ITS-G5/DSRC and 3GPP C-V2X. Additionally or alternatively, other access layer technologies (V2X RATs) may be used in various other embodiments.
The ITS-S reference architecture 800 may be applicable to the elements of
Additionally, other entities that operate at the same level but are not included in the ITS-S include the relevant users at that level, the relevant HMI (e.g., audio devices, display/touchscreen devices, etc.); when the ITS-S is a vehicle, vehicle motion control for computer-assisted and/or automated vehicles (both HMI and vehicle motion control entities may be triggered by the ITS-S applications); a local device sensor system and IoT Platform that collects and shares IoT data; local device sensor fusion and actuator application(s), which may contain ML/AI and aggregates the data flow issued by the sensor system; local perception and trajectory prediction applications that consume the output of the fusion application and feed the ITS-S applications; and the relevant ITS-S. The sensor system can include one or more cameras, radars, LIDARs, etc., in a V-ITS-S 110 or R-ITS-S 130. In the central station, the sensor system includes sensors that may be located on the side of the road, but directly report their data to the central station, without the involvement of a V-ITS-S 110 or R-ITS-S 130. In some cases, the sensor system may additionally include gyroscope(s), accelerometer(s), and the like (see e.g., sensor circuitry 1572 of
The actuators 1313 are devices that are responsible for moving and controlling a mechanism or system. In various embodiments, the actuators 1313 are used to change the operational state (e.g., on/off, zoom or focus, etc.), position, and/or orientation of the sensors 1308. In some embodiments, the actuators 1313 are used to change the operational state of some other roadside equipment, such as gates, traffic lights, digital signage or variable message signs (VMS), etc. The actuators 1313 are configured to receive control signals from the R-ITS-S 1301 via the roadside network, and convert the signal energy (or some other energy) into an electrical and/or mechanical motion. The control signals may be relatively low energy electric voltage or current. In embodiments, the actuators 1313 comprise electromechanical relays and/or solid state relays, which are configured to switch electronic devices on/off and/or control motors, and/or may be that same or similar or actuators 1574 discussed infra with respect to
Each of
The local device sensor system and IoT Platform 1105, 1205, and 1305 collects and shares IoT data. The VRU sensor system and IoT Platform 1205 is at least composed of the PoTi management function present in each ITS-S of the system. The PoTi entity provides the global time common to all system elements and the real time position of the mobile elements. Local sensors may also be embedded in other mobile elements as well as in the road infrastructure (e.g., camera in a smart traffic light, electronic signage, etc.). An IoT platform, which can be distributed over the system elements, may contribute to provide additional information related to the environment surrounding the VRU system 1200. The sensor system can include one or more cameras, radars, LiDARs, and/or other sensors (see e.g., 1522 of
The (local) sensor data fusion function and/or actuator applications 1104, 1204, and 1304 provides the fusion of local perception data obtained from the VRU sensor system and/or different local sensors. This may include aggregating data flows issued by the sensor system and/or different local sensors. The local sensor fusion and actuator application(s) may contain machine learning (ML)/Artificial Intelligence (AI) algorithms and/or models. Various ML/AI techniques can be used to carry out the sensor data fusion. Sensor data fusion usually relies on the consistency of its inputs and then to their timestamping, which correspond to a common given time.
For any of the embodiments discussed herein, any suitable data fusion or data integration technique(s) may be used to generate the composite information. For example, the data fusion technique may be a direct fusion technique or an indirect fusion technique. Direct fusion combines data acquired directly from multiple vUEs or sensors, which may be the same or similar (e.g., all vUEs or sensors perform the same type of measurement) or different (e.g., different vUE or sensor types, historical data, etc.). Indirect fusion utilizes historical data and/or known properties of the environment and/or human inputs to produce a refined data set. Additionally, the data fusion technique may include one or more fusion algorithms, such as a smoothing algorithm (e.g., estimating a value using multiple measurements in real-time or not in real-time), a filtering algorithm (e.g., estimating an entity's state with current and past measurements in real-time), and/or a prediction state estimation algorithm (e.g., analyzing historical data (e.g., geolocation, speed, direction, and signal measurements) in real-time to predict a state (e.g., a future signal strength/quality at a particular geolocation coordinate)). As examples, the data fusion algorithm may be or include a structured-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 Extended Kalman Filtering, a fuzzy-based data fusion algorithm, an Ant Colony Optimization (ACO) algorithm, a fault detection algorithm, a Dempster-Shafer (D-S) argumentation-based algorithm, a Gaussian Mixture Model algorithm, a triangulation based fusion algorithm, and/or any other like data fusion algorithm
A local perception function (which may or may not include trajectory prediction application(s)) 1102, 1202, and 1302 is provided by the local processing of information collected by local sensor(s) associated to the system element. The local perception (and trajectory prediction) function 1102, 1202, and 1302 consumes the output of the sensor data fusion application/function 1104, 1204, and 1304 and feeds ITS-S applications with the perception data (and/or trajectory predictions). The local perception (and trajectory prediction) function 1102, 1202, and 1302 detects and characterize objects (static and mobile) which are likely to cross the trajectory of the considered moving objects. The infrastructure, and particularly the road infrastructure 1300, may offer services relevant to the VRU support service. The infrastructure may have its own sensors detecting VRUs 116 evolutions and then computing a risk of collision if also detecting local vehicles' evolutions, either directly via its own sensors or remotely via a cooperative perception 814 supporting services such as the CPS (see e.g., ETSI TR 103 562). Additionally, road marking (e.g., zebra areas or crosswalks) and vertical signs may be considered to increase the confidence level associated with the VRU detection and mobility since VRUs 116 usually have to respect these marking/signs.
The motion dynamic prediction function 1103 and 1203, and the mobile objects trajectory prediction 1303 (at the RSU level), are related to the behavior prediction of the considered moving objects. In some embodiments, the motion dynamic prediction function 1103 and 1203 predict the trajectory of the vehicle 110 and the VRU 116, respectively. In some embodiments, the motion dynamic prediction function 1103 may be part of the VRU Trajectory and Behavioral Modeling module and trajectory interception module of the V-ITS-S 110. In some embodiments, the motion dynamic prediction function 1203 may be part of the dead reckoning module and/or the movement detection module of the VRU ITS-S 117. Alternatively, the motion dynamic prediction functions 1103 and 1203 may provide motion/movement predictions to the aforementioned modules. Additionally or alternatively, the mobile objects trajectory prediction 1303 predict respective trajectories of corresponding vehicles 110 and VRUs 116, which may be used to assist the VRU ITS-S 117 in performing dead reckoning and/or assist the V-ITS-S 110 with VRU Trajectory and Behavioral Modeling.
Motion dynamic prediction includes a moving object trajectory resulting from evolution of the successive mobile positions. A change of the moving object trajectory or of the moving object velocity (acceleration/deceleration) impacts the motion dynamic prediction. In most cases, when VRUs 116 are moving, they still have a large amount of possible motion dynamics in terms of possible trajectories and velocities. This means that motion dynamic prediction 1103, 1203, 1303 is used to identify which motion dynamic will be selected by the VRU 116 as quickly as possible, and if this selected motion dynamic is subject to a risk of collision with another VRU or a vehicle.
The motion dynamic prediction functions 1103, 1203, 1303 analyze the evolution of mobile objects and the potential trajectories that may meet at a given time to determine a risk of collision between them. The motion dynamic prediction works on the output of cooperative perception 814 considering the current trajectories of considered device (e.g., VRU device 117) for the computation of the path prediction; the current velocities and their past evolutions for the considered mobiles for the computation of the velocity evolution prediction; and the reliability level which can be associated to these variables. The output of this function is provided to the risk analysis function (see e.g.,
In many cases, working only on the output of the cooperative perception 814 is not sufficient to make a reliable prediction because of the uncertainty which exists in terms of VRU trajectory selection and its velocity. However, complementary functions may assist in increasing consistently the reliability of the prediction. For example, the use of the device (e.g., VRU device 117) navigation system, which provides assistance to the user (e.g., VRU 116) to select the best trajectory for reaching its planned destination. With the development of Mobility as a Service (MaaS), multimodal itinerary computation may also indicate to the VRU 116 dangerous areas and then assist to the motion dynamic prediction at the level of the multimodal itinerary provided by the system. In another example, the knowledge of the user (e.g., VRU 116) habits and behaviors may be additionally or alternatively used to improve the consistency and the reliability of the motion predictions. Some users (e.g., VRUs 116) follow the same itineraries, using similar motion dynamics, for example when going to the main Point of Interest (POI), which is related to their main activities (e.g., going to school, going to work, doing some shopping, going to the nearest public transport station from their home, going to sport center, etc.). The device (e.g., VRU device 117) or a remote service center may learn and memorize these habits. In another example, the indication by the user (e.g., VRU 116) itself of its selected trajectory in particular when changing it (e.g., using a right turn or left turn signal similar to vehicles when indicating a change of direction).
The vehicle motion control 1108 may be included for computer-assisted and/or automated vehicles 110. Both the HMI entity 1106 and vehicle motion control entity 1108 may be triggered by one or more ITS-S applications. The vehicle motion control entity 1108 may be a function under the responsibility of a human driver or of the vehicle if it is able to drive in automated mode.
The Human Machine Interface (HMI) 1106, 1206, and 1306, when present, enables the configuration of initial data (parameters) in the management entities (e.g., VRU profile management) and in other functions (e.g., VBS management). The HMI 1106, 1206, and 1306 enables communication of external events related to the VBS to the device owner (user), including the alerting 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 seconds) being detected by at least one element of the system. For a VRU system 117 (e.g., personal computing system 1200), similar to a vehicle driver, the HMI provides the information to the VRU 116, considering its profile (e.g., for a blind person, the information is presented with a clear sound level using accessibility capabilities of the particular platform of the personal computing system 1200). In various implementations, the HMI 1106, 1206, and 1306 may be part of the alerting system.
The connected systems 1107, 1207, and 1307 refer to components/devices used to connect a system with one or more other systems. As examples, the connected systems 1107, 1207, and 1307 may include communication circuitry and/or radio units. The VRU system 1200 may be a connected system made of up to 4 different levels of equipment. The VRU system 1200 may also be an information system which collects, in real time, information resulting from events, processes the collected information and stores them together with processed results. At each level of the VRU system 1200, the information collection, processing and storage is related to the functional and data distribution scenario which is implemented.
The system 1400 includes application circuitry 1405, baseband circuitry 1410, one or more radio front end modules (RFEMs) 1415, memory circuitry 1420, power management integrated circuitry (PMIC) 1425, power tee circuitry 1430, network controller circuitry 1435, network interface connector 1440, positioning circuitry 1445, and user interface 1450. In some embodiments, the device 1400 may include additional elements such as, for example, memory/storage, display, camera, sensor, or 10 interface. In other embodiments, the components described below may be included in more than one device. For example, said circuitries may be separately included in more than one device for CRAN, CR, vBBU, or other like implementations.
Application circuitry 1405 includes circuitry such as, but not limited to one or more processors (or processor cores), cache memory, and one or more of low drop-out voltage regulators (LDOs), interrupt controllers, serial interfaces such as SPI, I2C or universal programmable serial interface module, real time clock (RTC), timer-counters including interval and watchdog timers, general purpose IO, memory card controllers such as Secure Digital (SD) MultiMediaCard (MMC) or similar, Universal Serial Bus (USB) interfaces, Mobile Industry Processor Interface (MIPI) interfaces and Joint Test Access Group (JTAG) test access ports. The processors (or cores) of the application circuitry 1405 may be coupled with or may include memory/storage elements and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the system 1400. In some implementations, the memory/storage elements may be on-chip memory circuitry, which may include any suitable volatile and/or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, Flash memory, solid-state memory, and/or any other type of memory device technology, such as those discussed herein.
The processor(s) of application circuitry 1405 may include, for example, one or more processor cores (CPUs), one or more application processors, one or more graphics processing units (GPUs), one or more reduced instruction set computing (RISC) processors, one or more Acorn RISC Machine (ARM) processors, one or more complex instruction set computing (CISC) processors, one or more DSPs, one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, or any suitable combination thereof. In some embodiments, the application circuitry 1405 may comprise, or may be, a special-purpose processor/controller to operate according to the various embodiments herein. As examples, the processor(s) of application circuitry 1405 may include one or more Intel Pentium®, Core®, or Xeon® processor(s); Advanced Micro Devices (AMD) Ryzen® processor(s), Accelerated Processing Units (APUs), or Epyc® processors; ARM-based processor(s) licensed from ARM Holdings, Ltd. such as the ARM Cortex-A family of processors and the ThunderX2® provided by Cavium™, Inc.; a MIPS-based design from MIPS Technologies, Inc. such as MIPS Warrior P-class processors; and/or the like. In some embodiments, the system 1400 may not utilize application circuitry 1405, and instead may include a special-purpose processor/controller to process IP data received from an EPC or 5GC, for example.
In some implementations, the application circuitry 1405 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices, or the like. The one or more hardware accelerators may include, for example, computer vision (CV) and/or deep learning (DL) accelerators. As examples, the programmable processing devices may be one or more field-programmable gate arrays (FPGAs); programmable logic devices (PLDs) such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), and the like; ASICs such as structured ASICs and the like; programmable SoCs (PSoCs); and/or the like. In such implementations, the circuitry of application circuitry 1405 may comprise logic blocks or logic fabric, and other interconnected resources that may be programmed to perform various functions, such as the procedures, methods, functions, etc. of the various embodiments discussed herein. In such embodiments, the circuitry of application circuitry 1405 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), anti-fuses, etc.)) used to store logic blocks, logic fabric, data, etc. in look-up-tables (LUTs) and the like.
In some implementations, such as implementations where subsystems of the edge nodes 130, intermediate nodes 120, and/or endpoints 110 of Figure XS1 are individual software agents or AI agents, each agent is implemented in a respective hardware accelerator that are configured with appropriate bit stream(s) or logic blocks to perform their respective functions. In these implementations, processor(s) and/or hardware accelerators of the application circuitry 1405 may be specifically tailored for operating the agents and/or for machine learning functionality, such as a cluster of AI GPUs, tensor processing units (TPUs) developed by Google® Inc., a Real AI Processors (RAPs™) provided by AlphalCs®, Nervana™ Neural Network Processors (NNPs) provided by Intel® Corp., Intel® Movidius™ Myriad™ X Vision Processing Unit (VPU), NVIDIA® PX™ based GPUs, the NM500 chip provided by General Vision®, Hardware 3 provided by Tesla®, Inc., an Epiphany™ based processor provided by Adapteva®, or the like. In some embodiments, the hardware accelerator may be implemented as an AI accelerating co-processor, such as the Hexagon 685 DSP provided by Qualcomm®, the PowerVR 2NX Neural Net Accelerator (NNA) provided by Imagination Technologies Limited®, the Neural Engine core within the Apple® A11 or A12 Bionic SoC, the Neural Processing Unit within the HiSilicon Kirin 970 provided by Huawei®, and/or the like.
The baseband circuitry 1410 may be implemented, for example, as a solder-down substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board or a multi-chip module containing two or more integrated circuits. The baseband circuitry 1410 includes one or more processing devices (e.g., baseband processors) to carry out various protocol and radio control functions. Baseband circuitry 1410 may interface with application circuitry of system 1400 for generation and processing of baseband signals and for controlling operations of the RFEMs 1415. The baseband circuitry 1410 may handle various radio control functions that enable communication with one or more radio networks via the RFEMs 1415. The baseband circuitry 1410 may include circuitry such as, but not limited to, one or more single-core or multi-core processors (e.g., one or more baseband processors) or control logic to process baseband signals received from a receive signal path of the RFEMs 1415, and to generate baseband signals to be provided to the RFEMs 1415 via a transmit signal path. In various embodiments, the baseband circuitry 1410 may implement a real-time OS (RTOS) to manage resources of the baseband circuitry 1410, schedule tasks, etc. Examples of the RTOS may include Operating System Embedded (OSE)™ provided by Enea®, Nucleus RTOS™ provided by Mentor Graphics®, Versatile Real-Time Executive (VRTX) provided by Mentor Graphics®, ThreadX™ provided by Express Logic®, FreeRTOS, REX OS provided by Qualcomm®, OKL4 provided by Open Kernel (OK) Labs®, or any other suitable RTOS, such as those discussed herein.
Although not shown by
Continuing with the aforementioned embodiment, the baseband circuitry 1410 includes individual processing device(s) to implement PHY including HARQ functions, scrambling and/or descrambling, (en)coding and/or decoding, layer mapping and/or de-mapping, modulation symbol mapping, received symbol and/or bit metric determination, multi-antenna port pre-coding and/or decoding which may include one or more of space-time, space-frequency or spatial coding, reference signal generation and/or detection, preamble sequence generation and/or decoding, synchronization sequence generation and/or detection, control channel signal blind decoding, radio frequency shifting, and other related functions. etc. The modulation/demodulation functionality may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. The (en)coding/decoding functionality may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) coding. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.
User interface circuitry 1450 may include one or more user interfaces designed to enable user interaction with the system 1400 or peripheral component interfaces designed to enable peripheral component interaction with the system 1400. User interfaces may include, but are not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, a touchscreen, speakers or other audio emitting devices, microphones, a printer, a scanner, a headset, a display screen or display device, etc. Peripheral component interfaces may include, but are not limited to, a nonvolatile memory port, a universal serial bus (USB) port, an audio jack, a power supply interface, etc.
The radio front end modules (RFEMs) 1415 may comprise a millimeter wave (mmWave) RFEM and one or more sub-mmWave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-mmWave RFICs may be physically separated from the mmWave RFEM. The RFICs may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both mmWave and sub-mmWave radio functions may be implemented in the same physical RFEM 1415, which incorporates both mmWave antennas and sub-mmWave. The antenna array comprises one or more antenna elements, each of which is configured convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. For example, digital baseband signals provided by the baseband circuitry 1410 is converted into analog RF signals (e.g., modulated waveform) that will be amplified and transmitted via the antenna elements of the antenna array including one or more antenna elements (not shown). The antenna elements may be omnidirectional, direction, or a combination thereof. The antenna elements may be formed in a multitude of arranges as are known and/or discussed herein. The antenna array may comprise microstrip antennas or printed antennas that are fabricated on the surface of one or more printed circuit boards. The antenna array may be formed in as a patch of metal foil (e.g., a patch antenna) in a variety of shapes, and may be coupled with the RF circuitry using metal transmission lines or the like.
The memory circuitry 1420 may include one or more of volatile memory including dynamic random access memory (DRAM) and/or synchronous dynamic random access memory (SDRAM), and nonvolatile memory (NVM) including high-speed electrically erasable memory (commonly referred to as Flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc., and may incorporate the three-dimensional (3D) cross-point (XPOINT) memories from Intel® and Micron®. Memory circuitry 1420 may be implemented as one or more of solder down packaged integrated circuits, socketed memory modules and plug-in memory cards.
The memory circuitry 1420 is configured to store computational logic (or “modules”) in the form of software, firmware, or hardware commands to implement the techniques described herein. The computational logic or modules may be developed using a suitable programming language or development tools, such as any programming language or development tool discussed herein. The computational logic may be employed to store working copies and/or permanent copies of programming instructions for the operation of various components of appliance infrastructure equipment 1400, an operating system of infrastructure equipment 1400, one or more applications, and/or for carrying out the embodiments discussed herein. The computational logic may be stored or loaded into memory circuitry 1420 as instructions for execution by the processors of the application circuitry 1405 to provide or perform the functions described herein. The various elements may be implemented by assembler instructions supported by processors of the application circuitry 1405 or high-level languages that may be compiled into such instructions. The permanent copy of the programming instructions may be placed into persistent storage devices of memory circuitry 1420 in the factory during manufacture, or in the field through, for example, a distribution medium (not shown), through a communication interface (e.g., from a distribution server), and/or over-the-air (OTA).
As discussed in more detail infra, infrastructure equipment 1400 may be configured to support a particular V2X RAT based on the number of vUEs 121 that support (or are capable to communicate) the particular V2X RAT. In embodiments, the memory circuitry 1420 may store a RAT configuration control module to control the (re)configuration of the infrastructure equipment 1400 to support a particular RAT and/or V2X RAT. The configuration control module provides an interface for triggering (re)configuration actions. In some embodiments, the memory circuitry 1420 may also store a RAT software (SW) management module to implement SW loading or provisioning procedures, and (de)activation SW in the infrastructure equipment 1400. In either of these embodiments, the memory circuitry 1420 may store a plurality of V2X RAT software components, each of which include program code, instructions, modules, assemblies, packages, protocol stacks, software engine(s), etc., for operating the infrastructure equipment 1400 or components thereof (e.g., RFEMs 1415) according to a corresponding V2X RAT. When a V2X RAT component is configured or executed by the application circuitry 1405 and/or the baseband circuitry 1410, the infrastructure equipment 1400 operates according to the V2X RAT component.
In a first example, a first V2X RAT component may be an C-V2X component, which includes LTE and/or C-V2X protocol stacks that allow the infrastructure equipment 1400 to support C-V2X and/or provide radio time/frequency resources according to LTE and/or C-V2X standards. Such protocol stacks may include a control plane protocol stack including a Non-Access Stratum (NAS), Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) layer entities; and a user plane protocol stack including General Packet Radio Service (GPRS) Tunneling Protocol for the user plane layer (GTP-U), User Datagram Protocol (UDP), Internet Protocol (IP), PDCP, RLC, MAC, and PHY layer entities. These control plane and user plane protocol entities are discussed in more detail in 3GPP TS 36.300 and/or 3GPP TS 38.300, as well as other 3GPP specifications. In some embodiments, the IP layer entity may be replaced with an Allocation and Retention Priority (ARP) layer entity or some other non-IP protocol layer entity. Some or all of the aforementioned protocol layer entities may be “relay” versions depending on whether the infrastructure equipment 1400 is acting as a relay. In some embodiments, the user plane protocol stack may be the PC5 user plane (PC5-U) protocol stack discussed in 3GPP TS 23.303 v15.1.0 (2018 June).
In a second example, a second V2X RAT component may be a ITS-G5 component, which includes ITS-G5 (IEEE 802.11p) and/or Wireless Access in Vehicular Environments (WAVE) (IEEE 1609.4) protocol stacks, among others, that allow the infrastructure equipment to support ITS-G5 communications and/or provide radio time-frequency resources according to ITS-G5 and/or other WiFi standards. The ITS-G5 and WAVE protocol stacks include, inter alia, a DSRC/WAVE PHY and MAC layer entities that are based on the IEEE 802.11p protocol. The DSRC/WAVE PHY layer is responsible for obtaining data for transmitting over ITS-G5 channels from higher layers, as well as receiving raw data over the ITS-G5 channels and providing data to upper layers. The MAC layer organizes the data packets into network frames. The MAC layer may be split into a lower DSRC/WAVE MAC layer based on IEEE 802.11p and an upper WAVE MAC layer (or a WAVE multi-channel layer) based on IEEE 1609.4. IEEE 1609 builds on IEEE 802.11p and defines one or more of the other higher layers. The ITS-G5 component may also include a logical link control (LLC) layer entity to perform layer 3 (L3) multiplexing and demultiplexing operations. The LLC layer (e.g., IEEE 802.2) allows multiple network L3 protocols to communicate over the same physical link by allowing the L3 protocols to be specified in LLC fields.
In addition to the V2X RAT components, the memory circuitry 1420 may also store a RAT translation component, which is a software engine, API, library, object(s), engine(s), or other functional unit for providing translation services to vUEs 121 that are equipped with different V2X capabilities. For example, the RAT translation component, when configured or executed, may cause the infrastructure equipment 1400 to convert or translate a first message obtained according to the first V2X RAT (e.g., C-V2X) into a second message for transmission using a second V2X RAT (e.g., ITS-G5). In one example, the RAT translation component may perform the translation or conversion by extracting data from one or more fields of the first message and inserting the extracted data into corresponding fields of the second message. Other translation/conversion methods may also be used in other embodiments. In some embodiments, the RAT translation component may employ a suitable translator for translating one or more source messages in a source format into one or more target messages in a target format, and may utilize any suitable compilation strategies for the translation. The translator may also have different implementations depending on the type of V2X RATs that are supported by the infrastructure equipment 1400 (e.g., memory map, instruction set, programming model, etc.).
The PMIC 1425 may include voltage regulators, surge protectors, power alarm detection circuitry, and one or more backup power sources such as a battery or capacitor. The power alarm detection circuitry may detect one or more of brown out (under-voltage) and surge (over-voltage) conditions. The power tee circuitry 330 may provide for electrical power drawn from a network cable to provide both power supply and data connectivity to the infrastructure equipment 1400 using a single cable.
The network controller circuitry 1435 provides connectivity to a network using a standard network interface protocol such as Ethernet, Ethernet over GRE Tunnels, Ethernet over Multiprotocol Label Switching (MPLS), or some other suitable protocol, such as those discussed herein. Network connectivity may be provided to/from the infrastructure equipment 1400 via network interface connector 1440 using a physical connection, which may be electrical (commonly referred to as a “copper interconnect”), optical, or wireless. The network controller circuitry 1435 may include one or more dedicated processors and/or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the network controller circuitry 1435 may include multiple controllers to provide connectivity to other networks using the same or different protocols. In various embodiments, the network controller circuitry 1435 enables communication with associated equipment and/or with a backend system (e.g., server(s), core network, cloud service, etc.), which may take place via a suitable gateway device.
The positioning circuitry 1445 includes circuitry to receive and decode signals transmitted/broadcasted by a positioning network of a global navigation satellite system (GNSS). Examples of navigation satellite constellations (or GNSS) include United States' Global Positioning System (GPS), Russia's Global Navigation System (GLONASS), the European Union's Galileo system, China's BeiDou Navigation Satellite System, a regional navigation system or GNSS augmentation system (e.g., Navigation with Indian Constellation (NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS), etc.), or the like. The positioning circuitry 1445 comprises various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, and the like to facilitate OTA communications) to communicate with components of a positioning network, such as navigation satellite constellation nodes. In some embodiments, the positioning circuitry 1445 may include a Micro-Technology for Positioning, Navigation, and Timing (Micro-PNT) IC that uses a master timing clock to perform position tracking/estimation without GNSS assistance. The positioning circuitry 1445 may also be part of, or interact with, the baseband circuitry 1410 and/or RFEMs 1415 to communicate with the nodes and components of the positioning network. The positioning circuitry 1445 may also provide position data and/or time data to the application circuitry 1405, which may use the data to synchronize operations with various other infrastructure equipment, or the like.
The components shown by
The edge computing node 1550 includes processing circuitry in the form of one or more processors 1552. The processor circuitry 1552 includes circuitry such as, but not limited to one or more processor cores and one or more of cache memory, low drop-out voltage regulators (LDOs), interrupt controllers, serial interfaces such as SPI, I2C or universal programmable serial interface circuit, real time clock (RTC), timer-counters including interval and watchdog timers, general purpose I/O, memory card controllers such as secure digital/multi-media card (SD/MMC) or similar, interfaces, mobile industry processor interface (MIPI) interfaces and Joint Test Access Group (JTAG) test access ports. In some implementations, the processor circuitry 1552 may include one or more hardware accelerators (e.g., same or similar to acceleration circuitry 1564), which may be microprocessors, programmable processing devices (e.g., FPGA, ASIC, etc.), or the like. The one or more accelerators may include, for example, computer vision and/or deep learning accelerators. In some implementations, the processor circuitry 1552 may include on-chip memory circuitry, which may include any suitable volatile and/or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, Flash memory, solid-state memory, and/or any other type of memory device technology, such as those discussed herein
The processor circuitry 1552 may include, for example, one or more processor cores (CPUs), application processors, GPUs, RISC processors, Acorn RISC Machine (ARM) processors, CISC processors, one or more DSPs, one or more FPGAs, one or more PLDs, one or more ASICs, one or more baseband processors, one or more radio-frequency integrated circuits (RFIC), one or more microprocessors or controllers, a multi-core processor, a multithreaded processor, an ultra-low voltage processor, an embedded processor, or any other known processing elements, or any suitable combination thereof. The processors (or cores) 1552 may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the node 1550. The processors (or cores) 1552 is configured to operate application software to provide a specific service to a user of the node 1550. In some embodiments, the processor(s) 1552 may be a special-purpose processor(s)/controller(s) configured (or configurable) to operate according to the various embodiments herein.
As examples, the processor(s) 1552 may include an Intel® Architecture Core™ based processor such as an i3, an i5, an i7, an i9 based processor; an Intel® microcontroller-based processor such as a Quark™, an Atom™, or other MCU-based processor; Pentium® processor(s), Xeon® processor(s), or another such processor available from Intel® Corporation, Santa Clara, Calif. However, any number other processors may be used, such as one or more of Advanced Micro Devices (AMD) Zen® Architecture such as Ryzen® or EPYC® processor(s), Accelerated Processing Units (APUs), MxGPUs, Epyc® processor(s), or the like; A5-A12 and/or S1-S4 processor(s) from Apple® Inc., Snapdragon™ or Centrig™ processor(s) from Qualcomm® Technologies, Inc., Texas Instruments, Inc.® Open Multimedia Applications Platform (OMAP)™ processor(s); a MIPS-based design from MIPS Technologies, Inc. such as MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; an ARM-based design licensed from ARM Holdings, Ltd., such as the ARM Cortex-A, Cortex-R, and Cortex-M family of processors; the ThunderX2® provided by Cavium™, Inc.; or the like. In some implementations, the processor(s) 1552 may be a part of a system on a chip (SoC), System-in-Package (SiP), a multi-chip package (MCP), and/or the like, in which the processor(s) 1552 and other components are formed into a single integrated circuit, or a single package, such as the Edison™ or Galileo™ SoC boards from Intel® Corporation. Other examples of the processor(s) 1552 are mentioned elsewhere in the present disclosure.
The processor(s) 1552 may communicate with system memory 1554 over an interconnect (IX) 1556. Any number of memory devices may be used to provide for a given amount of system memory. As examples, the memory may be random access memory (RAM) in accordance with a Joint Electron Devices Engineering Council (JEDEC) design such as the DDR or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In particular examples, a memory component may comply with a DRAM standard promulgated 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), and/or the like may also be included. Such standards (and similar standards) may be referred to as DDR-based standards and communication interfaces of the storage devices that implement such standards may be referred to as DDR-based interfaces. In various implementations, the individual memory devices may be of any number of different package types such as single die package (SDP), dual die package (DDP) or quad die package (Q17P). These devices, in some examples, may be directly soldered onto a motherboard to provide a lower profile solution, while in other examples the devices are configured as one or more memory modules that in turn couple to the motherboard by a given connector. Any number of other memory implementations may be used, such as other types of memory modules, e.g., dual inline memory modules (DIMMs) of different varieties including but not limited to microDIMMs or MiniDIMMs.
To provide for persistent storage of information such as data, applications, operating systems and so forth, a storage 1558 may also couple to the processor 1552 via the IX 1556. In an example, the storage 1558 may be implemented via a solid-state disk drive (SSDD) and/or high-speed electrically erasable memory (commonly referred to as “flash memory”). Other devices that may be used for the storage 1558 include flash memory cards, such as SD cards, microSD cards, XD picture cards, and the like, and USB flash drives. In an example, the memory device may be or may include memory devices that use chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single or multi-level Phase Change Memory (PCM), a resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), anti-ferroelectric memory, magnetoresistive random access memory (MRAM) memory that incorporates memristor technology, phase change RAM (PRAM), resistive memory including the metal oxide base, the oxygen vacancy base and the conductive bridge Random Access Memory (CB-RAM), or spin transfer torque (STT)-MRAM, a spintronic magnetic junction memory based device, a magnetic tunneling junction (MTJ) based device, a Domain Wall (DW) and Spin Orbit Transfer (SOT) based device, a thyristor based memory device, or a combination of any of the above, or other memory. The memory circuitry 1554 and/or storage circuitry 1558 may also incorporate three-dimensional (3D) cross-point (XPOINT) memories from Intel® and Micron®.
In low power implementations, the storage 1558 may be on-die memory or registers associated with the processor 1552. However, in some examples, the storage 1458 may be implemented using a micro hard disk drive (HDD). Further, any number of new technologies may be used for the storage 1558 in addition to, or instead of, the technologies described, such resistance change memories, phase change memories, holographic memories, or chemical memories, among others.
The storage circuitry 1558 store computational logic 1582 (or “modules 1582”) in the form of software, firmware, or hardware commands to implement the techniques described herein. The computational logic 1582 may be employed to store working copies and/or permanent copies of computer programs, or data to create the computer programs, for the operation of various components of node 1550 (e.g., drivers, etc.), an OS of node 1550 and/or one or more applications for carrying out the embodiments discussed herein. The computational logic 1582 may be stored or loaded into memory circuitry 1554 as instructions 1582, or data to create the instructions 1588, for execution by the processor circuitry 1552 to provide the functions described herein. The various elements may be implemented by assembler instructions supported by processor circuitry 1552 or high-level languages that may be compiled into such instructions (e.g., instructions 1588, or data to create the instructions 1588). The permanent copy of the programming instructions may be placed into persistent storage devices of storage circuitry 1558 in the factory or in the field through, for example, a distribution medium (not shown), through a communication interface (e.g., from a distribution server (not shown)), or over-the-air (OTA).
In an example, the instructions 1588 provided via the memory circuitry 1554 and/or the storage circuitry 1558 of
In alternate embodiments, programming instructions (or data to create the instructions) may be disposed on multiple NTCRSM 1560. In alternate embodiments, programming instructions (or data to create the instructions) may be disposed on computer-readable transitory storage media, such as, signals. The instructions embodied by a machine-readable medium may further be transmitted or received over a communications network using a transmission medium via a network interface device utilizing any one of a number of transfer protocols (e.g., HTTP). Any combination of one or more computer usable or computer readable medium(s) may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, one or more electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, devices, or propagation media. For instance, the NTCRSM 1560 may be embodied by devices described for the storage circuitry 1558 and/or memory circuitry 1554. More specific examples (a non-exhaustive list) of a computer-readable medium would include the following: 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 optical disks, a transmission media such as those supporting the Internet or an intranet, a magnetic storage device, or any number of other hardware devices. Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program (or data to create the program) is printed, as the program (or data to create the program) can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory (with or without having been staged in or more intermediate storage media). In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program (or data to create the program) for use by or in connection with the instruction execution system, apparatus, or device. The computer-usable medium may include a propagated data signal with the computer-usable program code (or data to create the program code) embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code (or data to create the program) may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc.
In various embodiments, the program code (or data to create the program code) described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a packaged format, etc. Program code (or data to create the program code) as described herein may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, etc. in order to make them directly readable and/or executable by a computing device and/or other machine. For example, the program code (or data to create the program code) may be stored in multiple parts, which are individually compressed, encrypted, and stored on separate computing devices, wherein the parts when decrypted, decompressed, and combined form a set of executable instructions that implement the program code (the data to create the program code such as that described herein. In another example, the Program code (or data to create the program code) may be stored in a state in which they may be read by a computer, but require addition of a library (e.g., a dynamic link library), a software development kit (SDK), an application programming interface (API), etc. in order to execute the instructions on a particular computing device or other device. In another example, the program code (or data to create the program code) may need to be configured (e.g., settings stored, data input, network addresses recorded, etc.) before the program code (or data to create the program code) can be executed/used in whole or in part. In this example, the program code (or data to create the program code) may be unpacked, configured for proper execution, and stored in a first location with the configuration instructions located in a second location distinct from the first location. The configuration instructions can be initiated by an action, trigger, or instruction that is not co-located in storage or execution location with the instructions enabling the disclosed techniques. Accordingly, the disclosed program code (or data to create the program code) are intended to encompass such machine readable instructions and/or program(s) (or data to create such machine readable instruction and/or programs) regardless of the particular format or state of the machine readable instructions and/or program(s) when stored or otherwise at rest or in transit.
Computer program code for carrying out operations of the present disclosure (e.g., computational logic 1582, instructions 1582, instructions 1588 discussed previously) may be written in any combination of one or more programming languages, including an object oriented programming language such as Python, Ruby, Scala, Smalltalk, Java™, C++, C#, or the like; a procedural programming languages, such as the “C” programming language, the Go (or “Golang”) programming language, or the like; a scripting language 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, and/or the like; a markup language such as Hypertext Markup Language (HTML), Extensible Markup Language (XML), Java Script Object Notion (JSON), Apex®, Cascading Stylesheets (CSS), JavaServer Pages (JSP), MessagePack™, Apache® Thrift, Abstract Syntax Notation One (ASN.1), Google® Protocol Buffers (protobuf), or the like; some other suitable programming languages including proprietary programming languages and/or development tools, or any other languages tools. The computer program code for carrying out operations of the present disclosure may also be written in any combination of the programming languages discussed herein. The program code may execute entirely on the system 1550, partly on the system 1550, as a stand-alone software package, partly on the system 1550 and partly on a remote computer or entirely on the 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).
In an example, the instructions 1588 on the processor circuitry 1552 (separately, or in combination with the instructions 1582 and/or logic/modules 1582 stored in computer-readable storage media) may configure execution or operation of a trusted execution environment (TEE) 1590. The TEE 1590 operates as a protected area accessible to the processor circuitry 1552 to enable secure access to data and secure execution of instructions. In some embodiments, the TEE 1590 may be a physical hardware device that is separate from other components of the system 1550 such as a secure-embedded controller, a dedicated SoC, or a tamper-resistant chipset or microcontroller with embedded processing devices and memory devices. Examples of such embodiments include a Desktop and mobile Architecture Hardware (DASH) compliant Network Interface Card (NIC), Intel® Management/Manageability Engine, Intel® Converged Security Engine (CSE) or a Converged Security Management/Manageability Engine (CSME), Trusted Execution Engine (TXE) provided by Intel® each of which may operate in conjunction with Intel® Active Management Technology (AMT) and/or Intel® vPro™ Technology; AMD® Platform Security coProcessor (PSP), AMD® PRO A-Series Accelerated Processing Unit (APU) with DASH manageability, Apple® Secure Enclave coprocessor; IBM® Crypto Express3®, IBM® 4807, 4808, 4809, and/or 4765 Cryptographic Coprocessors, IBM® Baseboard Management Controller (BMC) with Intelligent Platform Management Interface (IPMI), Dell™ Remote Assistant Card II (DRAC II), integrated Dell™ Remote Assistant Card (iDRAC), and the like.
In other embodiments, the TEE 1590 may be implemented as secure enclaves, which are isolated regions of code and/or data within the processor and/or memory/storage circuitry of the system 1550. Only code executed within a secure enclave may access data within the same secure enclave, and the secure enclave may only be accessible using the secure application (which may be implemented by an application processor or a tamper-resistant microcontroller). Various implementations of the TEE 1550, and an accompanying secure area in the processor circuitry 1552 or the memory circuitry 1554 and/or storage circuitry 1558 may be provided, for instance, through use of Intel® Software Guard Extensions (SGX), ARM® TrustZone® hardware security extensions, Keystone Enclaves provided by Oasis Labs™, and/or the like. Other aspects of security hardening, hardware roots-of-trust, and trusted or protected operations may be implemented in the device 1550 through the TEE 1590 and the processor circuitry 1552.
In some embodiments, the memory circuitry 1554 and/or storage circuitry 1558 may be divided into isolated user-space instances such as containers, partitions, virtual environments (VEs), etc. The isolated user-space instances may be implemented using a suitable OS-level virtualization technology such as Docker® containers, Kubernetes® containers, Solaris® containers and/or zones, OpenVZ® virtual private servers, DragonFly BSD® virtual kernels and/or jails, chroot jails, and/or the like. Virtual machines could also be used in some implementations. In some embodiments, the memory circuitry 1554 and/or storage circuitry 1558 may be divided into one or more trusted memory regions for storing applications or software modules of the TEE 1590.
Although the instructions 1582 are shown as code blocks included in the memory circuitry 1554 and the computational logic 1582 is shown as code blocks in the storage circuitry 1558, it should be understood that any of the code blocks may be replaced with hardwired circuits, for example, built into an FPGA, ASIC, or some other suitable circuitry. For example, where processor circuitry 1552 includes (e.g., FPGA based) hardware accelerators as well as processor cores, the hardware accelerators (e.g., the FPGA cells) may be pre-configured (e.g., with appropriate bit streams) with the aforementioned computational logic to perform some or all of the functions discussed previously (in lieu of employment of programming instructions to be executed by the processor core(s)).
The memory circuitry 1554 and/or storage circuitry 1558 may store program code of an operating system (OS), which may be a general purpose OS or an OS specifically written for and tailored to the computing node 1550. For example, the OS may be Unix or a Unix-like OS such as Linux e.g., provided by Red Hat Enterprise, Windows 10™ provided by Microsoft Corp.®, macOS provided by Apple Inc.®, or the like. In another example, the OS may be a mobile OS, such as Android® provided by Google Inc.®, iOS® provided by Apple Inc.®, Windows 10 Mobile® provided by Microsoft Corp.®, KaiOS provided by KaiOS Technologies Inc., or the like. In another example, the OS may be a real-time OS (RTOS), such as Apache Mynewt provided by the Apache Software Foundation®, Windows 10 For IoT® provided by Microsoft Corp.®, Micro-Controller Operating Systems (“MicroC/OS” or “μC/OS”) provided by Micrium®, Inc., FreeRTOS, VxWorks® provided by Wind River Systems, Inc.®, PikeOS provided by Sysgo AG®, Android Things® provided by Google Inc.®, QNX® RTOS provided by BlackBerry Ltd., or any other suitable RTOS, such as those discussed herein.
The OS may include one or more drivers that operate to control particular devices that are embedded in the node 1550, attached to the node 1550, or otherwise communicatively coupled with the node 1550. The drivers may include individual drivers allowing other components of the node 1550 to interact or control various I/O devices that may be present within, or connected to, the node 1550. For example, the drivers may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface of the node 1550, sensor drivers to obtain sensor readings of sensor circuitry 1572 and control and allow access to sensor circuitry 1572, actuator drivers to obtain actuator positions of the actuators 1574 and/or control and allow access to the actuators 1574, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices. The OSs may also include one or more libraries, drivers, APIs, firmware, middleware, software glue, etc., which provide program code and/or software components for one or more applications to obtain and use the data from a secure execution environment, trusted execution environment, and/or management engine of the node 1550 (not shown).
The components of edge computing device 1550 may communicate over the IX 1556. The IX 1556 may include any number of technologies, including ISA, extended ISA, VC, SPI, point-to-point interfaces, power management bus (PMBus), PCI, PCIe, PCIx, Intel® UPI, Intel® Accelerator Link, Intel® CXL, CAPI, OpenCAPI, Intel® QPI, UPI, Intel® OPA IX, RapidIO™ system IXs, CCIX, Gen-Z Consortium IXs, a HyperTransport interconnect, NVLink provided by NVIDIA®, a Time-Trigger Protocol (TTP) system, a FlexRay system, and/or any number of other IX technologies. The IX 1556 may be a proprietary bus, for example, used in a SoC based system.
The IX 1556 couples the processor 1552 to communication circuitry 1566 for communications with other devices, such as a remote server (not shown) and/or the connected edge devices 1562. The communication circuitry 1566 is a hardware element, or collection of hardware elements, used to communicate over one or more networks (e.g., cloud 1563) and/or with other devices (e.g., edge devices 1562).
The transceiver 1566 may use any number of frequencies and protocols, such as 2.4 Gigahertz (GHz) transmissions under the IEEE 802.15.4 standard, using the Bluetooth® low energy (BLE) standard, as defined by the Bluetooth® Special Interest Group, or the ZigBee® standard, among others. Any number of radios, configured for a particular wireless communication protocol, may be used for the connections to the connected edge devices 1562. For example, a wireless local area network (WLAN) unit may be used to implement WiFi® communications in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. In addition, wireless wide area communications, e.g., according to a cellular or other wireless wide area protocol, may occur via a wireless wide area network (WWAN) unit.
The wireless network transceiver 1566 (or multiple transceivers) may communicate using multiple standards or radios for communications at a different range. For example, the edge computing node 1550 may communicate with close devices, e.g., within about 10 meters, using a local transceiver based on BLE, or another low power radio, to save power. More distant connected edge devices 1562, e.g., within about 50 meters, may be reached over ZigBee® or other intermediate power radios. Both communications techniques may take place over a single radio at different power levels or may take place over separate transceivers, for example, a local transceiver using BLE and a separate mesh transceiver using ZigBee®.
A wireless network transceiver 1566 (e.g., a radio transceiver) may be included to communicate with devices or services in the edge cloud 1563 via local or wide area network protocols. The wireless network transceiver 1566 may be an LPWA transceiver that follows the IEEE 802.15.4, or IEEE 802.15.4g standards, among others. The edge computing node 1563 may 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 technologies but may be used with any number of other cloud transceivers that implement long range, low bandwidth communications, such as Sigfox, and other technologies. Further, other communications techniques, such as time-slotted channel hopping, described in the IEEE 802.15.4e specification may be used.
Any number of other radio communications and protocols may be used in addition to the systems mentioned for the wireless network transceiver 1566, as described herein. For example, the transceiver 1566 may include a cellular transceiver that uses spread spectrum (SPA/SAS) communications for implementing high-speed communications. Further, any number of other protocols may be used, such as WiFi® networks for medium speed communications and provision of network communications. The transceiver 1566 may include radios that are compatible with any number of 3GPP specifications, such as LTE and 5G/NR communication systems, discussed in further detail at the end of the present disclosure. A network interface controller (NIC) 1568 may be included to provide a wired communication to nodes of the edge cloud 1563 or to other devices, such as the connected edge devices 1562 (e.g., operating in a mesh). The wired communication may provide an Ethernet connection or may be based on other types of networks, such as Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway Plus (DH+), PROFIBUS, or PROFINET, among many others. An additional NIC 1568 may be included to enable connecting to a second network, for example, a first NIC 1568 providing communications to the cloud over Ethernet, and a second NIC 1568 providing communications to other devices over another type of network.
Given the variety of types of applicable communications from the device to another component or network, applicable communications circuitry used by the device may include or be embodied by any one or more of components 1564, 1566, 151468, or 1570. Accordingly, in various examples, applicable means for communicating (e.g., receiving, transmitting, etc.) may be embodied by such communications circuitry.
The edge computing node 1550 may include or be coupled to acceleration circuitry 1564, which may be embodied by one or more AI accelerators, a neural compute stick, neuromorphic hardware, an FPGA, an arrangement of GPUs, one or more SoCs (including programmable SoCs), one or more CPUs, one or more digital signal processors, dedicated ASICs (including programmable ASICs), PLDs such as CPLDs or HCPLDs, and/or other forms of specialized processors or circuitry designed to accomplish one or more specialized tasks. These tasks may include AI processing (including machine learning, training, inferencing, and classification operations), visual data processing, network data processing, object detection, rule analysis, or the like. In FPGA-based implementations, the acceleration circuitry 1564 may comprise logic blocks or logic fabric and other interconnected resources that may be programmed (configured) to perform various functions, such as the procedures, methods, functions, etc. of the various embodiments discussed herein. In such implementations, the acceleration circuitry 1564 may also include memory cells (e.g., EPROM, EEPROM, flash memory, static memory (e.g., SRAM, anti-fuses, etc.) used to store logic blocks, logic fabric, data, etc. in LUTs and the like.
The IX 1556 also couples the processor 1552 to a sensor hub or external interface 1570 that is used to connect additional devices or subsystems. The additional/external devices may include sensors 1572, actuators 1574, and positioning circuitry 1545.
The sensor circuitry 1572 includes devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) about the detected events to some other a device, module, subsystem, etc. Examples of such sensors 1572 include, inter alia, inertia measurement units (IMU) comprising accelerometers, gyroscopes, and/or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) comprising 3-axis accelerometers, 3-axis gyroscopes, and/or magnetometers; level sensors; flow sensors; temp sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras); light detection and ranging (LiDAR) sensors; proximity sensors (e.g., infrared radiation detector and the like); depth sensors, ambient light sensors; optical light sensors; ultrasonic transceivers; microphones; and the like.
Additionally or alternatively, some of the sensors 172 may be sensors used for various vehicle control systems, and may include, inter alia, exhaust sensors including exhaust oxygen sensors to obtain oxygen data and manifold absolute pressure (MAP) sensors to obtain manifold pressure data; mass air flow (MAF) sensors to obtain intake air flow data; intake air temperature (IAT) sensors to obtain IAT data; ambient air temperature (AAT) sensors to obtain AAT data; ambient air pressure (AAP) sensors to obtain AAP data (e.g., tire pressure data); catalytic converter sensors including catalytic converter temperature (CCT) to obtain CCT data and catalytic converter oxygen (CCO) sensors to obtain CCO data; vehicle speed sensors (VSS) to obtain VSS data; exhaust gas recirculation (EGR) sensors including EGR pressure sensors to obtain ERG pressure data and EGR position sensors to obtain position/orientation data of an EGR valve pintle; Throttle Position Sensor (TPS) to obtain throttle position/orientation/angle data; a crank/cam position sensors to obtain crank/cam/piston position/orientation/angle data; coolant temperature sensors; drive train sensors to collect drive train sensor data (e.g., transmission fluid level), vehicle body sensors to collect vehicle body data (e.g., data associated with buckling of the front grill/fenders, side doors, rear fenders, rear trunk, and so forth); and so forth. The sensors 172 may include other sensors such as an accelerator pedal position sensor (APP), accelerometers, magnetometers, level sensors, flow/fluid sensors, barometric pressure sensors, and the like. Sensor data from sensors 172 of the host vehicle may include engine sensor data collected by various engine sensors (e.g., engine temperature, oil pressure, and so forth).
The actuators 1574, allow node 1550 to change its state, position, and/or orientation, or move or control a mechanism or system. The actuators 1574 comprise electrical and/or mechanical devices 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 motion. The actuators 1574 may include one or more electronic (or electrochemical) devices, such as piezoelectric biomorphs, solid state actuators, solid state relays (SSRs), shape-memory alloy-based actuators, electroactive polymer-based actuators, relay driver integrated circuits (ICs), and/or the like. The actuators 1574 may include one or more electromechanical devices such as pneumatic actuators, hydraulic actuators, electromechanical switches including electromechanical relays (EMRs), motors (e.g., DC motors, stepper motors, servomechanisms, etc.), power switches, valve actuators, wheels, thrusters, propellers, claws, clamps, hooks, audible sound generators, visual warning devices, and/or other like electromechanical components. The node 1550 may be configured to operate one or more actuators 1574 based on one or more captured events and/or instructions or control signals received from a service provider and/or various client systems
In embodiments, the actuators 1574 may be driving control units (e.g., DCUs 174 of
In vehicular embodiments, the actuators/DCUs 1574 may be provisioned with control system configurations (CSCs), which are collections of software modules, software components, logic blocks, parameters, calibrations, variants, etc. used to control and/or monitor various systems implemented by node 1550 (e.g., when node 1550 is a CA/AD vehicle 110). The CSCs define how the DCUs 1574 are to interpret sensor data of sensors 1572 and/or CSD of other DCUs 1574 using multidimensional performance maps or lookup tables, and define how actuators/components are to be adjust/modified based on the sensor data. The CSCs and/or the software components to be executed by individual DCUs 1574 may be developed using any suitable object-oriented programming language (e.g., C, C++, Java, etc.), schema language (e.g., XML schema, AUTomotive Open System Architecture (AUTOSAR) XML schema, etc.), scripting language (VBScript, JavaScript, etc.), or the like. the CSCs and software components may be defined using a hardware description language (HDL), such as register-transfer logic (RTL), very high speed integrated circuit (VHSIC) HDL (VHDL), Verilog, etc. for DCUs 1574 that are implemented as field-programmable devices (FPDs). The CSCs and software components may be generated using a modeling environment or model-based development tools. According to various embodiments, the CSCs may be generated or updated by one or more autonomous software agents and/or AI agents based on learnt experiences, ODDs, and/or other like parameters. In another example, in embodiments where one or more DCUs 1574.
The IVS 101 and/or the DCUs 1574 is configurable or operable to operate one or more actuators based on one or more captured events (as indicated by sensor data captured by sensors 1572) and/or instructions or control signals received from user inputs, signals received over-the-air from a service provider, or the like. Additionally, one or more DCUs 1574 may be configurable or operable to operate one or more actuators by transmitting/sending instructions or control signals to the actuators based on detected events (as indicated by sensor data captured by sensors 1572). One or more DCUs 1574 may be capable of reading or otherwise obtaining sensor data from one or more sensors 1572, processing the sensor data to generate control system data (or CSCs), and providing the control system data to one or more actuators to control various systems of the vehicle 110. An embedded device/system acting as a central controller or hub may also access the control system data for processing using a suitable driver, API, ABI, library, middleware, firmware, and/or the like; and/or the DCUs 1574 may be configurable or operable to provide the control system data to a central hub and/or other devices/components on a periodic or aperiodic basis, and/or when triggered.
The various subsystems, including sensors 1572 and/or DCUs 1574, may be operated and/or controlled by one or more AI agents. The AI agents is/are autonomous entities configurable or operable to observe environmental conditions and determine actions to be taken in furtherance of a particular goal. The particular environmental conditions to be observed and the actions to take may be based on an operational design domain (ODD). An ODD includes the operating conditions under which a given AI agent or feature thereof is specifically designed to function. An ODD may include operational restrictions, such as environmental, geographical, and time-of-day restrictions, and/or the requisite presence or absence of certain traffic or roadway characteristics.
In embodiments, individual AI agents are configurable or operable to control respective control systems of the host vehicle, some of which may involve the use of one or more DCUs 1574 and/or one or more sensors 1572. In these embodiments, the actions to be taken and the particular goals to be achieved may be specific 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 particular context in which an AI agent is implemented. DDTs include all real-time operational and tactical functions required to operate a vehicle 110 in on-road traffic, excluding the strategic functions (e.g., trip scheduling and selection of destinations and waypoints. DDTs include tactical and operational tasks such as lateral vehicle motion control via steering (operational); longitudinal vehicle motion control via acceleration and deceleration (operational); monitoring the driving environment via object and event detection 818, recognition, classification, and response preparation (operational and tactical); object and event response execution (operational and tactical); maneuver planning (tactical); and enhancing conspicuity via lighting, signaling and gesturing, etc. (tactical). OEDR tasks may be subtasks of DDTs that include monitoring the driving environment (e.g., detecting, recognizing, and classifying objects and events and preparing to respond as needed) and executing an appropriate response to such objects and events, for example, as needed to complete the DDT or fallback task.
To observe environmental conditions, the AI agents is/are configurable or operable to receive, or monitor for, 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 act of monitoring may include capturing CSD and/or sensor data from individual sensors 172 and DCUs 1574. Monitoring may 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 for a specified/selected period of time. In other embodiments, monitoring may include sending a request or command for sensor data/CSD in response to an external request for sensor data/CSD. In some embodiments, monitoring may include waiting for sensor data/CSD from various sensors/modules based on triggers or events, such as when the host vehicle reaches predetermined speeds and/or distances in a predetermined amount of time (with or without intermitted stops). The events/triggers may be AI agent specific, and may vary depending of a particular embodiment. In some embodiments, the monitoring may be triggered or activated by an application or subsystem of the IVS 101 or by a remote device, such as compute node 140 and/or server(s) 160.
In some embodiments, one or more of the AI agents may be configurable or operable to process the sensor data and CSD to identify internal and/or external environmental conditions upon which to act. Examples of the sensor data may include, but are not limited to, image data from one or more cameras of the vehicle providing frontal, rearward, and/or side views looking out of the vehicle; sensor data from accelerometers, inertia measurement units (IMU), and/or gyroscopes of the vehicle providing speed, acceleration, and tilt data of the host vehicle; audio data provided by microphones; and control system sensor data provided by one or more control system sensors. In an example, one or more of the AI agents may be configurable or operable to process images captured by sensors 1572 (image capture devices) and/or assess conditions identified by some other subsystem (e.g., an EMA subsystem, CAS and/or CPS entities, and/or the like) to determine a state or condition of the surrounding area (e.g., existence of potholes, fallen trees/utility poles, damages to road side barriers, vehicle debris, and so forth). In another example, one or more of the AI agents may be configurable or operable to process CSD provided by one or more DCUs 1574 to determine a current amount of emissions or fuel economy of the host vehicle. The AI agents may also be configurable or operable to compare the sensor data and/or CSDs with training set data to determine or contribute to determining environmental conditions for controlling corresponding control systems of the vehicle.
To determine actions to be taken in furtherance of a particular goal, each of the AI agents are configurable or operable to identify a current state of the IVS 101, the host vehicles 110, and/or the AI agent itself, identify or obtain one or more models (e.g., ML models), identify or obtain goal information, and predict a result of taking one or more actions based on the current state/context, the one or more models, and the goal information. The one or more models may be any algorithms or objects created after an AI agent is trained with one or more training datasets, and the one or more models may indicate the possible actions that may 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 the IVS 101 and/or one or more other systems of the host vehicle 110, or a measure of various conditions in the IVS 101 and/or one or more other systems of the host vehicle 110. The current state is stored inside an AI agent and is maintained in a suitable data structure. The AI agents are configurable or operable to predict possible outcomes as a result of taking certain actions defined by the models. The goal information describes desired outcomes (or goal states) that are desirable given the current state. Each of the AI agents may select an outcome from among the predict possible outcomes that reaches a particular goal state, and provide signals or commands to various other subsystems of the vehicle 110 to perform one or more actions determined to lead to the selected outcome. The AI agents may also include a learning module configurable or operable to learn from an experience with respect to the selected outcome and some performance measure(s). The experience may include sensor data and/or new state data collected after performance of the one or more actions of the selected outcome. The learnt experience may be used to produce new or updated models for determining future actions to take.
The positioning circuitry 1545 includes circuitry to receive and decode signals transmitted/broadcasted by a positioning network of a global navigation satellite system (GNSS). Examples of navigation satellite constellations (or GNSS) include United States' Global Positioning System (GPS), Russia's Global Navigation System (GLONASS), the European Union's Galileo system, China's BeiDou Navigation Satellite System, a regional navigation system or GNSS augmentation system (e.g., Navigation with Indian Constellation (NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS), etc.), or the like. The positioning circuitry 1545 comprises various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, and the like to facilitate OTA communications) to communicate with components of a positioning network, such as navigation satellite constellation nodes. In some embodiments, the positioning circuitry 1545 may include a Micro-Technology for Positioning, Navigation, and Timing (Micro-PNT) IC that uses a master timing clock to perform position tracking/estimation without GNSS assistance. The positioning circuitry 1545 may also be part of, or interact with, the communication circuitry 1566 to communicate with the nodes and components of the positioning network. The positioning circuitry 1545 may also provide position data and/or time data to the application circuitry, which may use the data to synchronize operations with various infrastructure (e.g., radio base stations), for turn-by-turn navigation, or the like. When a GNSS signal is not available or when GNSS position accuracy is not sufficient for a particular application or service, a positioning augmentation technology can be used to provide augmented positioning information and data to the application or service. Such a positioning augmentation technology may include, for example, satellite based positioning augmentation (e.g., EGNOS) and/or ground based positioning augmentation (e.g., DGPS). In some implementations, the positioning circuitry 1545 is, or includes an INS, which is a system or device that uses sensor circuitry 1572 (e.g., motion sensors such as accelerometers, rotation sensors such as gyroscopes, and altimeters, magnetic sensors, and/or the like to continuously calculate (e.g., using dead by dead reckoning, triangulation, or the like) a position, orientation, and/or velocity (including direction and speed of movement) of the node 1550 without the need for external references.
In some optional examples, various input/output (I/O) devices may be present within or connected to, the edge computing node 1550, which are referred to as input circuitry 1586 and output circuitry 1584 in
A battery 1576 may power the edge computing node 1550, although, in examples in which the edge computing node 1550 is mounted in a fixed location, it may have a power supply coupled to an electrical grid, or the battery may be used as a backup or for temporary capabilities. The battery 1576 may be a lithium ion battery, or a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like.
A battery monitor/charger 1578 may be included in the edge computing node 1550 to track the state of charge (SoCh) of the battery 1576, if included. The battery monitor/charger 1578 may be used to monitor other parameters of the battery 1576 to provide failure predictions, such as the state of health (SoH) and the state of function (SoF) of the battery 1576. The battery monitor/charger 1578 may include a battery monitoring integrated circuit, such as an LTC4020 or an LTC2990 from Linear Technologies, an ADT7488A from ON Semiconductor of Phoenix Ariz., or an IC from the UCD90xxx family from Texas Instruments of Dallas, Tex. The battery monitor/charger 1578 may communicate the information on the battery 1576 to the processor 1552 over the IX 1556. The battery monitor/charger 1578 may 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 flow from the battery 1576. The battery parameters may be used to determine actions that the edge computing node 1550 may perform, such as transmission frequency, mesh network operation, sensing frequency, and the like.
A power block 1580, or other power supply coupled to a grid, may be coupled with 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 obtain the power wirelessly, for example, through a loop antenna in the edge computing node 1550. A wireless battery charging circuit, such as an LTC4020 chip from Linear Technologies of Milpitas, Calif., among others, may be included in the battery monitor/charger 1578. The specific charging circuits may be selected based on the size of the battery 1576, and thus, the current required. The charging may be performed using 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, among others.
The storage 1558 may include instructions 1582 in the form of software, firmware, or hardware commands to implement the techniques described herein. Although such instructions 1582 are shown as code blocks included in the memory 1554 and the storage 1558, it may be understood that any of the code blocks may be replaced with hardwired circuits, for example, built into an application specific integrated circuit (ASIC).
In an example, the instructions 1482 provided via the memory 1554, the storage 1558, or the processor 1552 may be embodied as a non-transitory, machine-readable medium 1560 including code to direct the processor 1552 to perform electronic operations in the edge computing node 1550. The processor 1552 may access the non-transitory, machine-readable medium 1560 over the IX 1556. For instance, the non-transitory, machine-readable medium 1560 may be embodied by devices described for the storage 1558 or may include specific storage units such as optical disks, flash drives, or any number of other hardware devices. The non-transitory, machine-readable medium 1560 may include instructions to direct the processor 1552 to perform a specific sequence or flow of actions, for example, as described with respect to the flowchart(s) and block diagram(s) of operations and functionality depicted above. As used herein, the terms “machine-readable medium” and “computer-readable medium” are interchangeable.
In further examples, a machine-readable medium also includes any tangible medium that is capable of storing, encoding or carrying instructions for execution by a machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. A “machine-readable medium” thus may include but is not limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including but not limited to, by way of example, 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. The instructions embodied by a machine-readable medium may further be transmitted or received over a communications network using a transmission medium via a network interface device utilizing any one of a number of transfer protocols (e.g., HTTP).
A machine-readable medium may be provided by a storage device or other apparatus which is capable of hosting data in a non-transitory format. In an example, information stored or otherwise provided on a machine-readable medium may be representative of instructions, such as instructions themselves or a format from which the instructions may be derived. This format from which the instructions may be derived may include source code, encoded instructions (e.g., in compressed or encrypted form), packaged instructions (e.g., split into multiple packages), or the like. The information representative of the instructions in the machine-readable medium may be processed by processing circuitry into the instructions to implement any of the operations discussed herein. For example, deriving the instructions from the information (e.g., processing by the processing circuitry) may include: compiling (e.g., from source code, object code, etc.), interpreting, loading, organizing (e.g., dynamically or statically linking), encoding, decoding, encrypting, unencrypting, packaging, unpackaging, or otherwise manipulating the information into the instructions.
In an example, the derivation of the instructions may include assembly, compilation, or interpretation of the information (e.g., by the processing circuitry) to create the instructions from some intermediate or preprocessed format provided by the machine-readable medium. The information, when provided in multiple parts, may be combined, unpacked, and modified to create the instructions. For example, the information may 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 may be encrypted when in transit over a network and decrypted, uncompressed, assembled (e.g., linked) if necessary, and compiled or interpreted (e.g., into a library, stand-alone executable, etc.) at a local machine, and executed by the local machine.
The illustrations of
Edge computing refers to the implementation, coordination, and use of computing and resources at locations closer to the “edge” or collection of “edges” of a network. Deploying computing resources at the network's edge may reduce application and network latency, reduce network backhaul traffic and associated energy consumption, improve service capabilities, improve compliance with security or data privacy requirements (especially as compared to conventional cloud computing), and improve total cost of ownership.
Individual compute platforms or other components that can perform edge computing operations (referred to as “edge compute nodes,” “edge nodes,” or the like) can reside in whatever location needed by the system architecture or ad hoc service. In many edge computing architectures, edge nodes are deployed at NANs, gateways, network routers, and/or other devices that are closer to endpoint devices (e.g., UEs, IoT devices, etc.) producing and consuming data. As examples, edge nodes may be implemented in a high performance compute data center or cloud installation; a designated edge node server, an enterprise server, a roadside server, a telecom central office; or a local or peer at-the-edge device being served consuming edge services.
Edge compute nodes may partition resources (e.g., memory, CPU, GPU, interrupt controller, I/O controller, memory controller, bus controller, network connections or sessions, etc.) where respective partitionings may contain security and/or integrity protection capabilities. Edge nodes may also provide orchestration of multiple applications through isolated user-space instances such as containers, partitions, virtual environments (VEs), virtual machines (VMs), Function-as-a-Service (FaaS) engines, Servlets, servers, and/or other like computation abstractions. Containers are contained, deployable units of software that provide code and needed dependencies. Various edge system arrangements/architecture treats VMs, containers, and functions equally in terms of application composition. The edge nodes are coordinated based on edge provisioning functions, while the operation of the various applications are coordinated with orchestration functions (e.g., VM or container engine, etc.). The orchestration functions may be used to deploy the isolated user-space instances, identifying and scheduling use of specific hardware, security related functions (e.g., key management, trust anchor management, etc.), and other tasks related to the provisioning and lifecycle of isolated user spaces.
Applications that have been adapted for edge computing include but are not limited to virtualization of traditional network functions including include, for example, Software-Defined Networking (SDN), Network Function Virtualization (NFV), distributed RAN units and/or RAN clouds, and the like. Additional example use cases for edge computing include computational offloading, Content Data Network (CDN) services (e.g., video on demand, content streaming, security surveillance, alarm system monitoring, building access, data/content caching, etc.), gaming services (e.g., AR/VR, etc.), accelerated browsing, IoT and industry applications (e.g., factory automation), media analytics, live streaming/transcoding, and V2X applications (e.g., driving assistance and/or autonomous driving applications).
Internet of Things (IoT) devices are physical or virtualized objects that may communicate on a network, and may include sensors, actuators, and other input/output components, such as to collect data or perform actions from a real world environment. For example, IoT devices may include low-powered devices that are embedded or attached to everyday things, such as buildings, vehicles, packages, etc., to provide an additional level of artificial sensory perception of those things. Recently, IoT devices have become more popular and thus applications using these devices have proliferated. The deployment of IoT devices and Multi-access Edge Computing (MEC) services have introduced a number of advanced use cases and scenarios occurring at or otherwise involving the edge of the network.
Edge computing may, in some scenarios, offer or host a cloud-like distributed service, to offer orchestration and management for applications and coordinated service instances among many types of storage and compute resources. Edge computing is also expected to be closely integrated with existing use cases and technology developed for IoT and Fog/distributed networking configurations, as endpoint devices, clients, and gateways attempt to access network resources and applications at locations closer to the edge of the network.
The present disclosure provides specific examples relevant to edge computing configurations provided within Multi-Access Edge Computing (MEC) and 5G network implementations. However, many other standards and network implementations are applicable to the edge and service management concepts discussed herein. For example, the embodiments discussed herein may be applicable to many other edge computing/networking technologies in various combinations and layouts of devices located at the edge of a network. Examples of such other edge computing/networking technologies that may implement the embodiments herein include Content Delivery Networks (CDNs) (also referred to as “Content Distribution Networks” or the like); Mobility Service Provider (MSP) edge computing and/or Mobility as a Service (MaaS) provider systems (e.g., used in AECC architectures); Nebula edge-cloud systems; Fog computing systems; Cloudlet edge-cloud systems; Mobile Cloud Computing (MCC) systems; Central Office Re-architected as a Datacenter (CORD), mobile CORD (M-CORD) and/or Converged Multi-Access and Core (COMAC) systems; and/or the like. 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 practice the embodiments herein.
As shown, the edge cloud 1610 is co-located at an edge location, such as an access point or base station 1640, a local processing hub 1650, or a central office 1620, and thus may include multiple entities, devices, and equipment instances. The edge cloud 1610 is located much closer to the endpoint (consumer and producer) data sources 1660 (e.g., autonomous vehicles 1661, user equipment 1662, business and industrial equipment 1663, video capture devices 1664, drones 1665, smart cities and building devices 1666, sensors and IoT devices 1667, etc.) than the cloud data center 1630. Compute, memory, and storage resources which are offered at the edges in the edge cloud 1610 are critical to providing ultra-low latency response times for services and functions used by the endpoint data sources 1660 as well as reduce network backhaul traffic from the edge cloud 1610 toward cloud data center 1630 thus improving energy consumption and overall network usages among other benefits.
Compute, memory, and storage are scarce resources, and generally decrease depending on the edge location (e.g., fewer processing resources being available at consumer endpoint devices, than at a base station, than at a central office). However, the closer that the edge location is to the endpoint (e.g., user equipment (UE)), the more that space and power is often constrained. Thus, edge computing attempts to reduce the amount of resources needed for network services, through the distribution of more resources which are located closer both geographically and in network access time. In this manner, edge computing attempts to bring the compute resources to the workload data where appropriate, or, bring the workload data to the compute resources.
The following describes aspects of an edge cloud architecture that covers multiple potential deployments and addresses restrictions that some network operators or service providers may have in their own infrastructures. These include, variation of configurations based on the edge location (because edges at a base station level, for instance, may have more constrained performance and capabilities in a multi-tenant scenario); configurations based on the type of compute, memory, storage, fabric, acceleration, or like resources available to edge locations, tiers of locations, or groups of locations; the service, security, and management and orchestration capabilities; and related objectives to achieve usability and performance of end services. These deployments may accomplish processing in network layers that may be considered as “near edge”, “close edge”, “local edge”, “middle edge”, or “far edge” layers, depending on latency, distance, and timing characteristics.
Edge computing is a developing paradigm where computing is performed at or closer to the “edge” of a network, typically through the use of a compute platform (e.g., x86 or ARM compute hardware architecture) implemented at base stations, gateways, network routers, or other devices which are much closer to endpoint devices producing and consuming the data. For example, edge gateway servers may be equipped with pools of memory and storage resources to perform computation in real-time for low latency use-cases (e.g., autonomous driving or video surveillance) for connected client devices. Or as an example, base stations may be augmented with compute and acceleration resources to directly process service workloads for connected user equipment, without further communicating data via backhaul networks. Or as another example, central office network management hardware may be replaced with standardized compute hardware that performs virtualized network functions and offers compute resources for the execution of services and consumer functions for connected devices. Within edge computing networks, there may be scenarios in services which the compute resource will be “moved” to the data, as well as scenarios in which the data will be “moved” to the compute resource. Or as an example, base station compute, acceleration and network resources can provide services in order to scale to workload demands on an as needed basis by activating dormant capacity (subscription, capacity on demand) in order to manage corner cases, emergencies or to provide longevity for deployed resources over a significantly longer implemented lifecycle.
Examples of latency, resulting from network communication distance and processing time constraints, may range from less than a millisecond (ms) when among the endpoint layer 1700, under 5 ms at the edge devices layer 1710, to even between 10 to 40 ms when communicating with nodes at the network access layer 1720. Beyond the edge cloud 1610 are core network 1730 and cloud data center 1740 layers, each with increasing latency (e.g., between 50-60 ms at the core network layer 1730, to 100 or more ms at the cloud data center layer). As a result, operations at a core network data center 1735 or a cloud data center 1745, with latencies of at least 50 to 100 ms or more, will not be able to accomplish many time-critical functions of the use cases 1705. Each of these latency values are provided for purposes of illustration and contrast; it will be understood that the use of other access network mediums and technologies may further reduce the latencies. In some examples, respective portions of the network may be categorized as “close edge”, “local edge”, “near edge”, “middle edge”, or “far edge” layers, relative to a network source and destination. For instance, from the perspective of the core network data center 1735 or a cloud data center 1745, a central office or content data network may be considered as being located within a “near edge” layer (“near” to the cloud, having high latency values when communicating with the devices and endpoints of the use cases 1705), whereas an access point, base station, on-premise server, or network gateway may be considered as located within a “far edge” layer (“far” from the cloud, having low latency values when communicating with the devices and endpoints of the use cases 1705). It will be understood that other categorizations of a particular network layer as constituting a “close”, “local”, “near”, “middle”, or “far” edge may be based on latency, distance, number of network hops, or other measurable characteristics, as measured from a source in any of the network layers 1700-1740.
The various use cases 1705 may access resources under usage pressure from incoming streams, due to multiple services utilizing the edge cloud. To achieve results with low latency, the services executed within the edge cloud 1610 balance varying requirements in terms of: (a) Priority (throughput or latency) and Quality of Service (QoS) (e.g., traffic for an autonomous car may have higher priority than a temperature sensor in terms of response time requirement; or, a performance sensitivity/bottleneck may exist at a compute/accelerator, memory, storage, or network resource, depending on the application); (b) Reliability and Resiliency (e.g., some input streams need to be acted upon and the traffic routed with mission-critical reliability, where as some other input streams may be tolerate an occasional failure, depending on the application); and (c) Physical constraints (e.g., power, cooling and form-factor).
The end-to-end service view for these use cases involves the concept of a service-flow and is associated with a transaction. The transaction details the overall service requirement for the entity consuming the service, as well as the associated services for the resources, workloads, workflows, and business functional and business level requirements. The services executed with the “terms” described may be managed at each layer in a way to assure real time, and runtime contractual compliance for the transaction during the lifecycle of the service. When a component in the transaction is missing its agreed to SLA, the system as a whole (components in the transaction) may provide the ability to (1) understand the impact of the SLA violation, and (2) augment other components in the system to resume overall transaction SLA, and (3) implement steps to remediate.
Thus, with these variations and service features in mind, edge computing within the edge cloud 1610 may provide the ability to serve and respond to multiple applications of the use cases 1705 (e.g., object tracking, video surveillance, connected cars, etc.) in real-time or near real-time, and meet ultra-low latency requirements for these multiple applications. These advantages enable a whole new class of applications (Virtual Network Functions (VNFs), Function as a Service (FaaS), Edge as a Service (EaaS), standard processes, etc.), which cannot leverage conventional cloud computing due to latency or other limitations.
However, with the advantages of edge computing comes the following caveats. The devices located at the edge are often resource constrained and therefore there is pressure on usage of edge resources. Typically, this is addressed through the pooling of memory and storage resources for use by multiple users (tenants) and devices. The edge may be power and cooling constrained and therefore the power usage needs to be accounted for by the applications that are consuming the most power. There may be inherent power-performance tradeoffs in these pooled memory resources, as many of them are likely to use emerging memory technologies, where more power requires greater memory bandwidth. Likewise, improved security of hardware and root of trust trusted functions are also required, because edge locations may be unmanned and may even need permissioned access (e.g., when housed in a third-party location). Such issues are magnified in the edge cloud 1610 in a multi-tenant, multi-owner, or multi-access setting, where services and applications are requested by many users, especially as network usage dynamically fluctuates and the composition of the multiple stakeholders, use cases, and services changes.
At a more generic level, an edge computing system may be described to encompass any number of deployments at the previously discussed layers operating in the edge cloud 1610 (network layers 1700-1740), which provide coordination from client and distributed computing devices. One or more edge gateway nodes, one or more edge aggregation nodes, and one or more core data centers may be distributed across layers of the network to provide an implementation of the edge computing system by or on behalf of a telecommunication service provider (“telco”, or “TSP”), internet-of-things service provider, cloud service provider (CSP), enterprise entity, or any other number of entities. Various implementations and configurations of the edge computing system may be provided dynamically, such as when orchestrated to meet service objectives.
Consistent with the examples provided herein, a client compute node may be embodied as any type of endpoint component, device, appliance, or other thing capable of communicating as a producer or consumer of data. Further, the label “node” or “device” as used in the edge computing system does not necessarily mean that such node or device operates in a client or agent/minion/follower role; rather, any of the nodes or devices in the edge computing system refer to individual entities, nodes, or subsystems which include discrete or connected hardware or software configurations to facilitate or use the edge cloud 1610.
As such, the edge cloud 1610 is formed from network components and functional features operated by and within edge gateway nodes, edge aggregation nodes, or other edge compute nodes among network layers 1710-1730. The edge cloud 1610 thus may be embodied as any type of network that provides edge computing and/or storage resources which are proximately located to radio access network (RAN) capable endpoint devices (e.g., mobile computing devices, IoT devices, smart devices, etc.), which are discussed herein. In other words, the edge cloud 1610 may be envisioned as an “edge” which connects the endpoint devices and traditional network access points that serve as an ingress point into service provider core networks, including mobile carrier networks (e.g., Global System for Mobile Communications (GSM) networks, Long-Term Evolution (LTE) networks, 5G/6G networks, etc.), while also providing storage and/or compute capabilities. Other types and forms of network access (e.g., Wi-Fi, long-range wireless, wired networks including optical networks) may also be utilized in place of or in combination with such 3GPP carrier networks.
The network components of the edge cloud 1610 may be servers, multi-tenant servers, appliance computing devices, and/or any other type of computing devices. For example, the edge cloud 1610 may include an appliance computing device that is a self-contained electronic device including a housing, a chassis, a case or a shell. In some circumstances, the housing may be dimensioned for portability such that it can be carried by a human and/or shipped. Example housings may include materials that form one or more exterior surfaces that partially or fully protect contents of the appliance, in which protection may include weather protection, hazardous environment protection (e.g., EMI, vibration, extreme temperatures), and/or enable submergibility. Example housings may include power circuitry to provide power for stationary and/or portable implementations, such as AC power inputs, DC power inputs, AC/DC or DC/AC converter(s), power regulators, transformers, charging circuitry, batteries, wired inputs and/or wireless power inputs. Example housings and/or surfaces thereof may include or connect to mounting hardware to enable attachment to structures such as buildings, telecommunication structures (e.g., poles, antenna structures, etc.) and/or racks (e.g., server racks, blade mounts, etc.). Example housings and/or surfaces thereof may support one or more sensors (e.g., temperature sensors, vibration sensors, light sensors, acoustic sensors, capacitive sensors, proximity sensors, etc.). One or more such sensors may be contained in, carried by, or otherwise embedded in the surface and/or mounted to the surface of the appliance. Example housings and/or surfaces thereof may support mechanical connectivity, such as propulsion hardware (e.g., wheels, propellers, etc.) and/or articulating hardware (e.g., robot arms, pivotable appendages, etc.). In some circumstances, the sensors may include any type of input devices such as user interface hardware (e.g., buttons, switches, dials, sliders, etc.). In some circumstances, example housings include output devices contained in, carried by, embedded therein and/or attached thereto. Output devices may include displays, touchscreens, lights, LEDs, speakers, I/O ports (e.g., USB), etc. In some circumstances, edge devices are devices presented in the network for a specific purpose (e.g., a traffic light), but may have processing and/or other capacities that may be utilized for other purposes. Such edge devices may be independent from other networked devices and may be provided with a housing having a form factor suitable for its primary purpose; yet be available for other compute tasks that do not interfere with its primary task. Edge devices include Internet of Things devices. The appliance computing device may include hardware and software components to manage local issues such as device temperature, vibration, resource utilization, updates, power issues, physical and network security, etc. Example hardware for implementing an appliance computing device is described in conjunction with
In
In the illustrated example of
In some examples, one or more servers of the software distribution platform 1905 are communicatively connected to one or more security domains and/or security devices through which requests and transmissions of the example computer readable instructions 1960 must pass. In some examples, one or more servers of the software distribution platform 1905 periodically offer, transmit, and/or force updates to the software (e.g., the example computer readable instructions 1560 of
In the illustrated example of
Additional examples of the presently described method, system, and device embodiments include the following, non-limiting configurations. Each of the non-limiting examples may stand on its own, or may be combined in any permutation or combination with any one or more of the other examples provided below or throughout the present disclosure.
Example 1 includes a method to be performed by an ego Vulnerable Road User (VRU) Intelligent Transport System Station, (ITS-S), the method comprising: receiving, by the ego VRU ITS-S, a set of VRU Awareness Messages (VAMs) from a set of other VRUs; forming, by the ego VRU ITS-S, a new VRU cluster with one or more VRUs of the set of other VRUs based on one or more VAMs of the set of VAMs sent by the one or more VRUs; and joining, by the ego VRU ITS-S, an existing VRU cluster when one VAM of the set of VAMs is sent by a cluster head VRU of the set of other VRUs.
Example 2 includes the method of example 1 and/or some other example(s) herein, wherein forming the new VRU cluster comprises: sending, by the ego VRU ITS-S, a cluster formation VAM to the one or more VRUs indicating that the ego VRU ITS-S will lead the new VRU cluster and including a VRU cluster identifier of the new VRU cluster.
Example 3a includes the method of example 2 and/or some other example(s) herein, wherein the cluster formation VAM further includes one or more of bounding box information indicating a shape of the new VRU cluster, a cardinality size of the new VRU cluster, and profiles of the one or more VRUs making up the new VRU cluster.
Example 3b includes the method of examples 1-3a and/or some other example(s) herein, further comprising: performing a ‘Multiple CH Candidates Resolution’ mechanism when at least one other VRU ITS-S is a cluster head candidate.
Example 4 includes the method of examples 1-3b and/or some other example(s) herein, wherein forming the new VRU cluster comprises: determining, by the ego VRU ITS-S, to form the new VRU cluster when the ego VRU ITS-S has sufficient processing power as indicated in by a VRU configuration.
Example 5 includes the method of example 4 and/or some other example(s) herein, wherein forming the new VRU cluster comprises: determining, by the ego VRU ITS-S, to form the new VRU cluster when the ego VRU ITS-S includes both VRU transmission and VRU reception capabilities.
Example 6 includes the method of examples 4-5 and/or some other example(s) herein, wherein forming the new VRU cluster comprises: determining, by the ego VRU ITS-S, to form the new VRU cluster when a number of VAMs from different VRUs in the set of VAMs is same or larger than a configured number of VAMs and the one or more VRUs are at or less than a configured maximum distance from the ego VRU ITS-S.
Example 7 includes the method of examples 4-6 and/or some other example(s) herein, wherein forming the new VRU cluster comprises: determining, by the ego VRU ITS-S, to form the new VRU cluster when the ego VRU ITS-S has failed to identify an existing cluster it could join.
Example 8a includes the method of examples 4-7 and/or some other example(s) herein, wherein forming the new VRU cluster comprises: determining, by the ego VRU ITS-S, to form the new VRU cluster when the ego VRU ITS-S is located at a front most position of the new VRU cluster to be formed with respect to the one or more VRUs to be included in the new VRU cluster upon formation.
Example 8b includes the method of examples 4-8a and/or some other example(s) herein, wherein forming the new VRU cluster comprises: determining, by the ego VRU ITS-S, to form the new VRU cluster when the ego VRU ITS-S is a cluster head candidate among a plurality of cluster head candidates that has an earliest VAM generation time among the plurality of cluster head candidates, the VAM including a cluster head indication.
Example 9 includes the method of examples 2-8b and/or some other example(s) herein, further comprising: disbanding, by the ego VRU ITS-S, the new VRU cluster when the ego VRU ITS-S determines to disband the new VRU cluster.
Example 10 includes the method of examples 2-9 and/or some other example(s) herein, further comprising: determining, by the ego VRU ITS-S, whether the new VRU cluster is a homogeneous cluster or a heterogeneous cluster, wherein the new VRU cluster is a homogeneous cluster when the ego VRU ITS-S and the one or more VRUs have a same VRU profile, and the new VRU cluster is a heterogeneous cluster when at least one VRU of the one or more VRUs and the ego VRU ITS-S has a different VRU profile than other ones of the one or more VRUs and the ego VRU ITS-S.
Example 11 includes the method of examples 2-10 and/or some other example(s) herein, further comprising: determining a cluster profile for the new VRU cluster, a size of the new VRU cluster, a speed of the new VRU cluster, and a reference position of the new VRU cluster, the reference position of the new VRU cluster is a ground position at a center point of the new VRU cluster.
Example 12a includes the method of examples 2-11 and/or some other example(s) herein, wherein disbanding the new VRU cluster comprises: sending, by the ego VRU ITS-S a predefined number of times consecutively, a cluster disbandment VAM to the one or more VRUs indicating that the ego VRU ITS-S will disband the new VRU cluster and including the VRU cluster identifier of the new VRU cluster.
Example 12b includes the method of examples 2-12a and/or some other example(s) herein, further comprising: determining, by the ego VRU ITS-S, whether another VRU cluster and the new VRU cluster have coherent cluster velocity profiles and has a bounding box that is, or is about to, fully or partially overlap with a bounding box of the new VRU cluster; and sending, by the ego VRU ITS-S, one or more additional VAMs to merge the new VRU cluster with the other VRU cluster having the coherent cluster velocity profile.
Example 13 includes the method of examples 1-12b and/or some other example(s) herein, wherein joining the existing VRU cluster comprises: sending, by the ego VRU ITS-S, a cluster join VAM to the cluster head including a cluster join indication and a VRU cluster identifier of the existing VRU cluster, the cluster join indication indicating that the ego VRU ITS-S is joining the existing VRU cluster; and stopping, by the ego VRU ITS-S, transmission of any VAMs after sending the cluster join VAM; and monitoring, by the ego VRU ITS-S, for VAMs from the cluster head VRU.
Example 14 includes the method of example 13 and/or some other example(s) herein, further comprising: receiving, by the ego VRU ITS-S from the cluster head VRU, another VAM including cluster bounding box information of the existing VRU cluster.
Example 15 includes the method of examples 13-14 and/or some other example(s) herein, further comprising: comparing, by the ego VRU ITS-S, a measured position and speed of the ego VRU ITS-S with a cluster position and speed indicated in the VAM from the cluster head VRU; and determining, by the ego VRU ITS-S, to join the existing VRU cluster when the measured position and speed and the cluster position and speed is within a predefined threshold position and speed based on the comparison.
Example 16 includes the method of example 15 and/or some other example(s) herein, further comprising: comparing, by the ego VRU ITS-S, a measured position and speed of the ego VRU ITS-S with a cluster position and speed indicated in the VAM from the cluster head VRU; and determining, by the ego VRU ITS-S, to leave the existing VRU cluster when the measured position and speed and the cluster position and speed is outside of the predefined threshold position and speed based on the comparison.
Example 17 includes the method of examples 15-16 and/or some other example(s) herein, wherein the predefined threshold position and speed comprises a difference of about 3 to 5 meters between the ego VRU ITS-S and a reference position of the existing VRU cluster and speed difference of less than about 5% between the speed of the ego VRU ITS-S and a coherent velocity of the existing VRU cluster.
Example 18 includes the method of examples 16-17 and/or some other example(s) herein, wherein the cluster join indication is included in a cluster operation container of the cluster join VAM, and the method further comprises: when the ego VRU ITS-S determines to leave the existing VRU cluster, generating a cluster leave VAM including a cluster leave indication in a cluster operation container of the cluster leave VAM.
Example 18b includes the method of examples 13-18a and/or some other example(s) herein, further comprising: continuously monitoring, by the ego VRU ITS-S, for a VAM from the cluster head; and resume transmission of one or more VAMs when there is no VAM from the cluster head for a predefined period of time.
Example 19a includes the method of examples 1-18 and/or some other example(s) herein, wherein the ego VRU ITS-S includes a VRU basic service (VBS), the VBS being a facilities layer entity, and the VBS includes a cluster management function to determine whether to join the existing VRU cluster or to form the new VRU cluster.
Example 19b includes the method of examples 1-19a and/or some other example(s) herein, wherein the VBS is in one of a VRU-IDLE state, a VRU-ACTIVE-STANDALONE state, a VRU-ACTIVE-CLUSTER-LEADER state, or a VRU-PASSIVE state.
Example 19c includes the method of example 19b and/or some other example(s) herein, wherein the VBS is in the VRU-IDLE state when the ego VRU ITS-S is not considered as a VRU.
Example 19d includes the method of examples 19b-19c and/or some other example(s) herein, wherein the VBS is in the VRU-ACTIVE-STANDALONE state when VAMs or cooperative awareness messages (CAMs) are transmitted with information related to only the ego VRU ITS-S.
Example 19e includes the method of examples 19b-19d and/or some other example(s) herein, wherein the VBS is in the VRU-ACTIVE-CLUSTER-LEADER state when the VAMs include the cluster-related containers.
Example 19f includes the method of examples 19b-19e and/or some other example(s) herein, wherein the VBS is in the VRU-PASSIVE state when the ego VRU ITS-S does not transmit any VAMs.
Example 20 includes the method of examples 1-19f and/or some other example(s) herein, further comprising: executing a collision risk analysis function to analyze a motion dynamic prediction of considered moving objects associated to respective confidence levels, and determine a Trajectory Interception Indicator (TII) based on the analysis, the TII indicating a the likelihood that the ego VRU ITS-S and one or more other VRUs, non-VRUs, or objects on a road are going to collide; executing a collision risk avoidance function to determine a collision avoidance strategy according to the TII, visibility conditions, vehicle stability conditions, and vehicle braking capabilities; and executing a maneuver coordination function to execute collision avoidance actions of the collision avoidance strategy.
Example 21 includes the method of example 20 and/or some other example(s) herein, further comprising: executing the maneuver coordination function to send the TII and a Maneuver Identifier (MI) to one or more neighboring VRUs, the MI identifying or indicating a set of maneuvers to be used to avoid potential collision indicated by the TII.
Example 22 includes the method of example 21 and/or some other example(s) herein, wherein the TII is expressed as a range of probabilities to indicate a likelihood of a path of the ego VRU ITS-S to be intercepted by another entity.
Example 23 includes the method of examples 21-22 and/or some other example(s) herein, wherein or the TII is a TII index that indicates a likelihood of potential trajectory interception as being one of low, medium, high, or very high.
Example 24 includes the method of examples 21-23 and/or some other example(s) herein, wherein the set of maneuvers indicated by the MI include one or more of one or more longitudinal trajectory change maneuvers, one or more lateral trajectory change maneuvers, one or more heading change maneuvers, deceleration, and emergency braking.
Example 25 includes the method of examples 1-24 and/or some other example(s) herein, further comprising: generating one or more VAMs to include one or more of: a VRU low frequency (LF) container containing static or slow-changing vehicle data; a VRU high frequency (HF) container containing potentially fast-changing status information of the ego VRU ITS-S; and a VRU motion prediction container containing dynamic VRU motion prediction information and an explicit path prediction.
Example 26 includes the method of example 25 and/or some other example(s) herein, further comprising: generating one or more VAMs to include the VRU LF container, wherein the VRU LF container includes a VRU profile and subprofile data element (DE) to identify a profile and sub-profile of the ego VRU ITS-S.
Example 27 includes the method of example 26 and/or some other example(s) herein, wherein the VRU profile and subprofile data DE includes or indicates a profile index and a sub-profile index to indicate the profile and sub-profile, respectively.
Example 28 includes the method of example 27 and/or some other example(s) herein, wherein the VRU profile index is “1” to indicate a pedestrian VRU profile, and the sub-profile index is one of: “0” to indicate “unavailable”, “1” to indicate “ordinary person”, “2” to indicate “road worker”, or “3” to indicate “first responder”.
Example 29 includes the method of example 27 and/or some other example(s) herein, wherein the VRU profile index is “2” to indicate a bicyclist VRU profile, and the sub-profile index is one of: “0” to indicate “unavailable”, “1” to indicate “Bicyclist”, “2” to indicate “Wheelchair User”, “3” to indicate “horse and rider”, “4” to indicate “Rollerskater”, “5” to indicate “Standing E-Scooter”, “6” to indicate “Personal Transporter”, “7” to indicate “E-Bicyclist (Pedelec), up to 25 km/h”, or “8” to indicate “E-Bicyclist (Speed-Pedelec), up to 45 km/h”.
Example 30 includes the method of example 27 and/or some other example(s) herein, wherein the VRU profile index is “3” to indicate a Motorcyclist VRU profile, and the sub-profile index is one of: “0” to indicate “unavailable”, “1” to indicate “Moped”, “2” to indicate “Motorcycle”, “3” to indicate “Motorcycle+sidecar right”, “4” to indicate “Motorcycle+sidecar left”, or “5” to indicate “Seated E-scooter”.
Example 31 includes the method of example 27 and/or some other example(s) herein, wherein the VRU profile index is “4” to indicate an Animal VRU profile, and the sub-profile index is one of: “0” to indicate “unavailable”, “1” to indicate “wild animal”, “2” to indicate “farm animal”, or “3” to indicate “service animal”.
Example 32 includes the method of examples 27-31 and/or some other example(s) herein, wherein the VRU profile and subprofile data DE further includes another sub-profile index to indicate a speed range, environment, or weight category of the ego VRU ITS-S.
Example Z01 includes one or more computer readable media comprising instructions, wherein execution of the instructions by processor circuitry is to cause the processor circuitry to perform the method of any one of examples 1-32 and/or some other example(s) herein.
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.
Example Z03b includes an API or specification defining functions, methods, variables, data structures, protocols, etc., defining or involving use of any of examples 1-32 or portions thereof, or otherwise related to any of examples 1-32 or portions thereof.
Example Z04 includes an apparatus comprising circuitry loaded with the instructions of example Z01.
Example Z05 includes an apparatus comprising circuitry operable to run the instructions of example Z01.
Example Z06 includes an integrated circuit comprising one or more of the processor circuitry of example Z01 and the one or more computer readable media of example Z01.
Example Z07 includes a computing system comprising the one or more computer readable media and the processor circuitry 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.
Example Z11 includes the data unit of example Z10 and/or some other example(s) herein, wherein the data unit is a datagram, network packet, data frame, data segment, a Protocol Data Unit (PDU), a Service Data Unit (SDU), a message, or a database object.
Example Z12 includes a signal encoded with the data unit of examples Z10 and/or Z11. Example Z13 includes an electromagnetic signal carrying the instructions of example Z01. Example Z14 includes an apparatus comprising means for performing the method of any one of examples 1-32 and/or some other example(s) herein. Example Z15, includes a Multi-access Edge Computing (MEC) host executing a service as part of one or more MEC applications instantiated on a virtualization infrastructure, the service being related to any of examples 1-32 or portions thereof and/or some other example(s) herein, and wherein the MEC host is configurable or operable to operate according to a standard from one or more ETSI MEC standards families.
Any of the above-described examples may be combined with any other example (or combination of examples), unless explicitly stated otherwise. Implementation of the preceding techniques may be accomplished through any number of specifications, configurations, or example deployments of hardware and software. It should be understood that the functional units or capabilities described in this specification may have been referred to or labeled as components or modules, in order to more particularly emphasize their implementation independence. Such components may be embodied by any number of software or hardware forms. For example, a component or module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A component or module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. Components or modules may also be implemented in software for execution by various types of processors. An identified component or module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified component or module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the component or module and achieve the stated purpose for the component or module.
Indeed, a component or module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices or processing systems. In particular, some aspects of the described process (such as code rewriting and code analysis) may take place on a different processing system (e.g., in a computer in a data center), than that in which the code is deployed (e.g., in a computer embedded in a sensor or robot). Similarly, operational data may be identified and illustrated herein within components or modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The components or modules may be passive or active, including agents operable to perform desired functions.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The present disclosure has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and/or computer program products according to embodiments of the present disclosure. In the drawings, some structural or method features may be shown in specific arrangements and/or orderings. However, it should be appreciated that such specific arrangements and/or orderings may not be required. Rather, in some embodiments, such features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of a structural or method feature in a particular figure is not meant to imply that such feature is required in all embodiments and, in some embodiments, may not be included or may be combined with other features.
As used herein, the singular forms “a,” “an” and “the” are intended to include plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specific the presence of 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, operation, elements, components, and/or groups thereof. The phrase “A and/or B” means (A), (B), or (A and B). For the purposes of the present 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 description may use the phrases “in an embodiment,” or “In some embodiments,” which may each refer to one or more of the same or different embodiments. Furthermore, the terms “comprising,” “including,” “having,” and the like, as used with respect to embodiments of the present disclosure, are synonymous.
The terms “coupled,” “communicatively coupled,” along with derivatives thereof are used herein. The term “coupled” may mean two or more elements are in direct physical or electrical contact with one another, may mean that two or more elements indirectly contact each other but still cooperate or interact with each other, and/or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other. The term “directly coupled” may mean that two or more elements are in direct contact with one another. The term “communicatively coupled” may mean that two or more elements may be in contact with one another by a means of communication including through a wire or other interconnect connection, through a wireless communication channel or ink, and/or the like.
The term “circuitry” refers to a circuit or system of multiple circuits configured to perform a particular function in an electronic device. The circuit or system of circuits may be part of, or include one or more hardware components, such as a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an ASIC, a FPGA, programmable logic controller (PLC), SoC, SiP, multi-chip package (MCP), DSP, etc., that are configured to provide the described functionality. In addition, the term “circuitry” may also refer to a combination of one or more hardware elements with the program code used to carry out the functionality of that program code. Some types of circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. Such a combination of hardware elements and program code may be referred to as a particular type of circuitry.
It should be understood that the functional units or capabilities described in this specification may have been referred to or labeled as components or modules, in order to more particularly emphasize their implementation independence. Such components may be embodied by any number of software or hardware forms. For example, a component or module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A component or module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. Components or modules may also be implemented in software for execution by various types of processors. An identified component or module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified component or module need not be physically located together but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the component or module and achieve the stated purpose for the component or module.
Indeed, a component or module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices or processing systems. In particular, some aspects of the described process (such as code rewriting and code analysis) may take place on a different processing system (e.g., in a computer in a data center) than that in which the code is deployed (e.g., in a computer embedded in a sensor or robot). Similarly, operational data may be identified and illustrated herein within components or modules and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The components or modules may be passive or active, including agents operable to perform desired functions.
The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and/or transferring digital data. The term “processor circuitry” may 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 to, and may be referred to as, “processor circuitry.”
The term “memory” and/or “memory circuitry” as used herein refers to one or more hardware devices for storing data, including RAM, MRAM, PRAM, DRAM, and/or SDRAM, core memory, ROM, magnetic disk storage mediums, optical storage mediums, flash memory devices or other machine readable mediums for storing data. The term “computer-readable medium” may include, but is not limited to, memory, portable or fixed storage devices, optical storage devices, and various other mediums capable of storing, containing or carrying instructions or data.
The term “interface circuitry” as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I/O interfaces, peripheral component interfaces, network interface cards, and/or the like.
The term “element” refers to a unit that is indivisible at a given level of abstraction and has a clearly defined boundary, wherein an element may 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 embedded inside, or attached to, another physical entity in its vicinity, with capabilities to convey digital information from or to that 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 that has the capability to affect a physical entity, such as by changing its state or causing the physical entity to move.
As used herein, the term “edge computing” encompasses many implementations of distributed computing that move processing activities and resources (e.g., compute, storage, acceleration resources) towards the “edge” of the network, in an effort to reduce latency and increase throughput for endpoint users (client devices, user equipment, etc.). Such edge computing implementations typically involve the offering of such activities and resources in cloud-like services, functions, applications, and subsystems, from one or multiple locations accessible via wireless networks. Thus, the references to an “edge” of a network, cluster, domain, system or computing arrangement used herein are groups or groupings of functional distributed compute elements and, therefore, generally unrelated to “edges” (links or connections) as used in graph theory. Specific arrangements of edge computing applications and services accessible via mobile wireless networks (e.g., cellular and WiFi data networks) may be referred to as “mobile edge computing” or “multi-access edge computing”, which may be referenced by the acronym “MEC”. The usage of “MEC” herein may also refer to a standardized implementation promulgated by the European Telecommunications Standards Institute (ETSI), referred to as “ETSI MEC”. Terminology that is used by the ETSI MEC specification is generally incorporated herein by reference, unless a conflicting definition or usage is provided herein.
As used herein, the term “compute node” or “compute device” refers to an identifiable entity implementing an aspect of edge computing operations, whether part of a larger system, distributed collection of systems, or a standalone apparatus. In some examples, a compute node may be referred to as a “edge node”, “edge device”, “edge system”, whether in operation as a client, server, or intermediate entity. Specific implementations of a compute node may be incorporated into a server, base station, gateway, road side unit, on premise unit, UE or end consuming device, or the like.
The term “computer system” as used herein refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” and/or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” and/or “system” may refer to multiple computer devices and/or multiple computing systems that are communicatively coupled with one another and configured to share computing and/or networking resources.
The term “architecture” as used herein refers to a computer architecture or a network architecture. A “network architecture” is a physical and logical design or arrangement of software and/or hardware elements in a network including communication protocols, interfaces, and media transmission. A “computer architecture” is a physical and logical design or arrangement of software and/or hardware elements in a computing system or platform including technology standards for interacts therebetween.
The term “appliance,” “computer appliance,” or the like, as used herein refers to a computer device or computer system with program code (e.g., software or firmware) that is specifically designed to provide a specific computing resource. A “virtual appliance” is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or otherwise is dedicated to provide a specific computing resource.
The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, 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, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc.
Furthermore, the term “user equipment” or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface. The term “station” or “STA” refers to a logical entity that is a singly addressable instance of a medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). The term “wireless medium” or WM″ refers to the medium used to implement the transfer of protocol data units (PDUs) between peer physical layer (PHY) entities of a wireless local area network (LAN).
The term “network element” as used herein refers to physical or virtualized equipment and/or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, and/or the like.
As used herein, the term “access point” or “AP” refers to an entity that contains one station (STA) and provides access to the distribution services, via the wireless medium (WM) for associated STAs. An AP comprises a STA and a distribution system access function (DSAF). As used herein, the term “base station” refers to a network element in a radio access network (RAN), such as a fourth-generation (4G) or fifth-generation (5G) mobile communications network which is responsible for the transmission and reception of radio signals in one or more cells to or from a user equipment (UE). A base station can have an integrated antenna or may be connected to an antenna array by feeder cables. A base station uses specialized digital signal processing and network function hardware. In some examples, the base station may be split into multiple functional blocks operating in software for flexibility, cost, and performance. In some examples, a base station can include an evolved node-B (eNB) or a next generation node-B (gNB). In some examples, the base station may operate or include compute hardware to operate as a compute node. However, in many of the scenarios discussed herein, a RAN base station may be substituted with an access point (e.g., wireless network access point) or other network access hardware.
As used herein, the term “central office” (or CO) indicates an aggregation point for telecommunications infrastructure within an accessible or defined geographical area, often where telecommunication service providers have traditionally located switching equipment for one or multiple types of access networks. The CO can be physically designed to house telecommunications infrastructure equipment or compute, data storage, and network resources. The CO need not, however, be a designated location by a telecommunications service provider. The CO may host any number of compute devices for edge applications and services, or even local implementations of cloud-like services.
The term “cloud computing” or “cloud” refers to a paradigm for enabling network access to a scalable and elastic pool of shareable computing resources with self-service provisioning and administration on-demand and without active management by users. Cloud computing provides cloud computing services (or cloud services), which are one or more capabilities offered via cloud computing that are invoked using a defined interface (e.g., an API or the like). The term “computing resource” or simply “resource” refers to any physical or virtual component, or usage of such components, of limited availability within a computer system or network. Examples of computing resources include usage/access to, for a period of time, servers, processor(s), storage equipment, memory devices, memory areas, networks, electrical power, input/output (peripheral) devices, mechanical devices, network connections (e.g., channels/links, ports, network sockets, etc.), operating systems, virtual machines (VMs), software/applications, computer files, and/or the like. A “hardware resource” may refer to compute, storage, and/or network resources provided by physical hardware element(s). A “virtualized resource” may refer to compute, storage, and/or network resources provided by virtualization infrastructure to an application, device, system, etc. The term “network resource” or “communication resource” may refer to resources that are accessible by computer devices/systems via a communications network. The term “system resources” may refer to any kind of shared entities to provide services, and may include computing and/or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.
The term “workload” refers to an amount of work performed by a computing system, device, entity, etc., during a period of time or at a particular instant of time. A workload may be represented as a benchmark, such as a response time, throughput (e.g., how much work is accomplished over a period of time), and/or the like. Additionally or alternatively, the workload may be represented as a memory workload (e.g., an amount of memory space needed for program execution to store temporary or permanent data and to perform intermediate computations), processor workload (e.g., a number of instructions being executed by a processor during a given period of time or at a particular time instant), an I/O workload (e.g., a number of inputs and outputs or system accesses during a given period of time or at a particular time instant), database workloads (e.g., a number of database queries during a period of time), a network-related workload (e.g., a number of network attachments, a number of mobility updates, a number of radio link failures, a number of handovers, an amount of data to be transferred over an air interface, etc.), and/or the like. Various algorithms may be used to determine a workload and/or workload characteristics, which may be based on any of the aforementioned workload types.
As used herein, the term “cloud service provider” (or CSP) indicates an organization which operates typically large-scale “cloud” resources comprised of centralized, regional, and edge data centers (e.g., as used in the context of the 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 offered by a CSP or a CSO, at remote locations with at least some increased latency, distance, or constraints relative to edge computing.
As used herein, the term “data center” refers to a purpose-designed structure that is intended to house multiple high-performance compute and data storage nodes such that a large amount of compute, data storage and network resources are present at a single location. This often entails specialized rack and enclosure systems, suitable heating, cooling, ventilation, security, fire suppression, and power delivery systems. The term may also refer to a compute and data storage node in some contexts. A data center may vary in scale between a centralized or cloud data center (e.g., largest), regional data center, and edge data center (e.g., smallest).
As used herein, the term “access edge layer” indicates the sub-layer of infrastructure edge closest to the end user or device. For example, such layer may be fulfilled by an edge data center deployed at a cellular network site. The access edge layer functions as the front line of the infrastructure edge and may connect to an aggregation edge layer higher in the hierarchy.
As used herein, the term “aggregation edge layer” indicates the layer of infrastructure edge one hop away from the access edge layer. This layer can exist as either a medium-scale data center in a single location or may be formed from multiple interconnected micro data centers to form a hierarchical topology with the access edge to allow for greater collaboration, workload failover, and scalability than access edge alone.
As used herein, the term “network function virtualization” (or NFV) indicates the migration of NFs from embedded services inside proprietary hardware appliances to software-based virtualized NFs (or VNFs) running on standardized CPUs (e.g., within standard x86® and ARM® servers, such as those including Intel® Xeon™ or AMD® Epyc™ or Opteron™ processors) using industry standard virtualization and cloud computing technologies. In some aspects, NFV processing and data storage will occur at the edge data centers that are connected directly to the local cellular site, within the infrastructure edge.
As used herein, the term “virtualized NF” (or VNF) indicates a software-based NF operating on multi-function, multi-purpose compute resources (e.g., x86, ARM processing architecture) which are used by NFV in place of dedicated physical equipment. In some aspects, several VNFs will operate on an edge data center at the infrastructure edge.
As used herein, the term “edge computing” refers to the implementation, coordination, and use of computing and resources at locations closer to the “edge” or collection of “edges” of a network. Deploying computing resources at the network's edge may reduce application and network latency, reduce network backhaul traffic and associated energy consumption, improve service capabilities, improve compliance with security or data privacy requirements (especially as compared to conventional cloud computing), and improve total cost of ownership). As used herein, the term “edge compute node” refers to a real-world, logical, or virtualized implementation of a compute-capable element in the form of a device, gateway, bridge, system or subsystem, component, whether operating in a server, client, endpoint, or peer mode, and whether located at an “edge” of an network or at a connected location further within the network. References to a “node” used herein are generally interchangeable with a “device”, “component”, and “sub-system”; however, references to an “edge computing system” or “edge computing network” generally refer to a distributed architecture, organization, or collection of multiple nodes and devices, and which is organized to accomplish or offer some aspect of services or resources in an edge computing setting.
The term “Internet of Things” or “IoT” refers to a system of interrelated computing devices, mechanical and digital machines capable of transferring data with little or no human interaction, and may involve technologies such as real-time analytics, machine learning and/or AI, embedded systems, wireless sensor networks, control systems, automation (e.g., smart home, smart building and/or smart city technologies), and the like. IoT devices are usually low-power devices without heavy compute or storage capabilities. “Edge IoT devices” may be any kind of IoT devices deployed at a network's edge.
As used herein, the term “cluster” refers to a set or grouping of entities as part of an edge computing system (or systems), in the form of physical entities (e.g., different computing systems, networks or network groups), logical entities (e.g., applications, functions, security constructs, containers), and the like. In some locations, a “cluster” is also referred to as a “group” or a “domain”. The membership of cluster may be modified or affected based on conditions or functions, including from dynamic or property-based membership, from network or system management scenarios, or from various example techniques discussed below which may add, modify, or remove an entity in a cluster. Clusters may also include or be associated with multiple layers, levels, or properties, including variations in security features and results based on such layers, levels, or properties.
As used herein, the term “radio technology” refers to technology for wireless transmission and/or reception of electromagnetic radiation for information transfer. The term “radio access technology” or “RAT” refers to the technology used for the underlying physical connection to a radio based communication network. The term “V2X” refers to vehicle to vehicle (V2V), vehicle to infrastructure (V2I), infrastructure to vehicle (I2V), vehicle to network (V2N), and/or network to vehicle (N2V) communications and associated radio access technologies.
As used herein, the term “communication protocol” (either wired or wireless) refers to a set of standardized rules or instructions implemented by a communication device and/or system to communicate with other devices and/or systems, including instructions for packetizing/depacketizing data, modulating/demodulating signals, implementation of protocols stacks, and/or the like.
The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with and/or equivalent to “communications channel,” “data communications channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier,” “radiofrequency carrier,” and/or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information.
As used herein, the term “radio technology” refers to technology for wireless transmission and/or reception of electromagnetic radiation for information transfer. The term “radio access technology” or “RAT” refers to the technology used for the underlying physical connection to a radio based communication network.
As used herein, the term “communication protocol” (either wired or wireless) refers to a set of standardized rules or instructions implemented by a communication device and/or system to communicate with other devices and/or systems, including instructions for packetizing/depacketizing data, modulating/demodulating signals, implementation of protocols stacks, and/or the like. Examples of wireless communications protocols may be used in various embodiments include a Global System for Mobile Communications (GSM) radio communication technology, a General Packet Radio Service (GPRS) radio communication technology, an Enhanced Data Rates for GSM Evolution (EDGE) radio communication technology, and/or a Third Generation Partnership Project (3GPP) radio communication technology including, for example, 3GPP Fifth Generation (5G) or New Radio (NR), Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), Long Term Evolution (LTE), LTE-Advanced (LTE Advanced), LTE Extra, LTE-A Pro, cdmaOne (2G), Code Division Multiple Access 2000 (CDMA 2000), Cellular Digital Packet Data (CDPD), Mobitex, Circuit Switched Data (CSD), High-Speed CSD (HSCSD), Universal Mobile Telecommunications System (UMTS), Wideband Code Division Multiple Access (W-CDM), High Speed Packet Access (HSPA), HSPA Plus (HSPA+), Time Division-Code Division Multiple Access (TD-CDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), LTE LAA, MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UTRA (E-UTRA), Evolution-Data Optimized or Evolution-Data Only (EV-DO), Advanced Mobile Phone System (AMPS), Digital AMPS (D-AMPS), Total Access Communication System/Extended Total Access Communication System (TACS/ETACS), Push-to-talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), Cellular Digital Packet Data (CDPD), DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Personal Handy-phone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA), also referred to as also referred to as 3GPP Generic Access Network, or GAN standard), Bluetooth®, Bluetooth Low Energy (BLE), IEEE 802.15.4 based protocols (e.g., IPv6 over Low power Wireless Personal Area Networks (6LoWPAN), WirelessHART, MiWi, Thread, 802.11a, etc.) WiFi-direct, ANT/ANT+, ZigBee, Z-Wave, 3GPP device-to-device (D2D) or Proximity Services (ProSe), Universal Plug and Play (UPnP), Low-Power Wide-Area-Network (LPWAN), Long Range Wide Area Network (LoRA) or LoRaWAN™ developed by Semtech and the LoRa Alliance, Sigfox, Wireless Gigabit Alliance (WiGig) standard, Worldwide Interoperability for Microwave Access (WiMAX), mmWave standards in general (e.g., wireless systems operating at 10-300 GHz and above such as WiGig, IEEE 802.11ad, IEEE 802.11ay, etc.), V2X communication technologies (including C-V2X), Dedicated Short Range Communications (DSRC) communication systems such as Intelligent-Transport-Systems (ITS) including the European ITS-G5, ITS-GSB, ITS-GSC, etc. In addition to the standards listed above, any number of satellite uplink technologies may be used for purposes of the present disclosure including, for example, radios compliant with standards issued by the International Telecommunication Union (ITU), or the European Telecommunications Standards Institute (ETSI), among others. The examples provided herein are thus understood as being applicable to various other communication technologies, both existing and not yet formulated.
The term “V2X” refers to vehicle to vehicle (V2V), vehicle to infrastructure (V2I), infrastructure to vehicle (I2V), vehicle to network (V2N), and/or network to vehicle (N2V) communications and associated radio access technologies.
The term “localized network” as used herein may refer to a local network that covers a limited number of connected vehicles in a certain area or region. The term “distributed computing” as used herein may refer to computation resources that are geographically distributed within the vicinity of one or more localized networks' terminations. The term “local data integration platform” as used herein may refer to a platform, device, system, network, or element(s) that integrate local data by utilizing a combination of localized network(s) and distributed computation.
The terms “instantiate,” “instantiation,” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code. The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content. The term “database object”, “data structure”, or the like may refer to any representation of information that is in the form of an object, attribute-value pair (AVP), key-value pair (KVP), tuple, etc., and may include variables, data structures, functions, methods, classes, database records, database fields, database entities, associations between data and/or database entities (also referred to as a “relation”), blocks and links between blocks in block chain implementations, and/or the like. The term “data element” or “DE” refers to a data type that contains one single data. The term “data frame” or “DF” refers to a data type that contains more than one data element in a predefined order.
As used herein, the term “reliability” refers to the ability of a computer-related component (e.g., software, hardware, or network element/entity) to consistently perform a desired function and/or operate according to a specification. Reliability in the context of network communications (e.g., “network reliability”) may refer to the ability of a network to carry out communication. Network reliability may also be (or be a measure of) the probability of delivering a specified amount of data from a source to a destination (or sink).
The term “application” may refer to a complete and deployable package, environment to achieve a certain function in an operational environment. The term “AI/ML application” or the like may be an application that contains some AI/ML models and application-level descriptions. The term “machine learning” or “ML” refers to the use of computer systems implementing algorithms and/or statistical models to perform specific task(s) without using explicit instructions, but instead relying on patterns and inferences. ML algorithms build or estimate mathematical model(s) (referred to as “ML models” or the like) based on sample data (referred to as “training data,” “model training information,” or the like) in order to make predictions or decisions without being explicitly programmed to perform such tasks. Generally, an ML algorithm is a computer program that learns from experience with respect to some task and some performance measure, and an ML model may be any object or data structure created after an ML algorithm is trained with one or more training datasets. After training, an ML model may be used to make predictions on new datasets. Although the term “ML algorithm” refers to different concepts than the term “ML model,” these terms as discussed herein may be used interchangeably for the purposes of the present disclosure. The term “session” refers to a temporary and interactive information interchange between two or more communicating devices, two or more application instances, between a computer and user, or between any two or more entities or elements.
The term “ego” used with respect to an element or entity, such as “ego ITS-S” or the like, refers to an ITS-S that is under consideration, the term “ego vehicle” refers to a vehicle embedding an ITS-S being considered, and the term “neighbors” or “proximity” used to describe elements or entities refers to other ITS-Ss different than the ego ITS-S and/or ego vehicle.
The term “Interoperability” refers to the ability of ITS-Ss utilizing one communication system or RAT to communicate with other ITS-Ss utilizing another communication system or RAT. The term “Coexistence” refers to sharing or allocating radiofrequency resources among ITS-Ss using either communication system or RAT.
The term “ITS data dictionary” refers to a repository of DEs and DFs used in the ITS applications and ITS facilities layer. The term “ITS message” refers to messages exchanged at ITS facilities layer among ITS stations or messages exchanged at ITS applications layer among ITS stations.
The term “Collective Perception” or “CP” refers to the concept of sharing the perceived environment of an ITS-S based on perception sensors, wherein an ITS-S broadcasts information about its current (driving) environment. CP is the concept of actively exchanging locally perceived objects between different ITS-Ss by means of a V2X RAT. CP decreases the ambient uncertainty of ITS-Ss by contributing information to their mutual FoVs. The term “Collective Perception basic service” (also referred to as CP service (CPS)) refers to a facility at the ITS-S facilities layer to receive and process CPMs, and generate and transmit CPMs. The term “Collective Perception Message” or “CPM” refers to a CP basic service PDU. The term “Collective Perception data” or “CPM data” refers to a partial or complete CPM payload. The term “Collective Perception protocol” or “CPM protocol” refers to an ITS facilities layer protocol for the operation of the CPM generation, transmission, and reception. The term “CP object” or “CPM object” refers to aggregated and interpreted abstract information gathered by perception sensors about other traffic participants and obstacles. CP/CPM Objects can be represented mathematically by a set of variables describing, amongst other, their dynamic state and geometric dimension. The state variables associated to an object are interpreted as an observation for a certain point in time and are therefore always accompanied by a time reference. The term “Environment Model” refers to a current representation of the immediate environment of an ITS-S, including all perceived objects perceived by either local perception sensors or received by V2X. The term “object”, in the context of the CP Basic Service, refers to the state space representation of a physically detected object within a sensor's perception range. The term “object list” refers to a collection of objects temporally aligned to the same timestamp.
The term “ITS Central System” refers to an ITS system in the backend, for example, traffic control center, traffic management center, or cloud system from road authorities, ITS application suppliers or automotive OEMs (see e.g., clause 4.5.1.1 of [EN302665]).
The term “personal ITS-S” refers to an ITS-S in a nomadic ITS sub-system in the context of a portable device (e.g., a mobile device of a pedestrian).
The term “vehicle” may refer to road vehicle designed to carry people or cargo on public roads and highways such as AVs, busses, cars, trucks, vans, motor homes, and motorcycles; by water such as boats, ships, etc.; or in the air such as airplanes, helicopters, UAVs, satellites, etc.
The term “sensor measurement” refers to abstract object descriptions generated or provided by feature extraction algorithm(s), which may be based on the measurement principle of a local perception sensor mounted to an ITS-S. The feature extraction algorithm processes a sensor's raw data (e.g., reflection images, camera images, etc.) to generate an object description. The term “State Space Representation” is a mathematical description of a detected object, which includes state variables such as distance, speed, object dimensions, and the like. The state variables associated with/to an object are interpreted as an observation for a certain point in time, and therefore, are accompanied by a time reference.
The term “maneuvers” or “manoeuvres” refer to specific and recognized movements bringing an actor, e.g., pedestrian, vehicle or any other form of transport, from one position to another within some momentum (velocity, velocity variations and vehicle mass). The term “Maneuver Coordination” or “MC” refers to the concept of sharing, by means of a V2X RAT, an intended movement or series of intended movements of an ITS-S based on perception sensors, planned trajectories, and the like, wherein an ITS-S broadcasts information about its current intended maneuvers. The term “Maneuver Coordination basic service” (also referred to as Maneuver Coordination Service (MCS)) refers to a facility at the ITS-S facilities layer to receive and process MCMs, and generate and transmit MCMs. The term “Maneuver Coordination Message” or “MCM” refers to an MC basic service PDU. The term “Maneuver Coordination data” or “MCM data” refers to a partial or complete MCM payload. The term “Maneuver Coordination protocol” or “MCM protocol” refers to an ITS facilities layer protocol for the operation of the MCM generation, transmission, and reception. The term “MC object” or “MCM object” refers to aggregated and interpreted abstract information gathered by perception sensors about other traffic participants and obstacles, as well as information from applications and/or services operated or consumed by an ITS-S.
Although many of the previous examples are provided with use of specific cellular/mobile network terminology, including with the use of 4G/5G 3GPP network components (or expected terahertz-based 6G/6G+ technologies), it will be understood these examples may be applied to many other deployments of wide area and local wireless networks, as well as the integration of wired networks (including optical networks and associated fibers, transceivers, etc.). Furthermore, various standards (e.g., 3GPP, ETSI, etc.) may define various message formats, PDUs, containers, frames, etc., as comprising a sequence of optional or mandatory data elements (DEs), data frames (DFs), information elements (IEs), and/or the like. However, it should be understood that the requirements of any particular standard should not limit the embodiments discussed herein, and as such, any combination of containers, frames, DFs, DEs, IEs, values, actions, and/or features are possible in various embodiments, including any combination of containers, DFs, DEs, values, actions, and/or features that are strictly required to be followed in order to conform to such standards or any combination of containers, frames, DFs, DEs, IEs, values, actions, and/or features strongly recommended and/or used with or in the presence/absence of optional elements
Although these implementations have been described with reference to specific exemplary aspects, it will be evident that various modifications and changes may be made to these aspects without departing from the broader scope of the present disclosure. Many of the arrangements and processes described herein can be used in combination and/or in parallel implementations. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show, by way of illustration, and not of limitation, specific aspects in which the subject matter may be practiced. The aspects illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other aspects may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure.
Such aspects of the inventive subject matter may be referred to herein, individually and/or collectively, merely for convenience and without intending to voluntarily limit the scope of this application to any single aspect or inventive concept if more than one is in fact disclosed. This disclosure is intended to cover any and all adaptations or variations of various aspects. Combinations of the above aspects and other aspects not specifically described herein will be apparent to those of skill in the art upon reviewing the above description. The present disclosure is not to be taken in a limiting sense, and the scope of various aspects is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
The present application claims priority to U.S. Provisional App. No. 62/957,749 filed Jan. 6, 2020, U.S. Provisional App. No. 62/957,752 filed Jan. 6, 2020, and U.S. Provisional App. No. 62/967,874 filed Jan. 30, 2020, the contents of each of which are hereby incorporated by reference in their entireties.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2020/066473 | 12/21/2020 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 62957749 | Jan 2020 | US | |
| 62957752 | Jan 2020 | US | |
| 62967874 | Jan 2020 | US |
