Event-based network and blockchain formation

Abstract

Systems and techniques for recording event data are described. In some implementations, a method may generate a network formation request based on an event. In some examples, the method may broadcast the network formation request to one or more targets. In some cases, the method may form a network that includes at least one of the one or more targets. In some aspects, the method may obtain event data associated with the event from at least one of the one or more targets. In some implementations, the method may attach the event data associated with the event obtained from the one or more targets to a blockchain.

Description

Technical Field

[0001] The present disclosure generally relates to event-based network formation and event data recording between devices. For example, aspects of the present disclosure relate to network formation between vehicles initiated based on a hazardous driving condition and storage of data related to the hazardous driving condition. Background Art

[0002] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasting. A typical wireless communication system may employ multiple access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple access technologies include Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single-Carrier Frequency Division Multiple Access (SC-FDMA) systems, and Time Division Synchronous Code Division Multiple Access (TD-SCDMA) systems.

[0003] These multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate at the city, national, regional, and even global levels. An example telecommunication standard is 5G New Radio (NR). 5G NR is part of the ongoing evolution of mobile broadband promulgated by the Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., related to the Internet of Things (IoT)), and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine type communication (mMTC), and ultra-reliable low latency communication (URLLC). Certain aspects of 5G NR may be based on the 4G Long-Term Evolution (LTE) standard. Aspects of wireless communication may include direct communication between devices, such as in vehicle-to-everything (V2X), vehicle-to-vehicle (V2V), and / or device-to-device (D2D) communication. There is a need to further improve V2X, V2V, and / or D2D technologies. Additionally, these improvements may also be applicable to other multiple access technologies and telecommunication standards that employ these technologies.

[0004] Blockchain technology has received attention in many fields outside the cryptocurrency domain. Blockchain has the ability to build trust in a decentralized, distributed, and autonomous manner through a distributed database, where all electronic transactions or events are registered in a transparent ledger and shared among participating members. Summary of the Invention

[0005] The following presents a simplified summary of the invention related to one or more aspects disclosed herein. Accordingly, the following summary should not be considered an exhaustive overview of all contemplated aspects, nor should it be considered to identify key or critical elements of all contemplated aspects or to delineate the scope associated with any particular aspect. Thus, the sole purpose of the following summary is to present in a concise form certain concepts related to one or more aspects of the mechanisms described herein before the detailed description that follows.

[0006] Systems, apparatuses, methods, and computer-readable media for recording event data are disclosed. According to at least one example, a method for recording event data is provided. The method includes: generating a network formation request based on an event; broadcasting the network formation request to one or more targets; forming a network including at least one of the one or more targets; obtaining event data associated with the event from at least one of the one or more targets; and appending the event data associated with the event obtained from the one or more targets to a blockchain.

[0007] In another example, an apparatus for recording event data is provided, the apparatus including at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to: generate a network formation request based on an event; broadcast the network formation request to one or more targets; form a network including at least one of the one or more targets; obtain event data associated with the event from at least one of the one or more targets; and append the event data associated with the event obtained from the one or more targets to a blockchain.

[0008] In another example, a non-transitory computer-readable medium is provided, having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to: generate a network formation request based on an event; broadcast the network formation request to one or more targets; form a network including at least one of the one or more targets; obtain event data associated with the event from at least one of the one or more targets; and append the event data associated with the event obtained from the one or more targets to a blockchain.

[0009] In another example, a device for recording event data is provided. The device includes: components for generating a network formation request based on an event; components for broadcasting the network formation request to one or more targets; components for forming a network including at least one of the one or more targets; components for obtaining event data associated with the event from at least one of the one or more targets; and components for attaching the event data associated with the event obtained from the one or more targets to a blockchain.

[0010] In some aspects, the device is a vehicle (e.g., a car, a truck, etc. or a component or system of a car, a truck, etc.), or a device or component of a vehicle, a mobile device (e.g., a mobile phone or a so-called "smartphone" or other mobile device), a wearable device, an extended reality device (e.g., a virtual reality (VR) device, an augmented reality (AR) device, or a mixed reality (MR) device), a personal computer, a laptop computer, a server computer, a robotic device, or other devices, including these devices or being part of them. In some aspects, the device includes radio detection and ranging (radar) for capturing radio frequency (RF) signals. In some aspects, the device includes one or more light detection and ranging (LIDAR) sensors, radar sensors, or other light-based sensors for capturing light-based (e.g., light frequency) signals. In some aspects, the device includes one camera or multiple cameras for capturing one or more images. In some aspects, the device further includes a display for displaying one or more images, notifications, and / or other displayable data. In some aspects, the above-described device may include one or more sensors that can be used to determine the location of the device, the state of the device (e.g., temperature, humidity level, and / or other states), and / or for other purposes.

[0011] This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used alone to determine the scope of the claimed subject matter. The subject matter should be understood with reference to the appropriate portions of the entire specification of this patent, any or all of the drawings, and each claim.

[0012] Based on the drawings and the detailed description, other objects and advantages associated with the aspects disclosed herein will be apparent to those skilled in the art. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Exemplary aspects of the present application are described in detail below with reference to the following drawings:

[0014] Figure 1 is a diagram illustrating an example wireless communication system according to some aspects of the present disclosure;

[0015] Figure 2 is a diagram illustrating an example of a decomposed base station architecture that can be used by the disclosed system for event-based network formation and event record decomposition according to some aspects of the present disclosure;

[0016] Figure 3 is a diagram illustrating an example in which various user equipments (UEs) communicate through a direct communication interface and a wide area network interface according to some aspects of the present disclosure;

[0017] Figure 4 is a block diagram illustrating an example of a computing system of a vehicle according to some aspects of the present disclosure;

[0018] Figure 5 is a block diagram illustrating an example of a computing system of a user equipment according to some aspects of the present disclosure;

[0019] Figure 6 is a flowchart illustrating an example of event-based network and blockchain formation according to some aspects of the present disclosure;

[0020] Figure 7 is a diagram illustrating an example of devices involved in wireless communication (e.g., sidelink communication) according to some aspects of the present disclosure;

[0021] Figure 8 is a diagram illustrating an example of a network formation scope according to some aspects of the present disclosure;

[0022] Figure 9A is a block diagram illustrating three consecutive blocks of a blockchain ledger 900 that can be used to store data collected from devices participating in an event-based network according to some aspects of the present disclosure;

[0023] Figure 9B is a block diagram illustrating an example of a distributed ledger according to some aspects of the present disclosure;

[0024] Figure 10 is a flowchart illustrating an example of a process for wireless communication according to some aspects of the present disclosure;

[0025] Figure 11 Illustrates an example computing system according to aspects of the present disclosure. Detailed Description

[0026] For purposes of illustration, certain aspects of the present disclosure are provided below. Alternative aspects can be devised without departing from the scope of the present disclosure. Additionally, well-known elements of the present disclosure will not be described in detail or will be omitted so as not to obscure the relevant details of the present disclosure. Some of the aspects described herein can be applied independently, and some of them can be applied in combination, which will be apparent to those skilled in the art. In the following description, specific details are set forth for purposes of explanation to provide a thorough understanding of the aspects of the present application. However, it will be apparent that the various aspects can be practiced without these specific details. The accompanying drawings and description are not intended to be restrictive.

[0027] The following description provides only example aspects and is not intended to limit the scope, applicability, or configuration of the present disclosure. Instead, the following description of the example aspects will provide those skilled in the art with a description that can be used to implement the example aspects. It should be understood that various changes can be made to the functions and arrangements of the elements without departing from the essence and scope of the present application as set forth in the appended claims.

[0028] The terms “exemplary” and / or “example” are used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” and / or “example” need not be construed as superior or better than other aspects. Similarly, the term “aspects of the present disclosure” does not require that all aspects of the present disclosure include the discussed features, advantages, or operating modes.

[0029] Wireless communication systems are deployed to provide various telecommunication services including telephony, video, data, messaging, broadcasting, and the like. Wireless communication systems have evolved through several generations. The fifth generation (5G) mobile standard calls for higher data transfer speeds, a greater number of connections, better coverage, and other improvements. According to the Next Generation Mobile Networks Alliance, the 5G standard (also known as “New Radio” or “NR”) is designed to provide data rates of tens of megabits per second to each of tens of thousands of users.

[0030] A transportation vehicle is an example of a system that can include wireless communication capabilities. For example, a transportation vehicle (e.g., a motor vehicle, an autonomous vehicle, an aircraft, a sea vessel, etc.) can communicate with other transportation vehicles and / or other devices with wireless communication capabilities. A wireless transportation vehicle communication system includes vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), and vehicle-to-pedestrian (V2P) communications, which are collectively referred to as vehicle-to-everything (V2X) communications. V2X communication is a transportation vehicle communication system that supports wireless transfer of information from one transportation vehicle to other entities within a transportation system that may affect that transportation vehicle (e.g., other transportation vehicles, pedestrians with smart phones, equipped vulnerable road users (VRUs) such as cyclists, and / or other transportation infrastructure). The main purposes of V2X technology are to improve road safety, fuel savings, and traffic efficiency.

[0031] The IEEE 802.11p standard supports the use of dedicated short range communication (DSRC) interfaces for V2X wireless communication. Characteristics of the DSRC interface based on IEEE 802.11p include low latency and the use of the unlicensed 5.9 gigahertz (GHz) band. Cellular-V2X (C-V2X) is adopted as an alternative to using the DSRC interface based on IEEE 802.11p for wireless communication. The 5G Automotive Association (5GAA) supports the use of C-V2X technology. In some cases, C-V2X technology uses Long Term Evolution (LTE) as the underlying technology, and C-V2X functionality is based on LTE technology. C-V2X includes multiple operation modes. One of the operation modes in each operation mode allows for direct wireless communication between transportation vehicles through the LTE side-link PC5 interface. Similar to the DSRC interface based on IEEE 802.11p, the LTE C-V2X side-link PC5 interface operates in the 5.9 GHz band. Vehicle-based messages (such as basic safety messages (BSM) and cooperative awareness messages (CAM) as application layer messages) are designed to be wirelessly broadcast on the DSRC interface based on 802.11p and the LTE C-V2X side-link PC5 interface.

[0032] As previously mentioned, V2X technology includes V2V communication, which can also be referred to as peer-to-peer communication. V2V communication allows transportation vehicles to directly communicate wirelessly with each other while on the road. Using V2V communication, a transportation vehicle can obtain situational awareness by receiving information about upcoming road hazards (e.g., unforeseen oncoming transportation vehicles, accidents, and road conditions) from other transportation vehicles.

[0033] In a V2X communication system, information is sent via a wireless link from vehicle sensors (and other sources) to allow the information to be communicated to other vehicles, pedestrians, VRUs, and / or traffic infrastructure. One or more vehicle-based messages (such as Cellular Vehicle-to-Everything (C-V2X) messages) can be used to send the information, and the one or more vehicle-based messages can include Sensor Data Sharing Messages (SDSMs), BSMs, CAMs, Cooperative Awareness Messages (CPMs), Decentralized Environmental Messages (DENMs), and / or other types of vehicle-based messages.

[0034] Solutions are needed for event-based detection to securely and privately collect data in an ad-hoc manner. Systems and techniques are described herein for using blockchain to meet the security and privacy requirements in an ad-hoc network that forms and operates in a peer-to-peer manner among peer participants without the presence of a central authority.

[0035] In an illustrative example, a traffic accident is an event that can benefit from data collection by an ad-hoc network. For example, data collected by parties witnessing a traffic accident event can be a good source of information about the traffic accident. However, in some cases, the event data captured by parties witnessing the accident may not be organized by any central authority. In some examples, the lack of a central entity can lead to a lack of credibility and / or trust in the event data. In some aspects, collecting data from parties in a blockchain can preserve the event data and / or prevent later modification of the event data. In some examples, the blockchain can provide a repository for event data captured by different parties witnessing a traffic accident.

[0036] Although, for illustrative purposes, a traffic accident is provided as an example event, it should be understood that the systems and techniques described herein can be used for data collection related to events that may or may not involve vehicles. Similarly, although data collection by electronic equipment included in vehicles is described below, data collected from other types of electronic devices (e.g., handheld devices, wearable devices, sensors attached to stationary objects, etc.) can be used without departing from the scope of the present disclosure. In addition to the vehicles directly involved in an accident, electronic devices physically close to the vehicles directly involved can simultaneously collect data related to reconstructing the events that occurred before, during, and after a traffic accident. For example, vehicles in nearby lanes can collect images or videos from one or more cameras, RADAR data, LIDAR data, audio data, etc. that capture the accident and the events leading to the accident.

[0037] In some cases, data collected from participants in a network may have data appended to a blockchain. The blockchain may provide security and privacy, as well as store the appended data in a sequence that can be used to reconstruct an event based on the collected data (also referred to herein as detailed event data). In some cases, rather than collecting the raw data collected by devices participating in the network, the raw data may be hashed and the raw data stored in the blockchain. The hash data associated with the collected raw data (also referred to herein as hash event data) can later be used to verify the authenticity of the raw data collected from participants in the network. For example, cameras on vehicles near a traffic accident may capture video of the accident. In some cases, the raw video data may be hashed, and the hash may be appended to the blockchain. In some cases, the owner of the raw video data may choose whether to opt in. Additionally, in addition to the timestamp in the data, the order of the observations added to the blockchain may at least partially record and preserve the time series of the observations.

[0038] In some cases, one or more electronic devices may initiate the formation of a network based on the occurrence of an event (e.g., a traffic accident). In an illustrative example, a stationary roadside device may initiate the formation of a network based on detecting a traffic accident. In some cases, the network formation may be sent as a network formation request to one or more devices and / or initiating electronic devices near the event. In an illustrative example, the network formation request may be sent based on dedicated short-range communication (DSRC), which is based on 802.11p on the PHY / MAC and IEEE 1609.2 / 3 / 4 on the upper layer, or based on multicast in mode 2 of NR cellular V2X (NR C-V2X) or mode 4 of LTE V2X. In some cases, network participants may communicate with the network via different types of physical layer connections. In some cases, the physical layer connections may be provided by different service providers.

[0039] In some examples, a device that receives a network formation request may forward the request to other nearby devices. In some examples, the request forwarding may be restricted by time, location, relevance, and / or any combination thereof. In some cases, by restricting the network request formation forwarding, the data stored in the blockchain can be highly specific and related to the event.

[0040] In some specific implementations, the responding device may broadcast a broadcast with the attached data to multiple devices in the network. For example, participants in the network may not be directly connected to all other devices participating in the network. Due to the broadcasts to different devices and / or the different connections between the devices of the network, there may be multiple branches or forks during the process of attaching data from network participants. In an illustrative example, the initiator and / or another network participant may determine the append order. In some cases, the device that determines the append order may also be referred to as the control device. As used herein, the append order may refer to the specified order for network participants to attach data to the chain. In some cases, the append order may prevent branches and / or forks. For example, a network participant may announce its central role to the network, and the responding node may confirm the message. In another illustrative example, a distributed method for managing branches and / or forks (also referred to herein as branch reduction and / or fork reduction) may be based on the length of the blockchain. In some cases, the participating device may attach its data to the longest available chain when attaching data. In some cases, attaching data to the longest available chain may reduce the number of branches and / or forks in the blockchain by preventing data from being added to multiple chains. In another illustrative example, the formation of branches and forks may be allowed, and the relationships between the branches and / or forks may be stored and used to establish the organizational structure of the blockchain. In an illustrative example, the relationships between the branches and / or forks may be stored as a hashgraph. As used herein, a hashgraph is a distributed ledger system that can store data in multiple chains and generate the order of nodes based on the consensus of the timestamps of each transaction stored across multiple chains.

[0041] Additional aspects of the present disclosure are described in more detail below.

[0042] As used herein, the terms "user equipment" (UE) and "network entity" are not intended to be dedicated to or otherwise limited to any particular radio access technology (RAT), unless otherwise specified. In general, a UE can be any wireless communication device (e.g., a mobile phone, router, tablet computer, laptop computer, and / or tracking device, etc.), a wearable device (e.g., a smart watch, smart glasses, wearable ring, and / or extended reality (XR) device (such as a virtual reality (VR) headset, an augmented reality (AR) headset or glasses, or a mixed reality (MR) headset)), a vehicle (e.g., a car, motorcycle, bicycle, etc.), and / or an Internet of Things (IoT) device, etc., for a user to communicate over a wireless communication network. The UE can be mobile or can (e.g., at certain times) be stationary and can communicate with a radio access network (RAN). As used herein, the term "UE" can be interchangeably referred to as "access terminal" or "AT", "client device", "wireless device", "subscriber device", "subscriber terminal", "subscriber station", "user terminal" or "UT", "mobile device", "mobile terminal", "mobile station", or variants thereof. Generally speaking, a UE can communicate with a core network via the RAN, and through the core network, the UE can connect to external networks such as the Internet and to other UEs. Of course, other mechanisms for connecting to the core network and / or the Internet are also possible for the UE, such as via a wired access network, a wireless local area network (WLAN) network (e.g., based on the IEEE 802.11 communication standard, etc.).

[0043] In some cases, the network entity may be implemented in a centralized or monolithic base station or server architecture, or alternatively, in a decomposed base station or server architecture, and may include one or more of a Central Unit (CU), a Distributed Unit (DU), a Radio Unit (RU), a Near Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), or a Non-Real-Time (Non-RT) RIC. In some cases, the network entity may include server devices such as Multi-Access Edge Computing (MEC) devices. The base station or server (e.g., having a centralized / monolithic base station architecture or a decomposed base station architecture) may operate according to one of several Radio Access Technologies (RATs) depending on the network in which the base station or server is deployed to communicate with User Equipments (UEs), Road Side Units (RSUs), and / or other devices, and may alternatively be referred to as an Access Point (AP), a network node, a Node B (NB), an Evolved Node B (eNB), a Next Generation eNB (ng-eNB), a New Radio (NR) Node B (also referred to as gNB or gNodeB), etc. The base station is mainly used to support the wireless access of UEs, including supporting the data, voice, and / or signaling connections of the supported UEs. In some systems, the base station may provide edge node signaling functions, while in other systems, the base station may provide additional control and / or network management functions. The communication link by which a UE can transmit signals to the base station is referred to as an Uplink (UL) channel (e.g., reverse traffic channel, reverse control channel, access channel, etc.). The communication link by which the base station can transmit signals to the UE is referred to as a Downlink (DL) or Forward Link channel (e.g., paging channel, control channel, broadcast channel, forward traffic channel, etc.). As used herein, the term Traffic Channel (TCH) may refer to an uplink, reverse, or downlink, and / or forward traffic channel.

[0044] The term "network entity" or "base station" (e.g., having an integrated / monolithic base station architecture or a disaggregated base station architecture) can refer to a single physical TRP or multiple physical TRPs, which may or may not be co-located. For example, when the term "network entity" or "base station" refers to a single physical TRP, the physical TRP can be a base station antenna corresponding to a cell (or several cell sectors) of the base station. When the term "network entity" or "base station" refers to multiple co-located physical TRPs, these physical TRPs can be an antenna array of the base station (e.g., as in a multiple-input multiple-output (MIMO) system or when beamforming is employed at the base station). When the term "base station" refers to multiple non-co-located physical TRPs, the physical TRPs can be a distributed antenna system (DAS) (a network of spatially separated antennas connected to a common source via a transmission medium) or a remote radio head (RRH) (a remote base station connected to a serving base station). Alternatively, the non-co-located physical TRPs can be a serving base station that receives measurement reports from a UE and a neighbor base station whose reference radio frequency (RF) signal (or simply "reference signal") the UE is measuring. Since, as used herein, a TRP is the point by which a base station transmits and receives wireless signals, a reference to transmission from or reception at a base station should be understood to refer to a specific TRP of the base station.

[0045] In some specific implementations that support UE positioning, a network entity or base station may not support wireless access for the UE (e.g., may not support data, voice, and / or signaling connections for the UE), but instead may send reference signals to be measured by the UE and / or may receive and measure signals transmitted by the UE. Such a base station can be referred to as a positioning beacon (e.g., in the case of sending signals to the UE) and / or as a position measurement unit (e.g., in the case of receiving and measuring signals from the UE).

[0046] A roadside unit (RSU) is a device that can send messages to and receive messages from one or more UEs, other RSUs, and / or base stations via a communication link or interface (e.g., a cellular-based sidelink or PC5 interface, an 802.11 or WiFi TM -based dedicated short-range communication (DSRC) interface and / or other interfaces). Examples of messages that can be sent and received by the RSU include vehicle-to-everything (V2X) messages, which are described in more detail below. The RSU can be located on various transportation infrastructure systems, including roads, bridges, parking lots, toll booths, and / or other infrastructure systems. In some examples, the RSU can facilitate communication between UEs (e.g., vehicles, pedestrian user devices, and / or other UEs) and transportation infrastructure systems. In some specific implementations, the RSU can communicate with a server, a base station, and / or other systems that can perform centralized management functions.

[0047] The RSU can communicate with the communication system of the UE. For example, the intelligent transportation system (ITS) of the UE (such as a vehicle and / or other UE) can be used to generate and sign messages for transmission to the RSU and verify the messages received from the RSU. The RSU can communicate with vehicles traveling along roads, bridges, or other infrastructure systems (e.g., via the PC5 interface, DSRC interface, etc.) to obtain traffic-related data (such as the time, speed, location, etc. of the vehicle). In some cases, in response to obtaining traffic-related data, the RSU can determine or estimate traffic congestion information (such as the start of traffic congestion, the end of traffic congestion, etc.), travel time, and / or other information about a specific location. In some examples, the RSU can communicate with other RSUs (e.g., via the PC5 interface, DSRC interface, etc.) to determine traffic-related data. The RSU can send information (such as traffic congestion information, travel time information, and / or other information) to other vehicles, pedestrian UEs, and / or other UEs. For example, the RSU can broadcast or otherwise send information to any UE (such as a vehicle, pedestrian UE, etc.) within the coverage area of the RSU.

[0048] A radio frequency signal or "RF signal" includes an electromagnetic wave of a given frequency that transmits information through the space between a transmitter and a receiver. As used herein, the transmitter can send a single "RF signal" or multiple "RF signals" to the receiver. However, due to the propagation characteristics of the RF signal through a multipath channel, the receiver can receive multiple "RF signals" corresponding to each transmitted RF signal. The same transmitted RF signal on different paths between the transmitter and the receiver can be referred to as a "multipath" RF signal. As used herein, when the context clearly indicates that the term "signal" refers to a wireless signal or an RF signal, the RF signal can also be referred to as a "wireless signal" or simply "signal".

[0049] According to various aspects, Figure 1An exemplary wireless communication system 100 is illustrated. The wireless communication system 100 (which may also be referred to as a wireless wide area network (WWAN)) may include various base stations 102 and various UEs 104. In some aspects, the base stations 102 may also be referred to as "network entities" or "network nodes". One or more of the base stations 102 may be implemented in an aggregated or monolithic base station architecture. Additionally or alternatively, one or more of the base stations 102 may be implemented in a disaggregated base station architecture and may include one or more of a central unit (CU), a distributed unit (DU), a radio unit (RU), a near real-time (near RT) RAN intelligent controller (RIC), or a non-real-time (non RT) RIC. The base stations 102 may include macrocell base stations (high-power cellular base stations) and / or small cell base stations (low-power cellular base stations). In one aspect, the macrocell base stations may include eNBs and / or ng-eNBs (where the wireless communication system 100 corresponds to a Long Term Evolution (LTE) network), or gNBs (where the wireless communication system 100 corresponds to a New Radio (NR) network), or a combination of both, and the small cell base stations may include femtocells, picocells, microcells, etc.

[0050] The base stations 102 may together form a RAN and interface with a core network 170 (e.g., an evolved packet core (EPC) or a 5G core (5GC)) via a backhaul link 122 and interface to one or more location servers 172 (which may be part of the core network 170 or may be external to the core network 170) via the core network 170. Among other functions, the base stations 102 may perform functions related to one or more of the following: passing user data, radio channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection establishment and release, load balancing, distribution of non-access stratum (NAS) messages, NAS node selection, synchronization, RAN sharing, multimedia broadcast multicast service (MBMS), subscriber and equipment tracking, RAN information management (RIM), paging, positioning, and delivery of warning messages. The base stations 102 may communicate with each other directly or (e.g., via the EPC or 5GC) indirectly via a backhaul link 134 (which may be wired and / or wireless).

[0051] Base station 102 can communicate wirelessly with UE 104. Each base station in base station 102 can provide communication coverage for a corresponding geographical coverage area 110. In one aspect, the base stations 102 in each coverage area 110 can support one or more cells. A "cell" is a logical communication entity used to communicate with a base station (e.g., on a certain frequency resource, which is called carrier frequency, component carrier, carrier, frequency band, etc.), and can be associated with an identifier (e.g., physical cell identifier (PCI), virtual cell identifier (VCI), cell global identifier (CGI)) to distinguish cells operating via the same or different carrier frequencies. In some cases, different cells can be configured according to different protocol types that can provide access for different types of UEs (e.g., machine type communication (MTC), narrowband IoT (NB-IoT), enhanced mobile broadband (eMBB) or other protocol types). Since a cell is supported by a specific base station, the term "cell" can, depending on the context, refer to either or both of the logical communication entity and the base station that supports the logical communication entity. In addition, since the TRP is usually the physical transmission point of a cell, the terms "cell" and "TRP" can be used interchangeably. In some cases, the term "cell" can also refer to the geographical coverage area (e.g., sector) of a base station, as long as the carrier frequency can be detected and used for communication within a certain part of the geographical coverage area 110.

[0052] Although the geographical coverage areas 110 of adjacent macro cell base stations 102 can partially overlap (e.g., in a handover area), some areas in the geographical coverage area 110 can substantially overlap with a larger geographical coverage area 110. For example, a small cell base station 102' can have a coverage area 110' that substantially overlaps with the coverage areas 110 of one or more macro cell base stations 102. A network including both small cell base stations and macro cell base stations can be referred to as a heterogeneous network. The heterogeneous network can also include a home eNB (HeNB), which can provide services to a restricted group called a closed subscriber group (CSG).

[0053] The communication link 120 between base station 102 and UE 104 can include an uplink (also called reverse link) transmission from UE 104 to base station 102 and / or a downlink (also called forward link) transmission from base station 102 to UE 104. The communication link 120 can use MIMO antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link 120 can pass through one or more carrier frequencies. The allocation of carriers can be asymmetric for the downlink and uplink (e.g., more or fewer carriers can be allocated to the downlink compared to the uplink).

[0054] The wireless communication system 100 may further include a WLAN AP 150 that communicates with a WLAN station (STA) 152 via a communication link 154 in an unlicensed spectrum (e.g., 5 gigahertz (GHz)). When communicating in the unlicensed spectrum, the WLAN STA 152 and / or the WLAN AP 150 may perform a Clear Channel Assessment (CCA) or Listen Before Talk (LBT) procedure before communication to determine whether the channel is available. In some examples, the wireless communication system 100 may include devices (e.g., UEs, etc.) that communicate with one or more UEs 104, base stations 102, APs 150, etc. using the Ultra-Wideband (UWB) spectrum. The range of the UWB spectrum may be from 3.1 GHz to 10.5 GHz.

[0055] The small cell base station 102' may operate in licensed and / or unlicensed spectrum. When operating in the unlicensed spectrum, the small cell base station 102' may employ LTE or NR technologies and use the same 5 GHz unlicensed spectrum as that used by the WLAN AP 150. The small cell base station 102' adopting LTE and / or 5G in the unlicensed spectrum may boost the coverage of the access network and / or increase the capacity of the access network. NR in the unlicensed spectrum may be referred to as NR-U. LTE in the unlicensed spectrum may be referred to as LTE-U, Licensed-Assisted Access (LAA), or MulteFire.

[0056] The wireless communication system 100 may further include a millimeter wave (mmW) base station 180 that may operate at mmW frequencies and / or near-mmW frequencies to communicate with a UE 182. The mmW base station 180 may be implemented in an integrated or monolithic base station architecture, or alternatively, in a disaggregated base station architecture (e.g., including one or more of a CU, DU, RU, near-RT RIC, or non-RT RIC). The Extremely High Frequency (EHF) is a part of the RF in the electromagnetic spectrum. The EHF has a range of 30 GHz to 300 GHz and a wavelength between 1 millimeter and 10 millimeters. The radio waves in this band may be referred to as millimeter waves. Near-mmW may extend down to a frequency of 3 GHz with a wavelength of 100 millimeters. The Super High Frequency (SHF) band extends between 3 GHz and 30 GHz, which is also referred to as centimeter waves. Communication using the mmW and / or near-mmW radio frequency bands has high path loss and a relatively short distance. The mmW base station 180 and the UE 182 may utilize beamforming (transmission and / or reception) on the mmW communication link 184 to compensate for the extremely high path loss and short distance. In addition, it should be understood that in an alternative configuration, one or more of the base stations 102 may also use mmW or near-mmW and beamforming for transmission. Therefore, it should be understood that the foregoing illustrations are merely examples and should not be construed as limiting the various aspects disclosed herein.

[0057] Transmit beamforming is a technique for focusing RF signals in a specific direction. Traditionally, when a network node or entity (e.g., a base station) broadcasts an RF signal, it broadcasts the signal omnidirectionally, i.e., in all directions. With transmit beamforming, the network node determines where a given target device (e.g., a UE) is located (relative to the transmitting network node) and projects a stronger downlink RF signal in that specific direction, thus providing a faster and stronger RF signal (in terms of data rate) to the receiving device. To change the directivity of the RF signal during transmission, the network node can control the phase and relative amplitude of the RF signal at each of one or more transmitters that broadcast the RF signal. For example, the network node can use an array of antennas (referred to as a "phased array" or "antenna array") that forms an RF beam that can be "steered" to point in different directions without physically moving the antennas. Specifically, the RF currents from the transmitters are fed to the individual antennas with the correct phase relationships such that the radio waves from the individual antennas add together in the desired direction to increase radiation, while canceling in the undesired directions to suppress radiation.

[0058] Transmit beams can be quasi co-located, which means that they have the same parameters for a receiver (e.g., a UE), regardless of whether the transmitting antennas of the network node are physically co-located. In NR, there are four types of quasi co-location (QCL) relationships. Specifically, a given type of QCL relationship means that certain parameters of a second reference RF signal on a second beam can be derived based on information about a source reference RF signal on a source beam. Thus, if the source reference RF signal is of QCL type A, the receiver can use the source reference RF signal to estimate the Doppler shift, Doppler spread, average delay, and delay spread of a second reference RF signal transmitted on the same channel. If the source reference RF signal is of QCL type B, the receiver can use the source reference RF signal to estimate the Doppler shift and Doppler spread of a second reference RF signal transmitted on the same channel. If the source reference RF signal is of QCL type C, the receiver can use the source reference RF signal to estimate the Doppler shift and average delay of a second reference RF signal transmitted on the same channel. If the source reference RF signal is of QCL type D, the receiver can use the source reference RF signal to estimate the spatial reception parameters of a second reference RF signal transmitted on the same channel.

[0059] In receive beamforming, a receiver uses receive beams to amplify RF signals detected on a given channel. For example, the receiver can increase the gain setting of an antenna array in a specific direction and / or adjust the phase setting of the antenna array in a specific direction to amplify the RF signal received from that direction (e.g., increase its gain level). Thus, when a receiver is said to perform beamforming in a certain direction, this means that the beam gain in that direction is higher relative to the beam gains in other directions, or that the beam gain in that direction is the highest compared to the beam gains of other beams available to the receiver. This results in a stronger received signal strength for the RF signal received from that direction (e.g., reference signal received power (RSRP), reference signal received quality (RSRQ), signal-to-interference-plus-noise ratio (SINR), etc.).

[0060] Receive beams can be spatially related. Spatial relationship means that parameters for a transmit beam for a second reference signal can be derived based on information about a receive beam for a first reference signal. For example, a UE can use a specific receive beam to receive one or more reference downlink reference signals (e.g., positioning reference signal (PRS), tracking reference signal (TRS), phase tracking reference signal (PTRS), cell-specific reference signal (CRS), channel state information reference signal (CSI-RS), primary synchronization signal (PSS), secondary synchronization signal (SSS), synchronization signal block (SSB), etc.) from a network node or entity (e.g., a base station). The UE can then form a transmit beam based on the parameters of the receive beam for transmitting one or more uplink reference signals (e.g., uplink positioning reference signal (UL-PRS), sounding reference signal (SRS), demodulation reference signal (DMRS), PTRS, etc.) to the network node or entity (e.g., a base station).

[0061] Note that depending on the entity forming the "downlink" beam, the beam can be a transmit beam or a receive beam. For example, if a network node or entity (e.g., a base station) is forming a downlink beam to send a reference signal to a UE, the downlink beam is a transmit beam. However, if the UE is forming a downlink beam, the downlink beam is a receive beam for receiving downlink reference signals. Similarly, depending on the entity forming the "uplink" beam, the beam can be a transmit beam or a receive beam. For example, if a network node or entity (e.g., a base station) is forming an uplink beam, the uplink beam is an uplink receive beam, and if the UE is forming an uplink beam, the uplink beam is an uplink transmit beam.

[0062] In 5G, the spectrum in which a radio network node or entity (e.g., base station 102 / 180, UE 104 / 182) operates is divided into multiple frequency ranges: FR1 (from 450 megahertz (MHz) to 6000 MHz), FR2 (from 24250 MHz to 52600 MHz), FR3 (above 52600 MHz), and FR4 (between FR1 and FR2). In a multi-carrier system such as 5G, one of the carrier frequencies is referred to as the "primary carrier" or "anchor carrier" or "primary serving cell" or "PCell", and the remaining carrier frequencies are referred to as "secondary carriers" or "secondary serving cells" or "SCells". In carrier aggregation, the anchor carrier is a carrier that operates on the primary frequency (e.g., FR1) used by the UE 104 / 182 and the cell, where the UE 104 / 182 performs the initial radio resource control (RRC) connection establishment process or initiates the RRC connection re-establishment process in that cell. The primary carrier carries all common and UE-specific control channels and can be a carrier in a licensed frequency (however, this is not always the case). The secondary carrier is a carrier that operates on a second frequency (e.g., FR2) and can be configured and used to provide additional radio resources once an RRC connection is established between the UE 104 and the anchor carrier. In some cases, the secondary carrier can be a carrier in an unlicensed frequency. The secondary carrier can contain only the necessary signaling information and signals. For example, since the primary uplink carrier and the primary downlink carrier are usually UE-specific, the UE-specific signaling information and signals may not exist in the secondary carrier. This means that different UEs 104 / 182 in a cell can have different downlink primary carriers. The same holds for the uplink primary carrier. The network is able to change the primary carrier of any UE 104 / 182 at any time. This is done, for example, to balance the load on different carriers. Since a "serving cell" (whether it is a PCell or an SCell) corresponds to the carrier frequency or component carrier that some base station is using for communication, the terms "cell", "serving cell", "component carrier", "carrier frequency", etc. can be used interchangeably.

[0063] For example, still referring to Figure 1, one of the frequencies used by the macro cell base station 102 can be an anchor carrier (or "PCell"), and the other frequencies used by the macro cell base station 102 and / or the mmW base station 180 can be secondary carriers ("SCells"). In carrier aggregation, the base station 102 and / or the UE 104 can use a spectrum with a bandwidth of up to Y MHz (e.g., 5 MHz, 10 MHz, 15 MHz, 20 MHz, 100 MHz) per carrier, with a total of up to Yx MHz (x component carriers) in each direction for transmission. The component carriers can be adjacent to each other in the spectrum or can be non-adjacent to each other. The allocation of carriers can be asymmetric with respect to the downlink and the uplink (e.g., more or fewer carriers can be allocated to the downlink compared to the uplink). The simultaneous transmission and / or reception of multiple carriers enables the UE 104 / 182 to significantly increase its data transmission and / or reception rate. For example, compared to the data rate obtained with a single 20 MHz carrier, two 20 MHz aggregated carriers in a multi-carrier system would theoretically result in a doubling of the data rate (i.e., 40 MHz).

[0064] To operate on multiple carrier frequencies, the base station 102 and / or the UE 104 are equipped with multiple receivers and / or transmitters. For example, the UE 104 can have two receivers, namely "Receiver 1" and "Receiver 2", where "Receiver 1" is a multi-band receiver that can be tuned to the frequency band (i.e., carrier frequency) "X" or the frequency band "Y", and "Receiver 2" is a single-band receiver that can be tuned to only the frequency band "Z". In this example, if the UE 104 is being served in the frequency band "X", the frequency band "X" will be referred to as the PCell or the active carrier frequency, and "Receiver 1" will need to be tuned from the frequency band "X" to the frequency band "Y" (SCell) to measure the frequency band "Y" (and vice versa). In contrast, regardless of whether the UE 104 is being served in the frequency band "X" or the frequency band "Y", due to the separate "Receiver 2", the UE 104 can measure the frequency band "Z" without interrupting the service on the frequency band "X" or the frequency band "Y".

[0065] The wireless communication system 100 can further include a UE 164, which can communicate with the macro cell base station 102 on the communication link 120 and / or communicate with the mmW base station 180 on the mmW communication link 184. For example, the macro cell base station 102 can support a PCell and one or more SCells for the UE 164, and the mmW base station 180 can support one or more SCells for the UE 164.

[0066] The wireless communication system 100 may also include one or more UEs, such as UE 190, which is indirectly connected to one or more communication networks via one or more device-to-device (D2D) peer-to-peer (P2P) links (referred to as "sidelinks"). In Figure 1 the example, UE 190 has a D2D P2P link 192 with one of the UEs in UE 104 connected to one of the base stations in base station 102 (e.g., UE 190 can indirectly obtain cellular connectivity through this D2D P2P link), and has a D2D P2P link 194 with WLAN STA 152 connected to WLAN AP 150 (UE 190 can indirectly obtain WLAN-based Internet connectivity through this D2D P2P link). In one example, D2D P2P links 192 and 194 can use any well-known D2D RAT (such as LTE Direct (LTE-D), Wi-Fi Direct (Wi-Fi-D), etc.) to support.

[0067] Figure 2 is a diagram illustrating an example of a decomposed base station architecture that can be used by the disclosed system for event-based network and blockchain formation. The deployment of a communication system (such as a 5G NR system) can be arranged in various ways with various components or constituent parts. In a 5G NR system or network, network nodes, network entities, mobility elements of the network, radio access network (RAN) nodes, core network nodes, network elements, or network equipment (such as a base station (BS)) or one or more units (or one or more components) performing base station functionality can be implemented in an aggregated or decomposed architecture. For example, a BS (such as a Node B (NB), evolved NB (eNB), NR BS, 5G NB, AP, transmit-receive point (TRP), or cell, etc.) can be implemented as an aggregated base station (also referred to as a stand-alone BS or monolithic BS) or a decomposed base station.

[0068] An aggregated base station can be configured to utilize a radio protocol stack physically or logically integrated within a single RAN node. A decomposed base station can be configured to utilize a protocol stack physically or logically distributed between two or more units (such as one or more central or centralized units (CUs), one or more distributed units (DUs), or one or more radio units (RUs)). In some aspects, a CU can be implemented within a RAN node, and one or more DUs can be co-located with the CU, or alternatively, can be geographically or virtually distributed in one or more other RAN nodes. A DU can be implemented to communicate with one or more RUs. Each of the CU, DU, and RU can also be implemented as a virtual unit, i.e., a virtual central unit (VCU), a virtual distributed unit (VDU), or a virtual radio unit (VRU).

[0069] Base station type operations or network design may consider the aggregation characteristics of base station functionality. For example, a split base station may be used in an integrated access backhaul (IAB) network, an open radio access network (O-RAN, such as a network configuration advocated by the O-RAN Alliance), or a virtualized radio access network (vRAN, also known as a cloud radio access network (C-RAN)). The split may include distributing functions across two or more units at various physical locations, as well as virtually distributing the functions of at least one unit, which can achieve flexibility in network design. Various units of the split base station or split RAN architecture may be configured for wired or wireless communication with at least one other unit.

[0070] As previously mentioned, Figure 2 A diagram illustrating an exemplary split base station 201 architecture is shown. The split base station 201 architecture may include one or more central units (CUs) 211, which may communicate directly with the core network 223 via a backhaul link, or indirectly with the core network 223 through one or more split base station units (such as a near real-time (near RT) RAN intelligent controller (RIC) 227 via an E2 link, or a non-real-time (non RT) RIC 217 associated with a service management and orchestration (SMO) framework 207, or both). The CU 211 may communicate with one or more distributed units (DUs) 231 via a corresponding midhaul link (such as an F1 interface). The DU 231 may communicate with one or more radio units (RUs) 241 via a corresponding fronthaul link. The RU 241 may communicate with a corresponding UE 221 via one or more RF access links. In some specific implementations, the UE 221 may be served simultaneously by multiple RUs 241.

[0071] Each of the units (i.e., CU 211, DU 231, RU 241, and near RT RIC 227, non RT RIC 217, and SMO framework 207) may include one or more interfaces or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively referred to as signals) via a wired or wireless transmission medium. Each of the units or an associated processor or controller providing instructions to the communication interfaces of these units may be configured to communicate with one or more of the other units via the transmission medium. For example, the units may include a wired interface configured to receive or transmit signals to one or more of the other units via a wired transmission medium. Additionally, the units may include a wireless interface, which may include a receiver, a transmitter, or a transceiver (such as an RF transceiver) configured to receive or transmit signals to one or more of the other units on a wireless transmission medium, or both.

[0072] In some aspects, the CU 211 may host one or more higher layer control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP), etc. Each control function may be implemented using an interface that is configured to communicate signals with other control functions hosted by the CU 211. The CU 211 may be configured to handle user plane functionality (i.e., Central Unit - User Plane (CU-UP)), control plane functionality (i.e., Central Unit - Control Plane (CU-CP)), or a combination thereof. In some specific implementations, the CU 211 may be logically split into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units may communicate bi-directionally with the CU-CP units via an interface such as the E1 interface. As needed, the CU 211 may be implemented to communicate with the DU 231 for network control and signaling.

[0073] The DU 231 may correspond to a logical unit that includes one or more base station functions for controlling the operation of one or more RUs 241. In some aspects, the DU 231 may host one or more of the Radio Link Control (RLC) layer, Medium Access Control (MAC) layer, and one or more high Physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation, and demodulation, etc.) at least partially according to a functional split (such as those defined by the 3rd Generation Partnership Project (3GPP)). In some aspects, the DU 231 may further host one or more low PHY layers. Each layer (or module) may be implemented using an interface that is configured to communicate signals with other layers (and modules) hosted by the DU 231 or with control functions hosted by the CU 211.

[0074] Lower layer functionality may be implemented by one or more RUs 241. In some deployments, the RU 241 controlled by the DU 231 may correspond to a logical node that hosts RF processing functions or low PHY layer functions (such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.) or both, at least in part based on function split (such as lower layer function split). In such an architecture, the RU 241 may be implemented to handle over-the-air (OTA) communication with one or more UEs 221. In some embodiments, the real-time and non-real-time aspects of the control plane communication and user plane communication with the RU 241 may be controlled by the corresponding DU 231. In some scenarios, this configuration may enable the implementation of the DU 231 and CU 211 in a cloud-based RAN architecture (such as a vRAN architecture).

[0075] The SMO framework 207 may be configured to support the RAN deployment and orchestration of non-virtualized network elements and virtualized network elements. For non-virtualized network elements, the SMO framework 207 may be configured to support the deployment of dedicated physical resources for RAN coverage requirements, and these dedicated physical resources may be managed via an operation and maintenance interface (such as the O1 interface). For virtualized network elements, the SMO framework 207 may be configured to interact with a cloud computing platform (such as the Open Cloud (O-Cloud) 291) to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface (such as the O2 interface). Such virtualized network elements may include, but are not limited to, the CU 211, DU 231, RU 241, and the near RT RIC 227. In some embodiments, the SMO framework 207 may communicate with the hardware aspects of the 4G RAN (such as the Open eNB (O-eNB) 213) via the O1 interface. Additionally, in some embodiments, the SMO framework 207 may communicate directly with one or more RUs 241 via the O1 interface. The SMO framework 207 may also include a non-RT RIC 217 configured to support the functionality of the SMO framework 207.

[0076] The non-RT RIC 217 can be configured to include logic functions that enable non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and update, or policy-based guidance of applications / features in the near-RT RIC 227. The non-RT RIC 217 can be coupled to or communicate with the near-RT RIC 227 (such as via the A1 interface). The near-RT RIC 227 can be configured to include logic functions that enable near-real-time control and optimization of RAN elements and resources via an interface (such as via the E2 interface) through data collection and actions, the interface connecting one or more CU 211, one or more DU 231, or both, and the O-eNB 213 to the near-RT RIC 227.

[0077] In some specific implementations, to generate an AI / ML model to be deployed in the near-RT RIC 227, the non-RT RIC 217 can receive parameters or external enrichment information from an external server. Such information can be utilized by the near-RT RIC 227 and can be received from non-network data sources or from network functions at the SMO framework 207 or the non-RT RIC 217. In some examples, the non-RT RIC 217 or the near-RT RIC 227 can be configured to tune RAN behavior or performance. For example, the non-RT RIC 217 can monitor long-term trends and patterns of performance and employ an AI / ML model to perform corrective actions through the SMO framework 207 (such as via reconfiguration of O1) or via creating RAN management policies (such as A1 policies).

[0078] Figure 3 Examples of different communication mechanisms used by various UEs are illustrated. In one example of sidelink communication, Figure 3 Examples are illustrated where the vehicles 304, 305, and the RSU 303 communicate with each other using PC5, DSRC, or other device-to-device direct signaling interfaces. Additionally, the vehicles 304 and 305 can use the network (Uu) interface to communicate with the base station 302 (shown as BS 302). In some examples, the base station 302 can include a gNB. Figure 3It is also illustrated that the user equipment 307 uses a network (Uu) interface to communicate with the base station 302. As described below, functionality may be transferred from a vehicle (e.g., vehicle 304) to the user equipment (e.g., user equipment 307) based on one or more characteristics or factors (e.g., temperature, humidity, etc.). In an illustrative example, V2X functionality may be transferred from vehicle 304 to user equipment 307, after which user equipment 307 may communicate with other vehicles (e.g., vehicle 305) via a PC5 interface (or other device-to-device direct interface, such as a DSRC interface), as Figure 3 shown.

[0079] Although Figure 3 an example illustrates a specific number of vehicles (e.g., two vehicles 304 and 305) communicating with each other and / or with the RSU 303, BS 302, and / or user equipment 307, the present disclosure is not limited thereto. For example, dozens or hundreds of such vehicles may be communicating with each other and / or with the RSU 303, BS 302, and / or user equipment 307. At any given point in time, each such vehicle, RSU 303, BS 302, and / or user equipment 307 may send various types of information as messages to other nearby vehicles, resulting in each vehicle (e.g., vehicle 304 and / or 305), RSU 303, BS 302, and / or user equipment 307 receiving hundreds or thousands of messages per second from other nearby vehicles, RSUs, base stations, and / or other UEs.

[0080] Although the PC5 interface is shown in Figure 3 , various UEs (e.g., vehicles, user equipment, etc.) and RSUs may communicate directly using any suitable type of direct interface such as an 802.11 DSRC interface, Bluetooth TM interface, and / or other interfaces. For example, a vehicle may communicate with a user equipment via a direct communication interface (e.g., using PC5 and / or DSRC), a vehicle may communicate with another vehicle via a direct communication interface, a user equipment may communicate with another user equipment via a direct communication interface, a UE (e.g., vehicle, user equipment, etc.) may communicate with an RSU via a direct communication interface, an RSU may communicate with another RSU via a direct communication interface, and so on.

[0081] Figure 4FIG. is a block diagram of an example of a vehicle computing system 450 that illustrates a vehicle 404. The vehicle 404 is an example of a UE that can communicate with a network (e.g., an eNB, a gNB, a positioning beacon, a position measurement unit, and / or other network entities) via the Uu interface and can communicate with other UEs using V2X communication via a PC5 interface, a C-V2X interface, or other device-to-device direct interfaces (such as a DSRC interface). As shown, the vehicle computing system 450 may include at least a power management system 451, a control system 452, an infotainment system 454, an intelligent transportation system (ITS) 455, one or more sensor systems 456, and a communication system 458. In some cases, the vehicle computing system 450 may include or may use any type of processing device or system to implement, such as one or more central processing units (CPUs), digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), application processors (APs), graphics processing units (GPUs), vision processing units (VPUs), neural network signal processors (NSPs), microcontrollers, dedicated hardware, any combination thereof, and / or other processing devices or systems.

[0082] The control system 452 may be configured to control one or more operations of the vehicle 404, the power management system 451, the computing system 450, the infotainment system 454, the ITS 455, and / or one or more other systems of the vehicle 404 (e.g., a braking system, a steering system, a safety system other than the ITS 455, a cab system, and / or other systems). In some examples, the control system 452 may include one or more electronic control units (ECUs). The ECU may control one or more electrical systems or subsystems in the vehicle. Examples of specific ECUs that may be included as part of the control system 452 include an engine control module (ECM), a powertrain control module (PCM), a transmission control module (TCM), a brake control module (BCM), a central control module (CCM), a central timing module (CTM), etc. In some cases, the control system 452 may receive sensor signals from one or more sensor systems 456 and may communicate with other systems of the vehicle computing system 450 to operate the vehicle 404.

[0083] The vehicle computing system 450 also includes a power management system 451. In some specific implementations, the power management system 451 may include a power management integrated circuit (PMIC), a backup battery, and / or other components. In some cases, other systems of the vehicle computing system 450 may include one or more PMICs, batteries, and / or other components. The power management system 451 may perform power management functions of the vehicle 404, such as managing the power supply of the computing system 450 and / or other parts of the vehicle. For example, the power management system 451 may provide a stable power supply in view of power fluctuations (such as based on starting the engine of the vehicle). In another example, the power management system 451 may perform thermal monitoring operations, such as by checking the ambient and / or transistor junction temperature. In another example, the power management system 451 may perform a certain function based on detecting a certain temperature level, such as causing a cooling system (e.g., one or more fans, an air conditioning system, etc.) to cool certain components of the vehicle computing system 450 (e.g., the control system 452, such as one or more ECUs), shutting down certain functionality of the vehicle computing system 450 (e.g., restricting the infotainment system 454, such as by turning off one or more displays, disconnecting from a wireless network, etc.), and other functions.

[0084] The vehicle computing system 450 also includes a communication system 458. The communication system 458 may include both software and hardware components for sending signals to a network (e.g., to a gNB or other network entity via the Uu interface) and / or to other UEs (e.g., to another vehicle or UE via the PC5 interface, a WiFi interface (e.g., DSRC), a Bluetooth TM interface, and / or other wireless and / or wired interfaces) and receiving signals from a network (e.g., from a gNB or other network entity via the Uu interface) and / or from other UEs (e.g., from another vehicle or UE via the PC5 interface, a WiFi interface (e.g., DSRC), a Bluetooth TM interface, and / or other wireless and / or wired interfaces). For example, the communication system 458 is configured to communicate via any suitable wireless network (e.g., a 3G network, a 4G network, a 5G network, a WiFi network, a Bluetooth TMsend and receive information wirelessly over a network and / or other networks. Communication system 458 includes various components or devices for performing wireless communication functionality, including an original equipment manufacturer (OEM) subscriber identity module (referred to as a SIM or SIM card) 460, a user SIM 462, and a modem 464. Although vehicle computing system 450 is shown as having two SIMs and one modem, in some embodiments, computing system 450 may have any number of SIMs (e.g., one SIM or more than two SIMs) and any number of modems (e.g., one modem, two modems, or more than two modems).

[0085] A SIM is a device (e.g., an integrated circuit) that can securely store the international mobile subscriber identity (IMSI) number and associated keys (e.g., encryption - decryption keys) of a specific subscriber or user. The IMSI and keys can be used to identify and authenticate the subscriber on a particular UE. The OEM SIM 460 can be used by communication system 458 to establish a wireless connection for vehicle - based operations, such as for making emergency calls (eCall) function, communicating with the vehicle manufacturer's communication system (e.g., for software updates, etc.), and other operations. The OEM SIM 460 can be very important for OEM SIM - supported critical services, such as the eCall for making an emergency call in the event of a car accident or other emergency. For example, eCall can include automatically dialing an emergency number (e.g., "9 - 1 - 1" in the United States, "1 - 1 - 2" in Europe, etc.) in the case of a vehicle accident and communicating the vehicle's location to emergency services (such as the police, fire department, etc.).

[0086] The user SIM 462 can be used by communication system 458 to perform wireless network access functions to support user data connections (e.g., for making phone calls, messaging, infotainment - related services, etc.). In some cases, the user's user equipment can be interfaced (e.g., via PC5, Bluetooth TM , WiFI TM(e.g., DSRC), a Universal Serial Bus (USB) port, and / or other wireless or wired interfaces) to the vehicle computing system 450. Once connected, the user device can transfer wireless network access functionality from the user device to the vehicle's communication system 458, in which case the user device can cease execution of the wireless network access functionality (e.g., during a period when the communication system 458 is performing wireless access functionality). The communication system 458 can begin interacting with a base station to perform one or more wireless communication operations, such as facilitating a phone call, sending and / or receiving data (e.g., messaging, video, audio, etc.), and other operations. In such cases, other components of the vehicle computing system 450 can be used to output data received by the communication system 458. For example, the infotainment system 454 (described below) can display video received by the communication system 458 on one or more displays, and / or can use one or more speakers to output audio received by the communication system 458.

[0087] A modem is a device that modulates one or more carrier signals to encode digital information for transmission and demodulates signals to decode the transmitted information. The modem 464 (and / or one or more other modems of the communication system 458) can be used for data communication with the OEM SIM 460 and / or the user SIM 462. In some examples, the modem 464 can include a 4G (or LTE) modem, and another modem (not shown) of the communication system 458 can include a 5G (or NR) modem. In some examples, the communication system 458 can include one or more Bluetooth TM modems (e.g., for Bluetooth TM Low Energy (BLE) or other types of Bluetooth communication), one or more WiFi TM modems (e.g., for DSRC communication and / or other WiFi communication), broadband modems (e.g., Ultra-Wideband (UWB) modems), any combination thereof, and / or other types of modems.

[0088] In some cases, the modem 464 (and / or one or more other modems of the communication system 458) can be used to perform V2X communications (e.g., V2V communications with other vehicles, D2D communications with other devices, V2I communications with infrastructure systems, V2P communications with pedestrian UEs, etc.). In some examples, the communication system 458 can include a V2X modem for performing V2X communications (e.g., sidelink communications via a PC5 interface or a DSRC interface), in which case the V2X modem can be separate from one or more modems for wireless network access functions (e.g., network communications via the network / Uu interface and / or sidelink communications other than V2X communications).

[0089] In some examples, the communication system 458 can be or can include a telematics control unit (TCU). In some embodiments, the TCU can include a network access device (NAD) (also referred to as a network control unit or NCU in some cases). The NAD can include the modem 464, Figure 4 any other modems not shown, the OEM SIM 460, the user SIM 462, and / or other components for wireless communication. In some examples, the communication system 458 can include a global navigation satellite system (GNSS). In some cases, the GNSS can be part of one or more sensor systems 456, as described below. The GNSS can provide the vehicle computing system 450 with the ability to perform one or more location services, navigation services, and / or other services that can utilize GNSS functionality.

[0090] In some cases, the communication system 458 can also include one or more wireless interfaces for sending and receiving wireless communications (e.g., including one or more transceivers and one or more baseband processors for each wireless interface), one or more wired interfaces for performing communications via one or more hardwired connections (e.g., serial interfaces such as universal serial bus (USB) inputs, lighting connectors, and / or other wired interfaces), and / or other components that can allow the vehicle 404 to communicate with the network and / or other UEs.

[0091] The vehicle computing system 450 may also include an infotainment system 454 that can control content and one or more output devices of the vehicle 404 that can be used to output content. The infotainment system 454 may also be referred to as an in-vehicle infotainment (IVI) system or an in-car entertainment (ICE) system. The content may include navigation content, media content (e.g., video content, music or other audio content, and / or other media content), and other content. The one or more output devices may include one or more graphical user interfaces, one or more displays, one or more speakers, one or more extended reality devices (e.g., VR, AR, and / or MR headsets), one or more haptic feedback devices (e.g., one or more devices configured to vibrate the seat, the steering wheel, and / or other parts of the vehicle 404), and / or other output devices.

[0092] In some examples, the computing system 450 may include an intelligent transportation system (ITS) 455. In some examples, the ITS 455 may be used to implement V2X communication. For example, the ITS stack of the ITS 455 may generate V2X messages based on information from the application layer of the ITS. In some cases, the application layer may determine whether certain conditions have been met to generate messages for use by the ITS 455 and / or to generate messages to be transmitted to other vehicles (for V2V communication), pedestrian UEs (for V2P communication), and / or infrastructure systems (for V2I communication). In some cases, the communication system 458 and / or the ITS 455 may obtain controller area network (CAN) information (e.g., from other components of the vehicle via the CAN bus). In some examples, the communication system 458 (e.g., the TCU NAD) may obtain CAN information via the CAN bus and may transmit the CAN information to the PHY / MAC layer of the ITS 455. The ITS 455 may provide the CAN information to the ITS stack of the ITS 455. The CAN information may include vehicle-related information, such as the forward direction of the vehicle, the speed of the vehicle, braking information, and other information. The CAN information may be provided to the ITS 455 continuously or periodically (e.g., every 1 millisecond (ms), every 10 ms, etc.).

[0093] The conditions for determining whether to generate a message can be determined using CAN information based on security-related applications and / or other applications (including applications related to road safety, traffic efficiency, infotainment, commerce, and / or other applications). In an illustrative example, ITS 455 can perform lane change assistance or negotiation. For example, using CAN information, ITS 455 can determine that the driver of vehicle 404 is attempting to change lanes from the current lane to an adjacent lane (e.g., based on the turn signal being activated, based on the user steering or turning into the adjacent lane, etc.). Based on determining that vehicle 404 is attempting to change lanes, ITS 455 can determine that a lane change condition has been met, which is associated with a message to be transmitted to other vehicles in the vicinity of that vehicle in the adjacent lane. ITS 455 can trigger the ITS stack to generate one or more messages to be sent to other vehicles, which can be used to negotiate a lane change with other vehicles. Other examples of applications include forward collision warning, automatic emergency braking, lane departure warning, pedestrian avoidance or protection (e.g., when a pedestrian is detected near vehicle 404, such as based on V2P communication with the user's UE), traffic sign recognition, etc.

[0094] ITS 455 can use any suitable protocol to generate messages (e.g., V2X messages). Examples of protocols that ITS 455 can use include one or more Society of Automotive Engineers (SAE) standards (such as SAE J2735, SAE J2945, SAE J3161, and / or other standards), which are hereby incorporated by reference in their entirety and used for all purposes.

[0095] The security layer of ITS 455 can be used to securely sign messages from the ITS stack, which are transmitted to and verified by other UEs configured for V2X communication, such as other vehicles, pedestrian UEs, and / or infrastructure systems. The security layer can also verify messages received from such other UEs. In some embodiments, the signing and verification processes can be based on the security context of the vehicle. In some examples, the security context can include one or more encryption-decryption algorithms, public and / or private keys used with the encryption-decryption algorithms to generate signatures, and / or other information. For example, each ITS message generated by ITS 455 can be signed by the security layer of ITS 455. A signature can be derived using a public key and an encryption-decryption algorithm. A vehicle, pedestrian UE, and / or infrastructure system receiving the signed message can verify the signature to ensure that the message is from an authorized vehicle. In some examples, one or more encryption-decryption algorithms can include one or more symmetric encryption algorithms (e.g., Advanced Encryption Standard (AES), Data Encryption Standard (DES), and / or other symmetric encryption algorithms), one or more asymmetric encryption algorithms using public and private keys (e.g., Rivest-Shamir-Adleman (RSA) and / or other asymmetric encryption algorithms), and / or other encryption-decryption algorithms.

[0096] In some examples, ITS 455 can determine certain actions to perform (e.g., V2X-based actions) based on messages received from other UEs. These actions can include security-related and / or other actions, such as actions for road safety, traffic efficiency, infotainment, commerce, and / or other applications. In some examples, these actions can include causing a vehicle (e.g., control system 452) to perform automated functions, such as automated braking, automated steering (e.g., maintaining a forward direction in a specific lane), automated lane change negotiation with other vehicles, and other automated functions. In an illustrative example, the communication system 458 can receive a message from another vehicle (e.g., via a PC5 interface, DSRC interface, or other device-to-device direct interface) indicating that the other vehicle is about to suddenly stop. In response to receiving the message, the ITS stack can generate a message or instruction and transmit the message or instruction to the control system 452, which can cause the control system 452 to automatically brake the vehicle 404 so that it stops before colliding with the other vehicle. In other illustrative examples, these actions can include triggering messages to display to the driver warning of another vehicle in a lane adjacent to the vehicle, warning the driver to stop the vehicle, warning the driver of a pedestrian at an upcoming intersection, warning the driver of a toll booth within a certain distance (e.g., within 1 mile) of the vehicle, etc.

[0097] In some examples, the ITS 455 may receive a large number of messages from other UEs (e.g., vehicles, RSUs, etc.). In such a case, the ITS 455 will authenticate (e.g., decode and decrypt) each message in the messages and / or determine which operations to perform. Such a large number of messages may result in a large computational load on the vehicle computing system 450. In some cases, the large computational load may cause the temperature of the computing system 450 to increase. The increase in the temperature of the components of the computing system 450 may adversely affect the ability of the computing system 450 to process a large number of incoming messages. One or more functions may transition from the vehicle 404 to another device (e.g., a user device, an RSU, etc.) based on the temperature of the vehicle computing system 450 (or its components) exceeding or approaching one or more thermal levels. Transitioning one or more functions may reduce the computational load on the vehicle 404 and help reduce the temperature of the components. A thermal load balancer may be provided that enables the vehicle computing system 450 to perform thermal-based load balancing to control the processing load depending on the temperature of the computing system 450 and the processing capabilities of the vehicle computing system 450.

[0098] The computing system 450 also includes one or more sensor systems 456 (e.g., a first sensor system to an Nth sensor system, where N is a value equal to or greater than 0). When multiple sensor systems are included, the sensor systems 456 may include different types of sensor systems that may be arranged on or in different parts of the vehicle 404. The sensor systems 456 may include one or more camera sensor systems, LIDAR sensor systems, radio detection and ranging (RADAR) sensor systems, electromagnetic detection and ranging (EmDAR) sensor systems, sound navigation and ranging (SONAR) sensor systems, sound detection and ranging (SODAR) sensor systems, global navigation satellite system (GNSS) receiver systems (e.g., one or more global positioning system (GPS) receiver systems), accelerometers, gyroscopes, inertial measurement units (IMUs), infrared sensor systems, laser rangefinder systems, ultrasonic sensor systems, infrasound sensor systems, microphones, any combination thereof, and / or other sensor systems. It should be understood that any number of sensors or sensor systems may be included as part of the computing system 450 of the vehicle 404.

[0099] In some implementations, the vehicle computing system 450 may also include (e.g., as part of or separate from the control system 452, the infotainment system 454, the communication system 458, and / or the sensor system 456) at least one processor 466 and at least one memory 468 having computer executable instructions executed by the at least one processor. The at least one processor communicates with and / or is electrically connected to (referred to as "coupled to" or "communicatively coupled to") the at least one memory. The at least one processor 466 may include, for example, one or more microcontrollers, one or more central processing units (CPUs), one or more field programmable gate arrays (FPGAs), one or more graphics processing units (GPUs), one or more application processors (e.g., for running or executing one or more software applications), and / or other processors. The at least one memory may include, for example, a read-only memory (ROM), a random access memory (RAM) (e.g., a static RAM (SRAM)), an electrically erasable programmable read-only memory (EEPROM), flash memory, one or more buffers, one or more databases, and / or other memory. The computer executable instructions stored in or on at least the memory may be executed to perform one or more functions or operations described herein. In some cases, at least one processor 466 may be configured to perform one or more operations associated with storing and / or retrieving data in a ledger-based data storage device (e.g., a blockchain). For example, at least one processor 466 may be configured to perform operations associated with: Figure 9A The blockchain ledger 900 described, such as Figure 9B One or more operations associated with the distributed ledger 995 described herein, other distributed ledgers, and / or any combination thereof. In some cases, data for a ledger-based data storage device may be obtained from Figure 4 At least one memory 468 is used to store and / or retrieve information.

[0100] Although the vehicle computing system 450 is shown as including certain components and / or systems, one of ordinary skill in the art will appreciate that the vehicle computing system 450 may include more than Figure 4 More or fewer components than those shown. For example, the vehicle computing system 450 may also include one or more input devices and one or more output devices (not shown).

[0101] Figure 5An example of the computing system 570 of the user equipment 507 is illustrated. The user equipment 507 is an example of a UE that can be used by an end user. For example, the user equipment 507 may include a mobile phone, a router, a tablet computer, a laptop computer, a tracking device, a wearable device (e.g., a smart watch, glasses, an XR device, etc.), an Internet of Things (IoT) device, and / or other devices used by the user to communicate via a wireless communication network. The computing system 570 includes software and hardware components that can be electrically coupled or communicatively coupled via a bus 589 (or may communicate in other ways as appropriate). For example, the computing system 570 includes one or more processors 584. The one or more processors 584 may include one or more CPUs, ASICs, FPGAs, APs, GPUs, VPUs, NSPs, microcontrollers, dedicated hardware, any combination thereof, and / or other processing devices or systems. The bus 589 may be used by the one or more processors 584 to communicate between cores and / or with one or more memory devices 586.

[0102] The computing system 570 may also include one or more memory devices 586, one or more digital signal processors (DSPs) 582, one or more SIMs 574, one or more modems 576, one or more wireless transceivers 578, an antenna 587, one or more input devices 572 (e.g., a camera, a mouse, a keyboard, a touch-sensitive screen, a touchpad, a keypad, a microphone, etc.), and one or more output devices 580 (e.g., a display, a speaker, and / or a printer, etc.).

[0103] One or more wireless transceivers 578 may receive wireless signals (e.g., signal 588) from one or more other devices such as other user equipment, a vehicle (e.g., the vehicle 404 described above) Figure 4 , a network device (e.g., a base station such as an eNB and / or a gNB, a WiFi router, etc.), and / or a cloud network, etc. In some examples, the computing system 570 may include multiple antennas. The wireless signal 588 may be transmitted via a wireless network. The wireless network can be any wireless network such as a cellular or telecommunications network (e.g., 3G, 4G, 5G, etc.), a wireless local area network (e.g., a WiFi network), a Bluetooth TM network, and / or other networks. In some examples, one or more wireless transceivers 578 may include an RF front end that includes one or more components such as an amplifier, a mixer for down-converting the signal (also known as a signal multiplier), a frequency synthesizer (also known as an oscillator) that supplies the signal to the mixer, a baseband filter, an analog-to-digital converter (ADC), one or more power amplifiers, and other components. The RF front end generally can handle the selection of the wireless signal 588 and the conversion of the wireless signal to the baseband or intermediate frequency, and can convert the RF signal to the digital domain.

[0104] In some cases, computing system 570 may include a codec (or coder-decoder) configured to encode and / or decode data transmitted and / or received using one or more wireless transceivers 578. In some cases, computing system 570 may include an encryption-decryption device or component configured to encrypt and / or decrypt (e.g., according to AES and / or DES standards) data transmitted and / or received by one or more wireless transceivers 578.

[0105] Each of one or more SIMs 574 may securely store the IMSI number and associated keys assigned to the user of user equipment 507. As noted above, the IMSI and keys may be used to identify and authenticate a subscriber when accessing a network provided by a network service provider or carrier associated with one or more SIMs 574. One or more modems 576 may modulate one or more signals to encode information for transmission using one or more wireless transceivers 578. One or more modems 576 may also demodulate signals received by one or more wireless transceivers 578 to decode the transmitted information. In some examples, one or more modems 576 may include a 4G (or LTE) modem, a 5G (or NR) modem, a modem configured for V2X communication, and / or other types of modems. One or more modems 576 and one or more wireless transceivers 578 may be used to communicate data of one or more SIMs 574.

[0106] Computing system 570 may also include one or more non-transitory machine-readable storage media or storage devices (e.g., one or more memory devices 586) (and / or communicate with them), which may include but are not limited to local and / or network-accessible storage, disk drives, drive arrays, optical storage devices, solid-state storage devices (such as RAM and / or ROM), which may be programmable, flash-updateable, and / or the like. Such storage devices may be configured to implement any suitable data storage, including but not limited to various file systems, database structures, etc.

[0107] In some cases, one or more processors 584 may be configured to perform one or more operations associated with storing and / or retrieving data in a ledger-based data storage device (e.g., a blockchain). For example, one or more processors 584 may be configured to perform operations related to the blockchain ledger 900 as described with respect to Figure 9A and as described with respect to Figure 9BOne or more operations associated with the described distributed ledger 995, other distributed ledgers, and / or any combination thereof. In some cases, data for a data storage device based on the ledger may be stored and / or retrieved from Figure 5 one or more memory devices 586.

[0108] In various aspects, functionality may be stored as one or more computer program products (e.g., instructions or code) in a memory device 586 and executed by one or more processors 584 and / or one or more DSPs 582. The computing system 570 may also include software elements (e.g., located within one or more memory devices 586), including, for example, an operating system, device drivers, executable libraries, and / or other code, such as one or more applications, which may include computer programs implementing the functionality provided by the various aspects, and / or may be designed to implement methods and / or configure systems as described herein.

[0109] Figure 6 is a flowchart of a process 600 that illustrates an example process for event-based network and blockchain formation. At block 602, process 600 may include the detection of an event. As used herein, an event may refer to any occurrence that, when detected, causes one or more electronic devices to initiate network and blockchain formation. For example, an event may be detected based on data collected by one or more devices (such as Figure 3 the RSU 303, vehicle 304, vehicle 305, user device 307, Figure 4 the vehicle computing system 450 of Figure 5 the computing system 570), any other data associated with the event, and / or any combination thereof. In an illustrative example, an event may include a potential hazard indicated by data collected from one or more devices.

[0110] In an illustrative example, a traffic accident is an event that may benefit from data collection by an ad-hoc network. For example, a traffic accident may include any type of vehicle collision or near collision with another vehicle, pedestrian, animal, road debris, or other stationary obstacle. Although a traffic accident is provided as an example event for illustrative purposes, it should be understood that the systems and techniques described herein may be used for data collection related to events that may or may not involve vehicles.

[0111] Figure 7 is a diagram illustrating an example of a system 700 that may utilize event-based network and / or blockchain formation according to some examples of the present disclosure. In Figure 7In [the figure], system 700 is shown as including a plurality of equipped (e.g., having V2X capabilities) network devices. The plurality of equipped network devices includes vehicles (e.g., cars) 710a, 710b, 710c, 710d and RSU 705. Also shown is a plurality of un-equipped network devices, the plurality of un-equipped network devices including un-equipped vehicles 720, VRUs (e.g., cyclists) 730, and pedestrians 740. System 700 may include more or fewer equipped network devices and / or more or fewer un-equipped network devices as shown, for example Figure 7 In [the figure]. Additionally, system 700 may include more or fewer different types of equipped network devices (e.g., it may include equipped UEs) and / or more or fewer different types of un-equipped network devices (e.g., it may include un-equipped UEs) as shown, for example Figure 7 In [the figure]. Additionally, in one or more examples, the equipped network devices may be equipped with a variety of capabilities, which may include but are not limited to C-V2X / DSRC capabilities, 4G / 5G cellular connectivity, GPS capabilities, camera capabilities, radar capabilities, and / or LIDAR capabilities.

[0112] The plurality of equipped network devices may be capable of performing V2X communication. Additionally, at least some of the equipped network devices are configured to transmit and receive sensing signals for radar (e.g., RF sensing signals) and / or LIDAR (e.g., optical sensing signals) to detect nearby vehicles and / or objects. Additionally or alternatively, in some cases, at least some of the equipped network devices are configured to use one or more cameras to detect nearby vehicles and / or objects (e.g., by processing images captured by the one or more cameras to detect these vehicles / objects). In one or more examples, vehicles 710a, 710b, 710c, 710d and RSU 705 may be configured to transmit and receive certain sensing signals (e.g., radar and / or LIDAR sensing signals).

[0113] In some examples, some of the equipped network devices in the equipped network devices may have sensors with higher capabilities than other equipped network devices of system 700 (e.g., GPS receivers, cameras, RF antennas, and / or optical lasers and / or optical sensors). For example, vehicle 710b may be a luxury vehicle and thus have more expensive and higher-capability sensors than other vehicles that are economy vehicles. In an illustrative example, vehicle 710b may have one or more LIDAR sensors (e.g., high-capability optical lasers and optical sensors) with higher capabilities than other equipped network devices in system 700. In an illustrative example, the LIDAR of vehicle 710b may be able to detect VRUs (e.g., bicyclists) 730 and / or pedestrians 740 with a high confidence level (e.g., a confidence level of seventy percent). In another example, vehicle 710b may have a radar with higher capabilities than other equipped network devices in system 700 (e.g., a high-capability RF antenna). For example, the radar of vehicle 710b may be able to detect VRUs (e.g., bicyclists) 730 and / or pedestrians 740 with a confidence level (e.g., a confidence level of eighty-five percent). In another example, vehicle 710b may have a camera with higher capabilities than other equipped network devices in system 700 (e.g., having a higher resolution capability, a higher frame rate capability, a better lens, etc.).

[0114] During operation of system 700, the equipped network devices (e.g., RSU 705 and / or at least one of vehicles 710a, 710b, 710c, 710d) may send and / or receive sensing signals (e.g., RF and / or optical signals) to sense and detect vehicles (e.g., vehicles 710a, 710b, 710c, 710d, and 720) and / or objects (e.g., VRUs 730 and pedestrians 740) located within and around the road. Then, the equipped network devices (e.g., at least one of vehicles 710a, 710b, 710c, 710d and / or RSU 705) may use the sensing signals to determine the characteristics (e.g., motion, size, type, forward direction, and speed) of the detected vehicles and / or objects. The equipped network devices (e.g., RSU 705 and / or at least one of vehicles 710a, 710b, 710c, 710d) may generate at least one vehicle-based message 715 (e.g., a V2X message, such as an SDSM, BSM, CAM, CPM, and / or other types of messages), the at least one vehicle-based message including information related to the determined characteristics of the detected vehicles and / or objects.

[0115] The vehicle-based message 715 may include information related to the detected vehicle or object (e.g., the location of the vehicle or object, the accuracy of the location, the speed of the vehicle or object, the direction in which the vehicle or object is traveling, and / or other information related to the vehicle or object), traffic conditions (e.g., low-speed and / or dense traffic, high-speed traffic, information related to an accident, etc.), weather conditions (e.g., rain, snow, etc.), message type (e.g., emergency message, non-emergency or "regular" message, etc.), road topology (line-of-sight (LOS) or non-line-of-sight (NLOS), etc.), any combination thereof, and / or other information. In some examples, the vehicle-based message 715 may also include information about the preference of the equipped network device for receiving vehicle-based messages from certain other equipped network devices. In some cases, the vehicle-based message 715 may include the current capabilities of the equipped network devices (e.g., vehicles 710a, 710b, 710c, 710d), such as the sensing capabilities of the equipped network devices (which may affect the accuracy of the equipped network devices in sensing vehicles and / or objects), processing capabilities, the thermal state of the equipped network devices (which may affect the vehicle's ability to process data), and the health state of the equipped network devices.

[0116] In some aspects, the vehicle-based message 715 may include a dynamic neighbor list (also referred to as a local dynamic map (LDM) or a dynamic surrounding map) for each of the equipped network devices (e.g., vehicles 710a, 710b, 710c, 710d and RSU 705). For example, each dynamic neighbor list may include a list of all vehicles and / or objects located within a specific predetermined distance (or distance radius) from the corresponding equipped network device. In some cases, each dynamic neighbor list includes a mapping of all vehicles and / or objects located within a specific predetermined distance (or distance radius) from the corresponding equipped network device, which may include road and terrain topologies. For example, the predetermined distance may include, but is not limited to, up to one hundred (100) yards, up to one thousand yards (1000), up to one mile, and / or any other predetermined distance. In an illustrative example, the distance (or distance radius) between the equipped network device and the object may be determined based on the location information of the configured network device and / or object included in the vehicle-based message 715 and the current location of the equipped network device generating the dynamic neighbor list.

[0117] Return Figure 6, in an illustrative example, at block 602, process 600 may determine that a vehicle accident may have occurred based on a sensed signal, sensor data (e.g., video data, LIDAR data, RADAR data, etc.), and / or the content of at least one vehicle-based message 715 in which an event (e.g., a vehicle accident) may have occurred and / or has occurred.

[0118] At block 604, after detecting an event, process 600 may generate a network formation request. In some cases, the network formation request may be broadcast to devices in a predefined area associated with the detected event. In some cases, initiating the network formation request may include generating an event identifier (ID). In some cases, initiating the network formation request may include determining the scope of the network. For example, the scope of the network may include the network formation location. In an illustrative example, the location may be restricted to a specified distance from the event. In another illustrative example, the location may be restricted to the range of the communication signal capabilities of the initiating device. In some cases, the network formation request may include a timestamp of the event, a timestamp of when the network formation request was initiated, other timestamps related to the event, and / or any combination thereof. In some cases, the network formation request may include the communication protocol capabilities of the initiating device (e.g., Figure 3 RSU 303, vehicle 304, vehicle 305, user equipment 307, Figure 4 the vehicle computing system 450 of Figure 5 the computing system 570 of Figure 7 vehicles 710a, 710b, 710c, 710d of Figure 8 UEs 802, 804, 806 or RSU 805). In some cases, a device receiving the network formation request may determine whether to participate in event-based network formation and / or a blockchain based on the network formation request.

[0119] At block 606, process 600 may include broadcasting the network formation request. For example, process 600 may broadcast the network formation request to multiple devices. As used herein, any device participating in an event-based network may be referred to as a "target" device. In an illustrative example, the transmission may be based on a mode in DSRC, NR C-V2X, LTE V2X, any other communication protocol, and / or any combination thereof.

[0120] Figure 8 Illustrate an example of an event-based network configuration 800 according to some aspects of the present disclosure. In some cases, the network formation scope may be determined during the generation of the network formation request at block 604 of process 600. Figure 8 of Figure 8As illustrated, the network formation range may include a location 801 for network formation. In one illustrative example, UE 802 may generate a network formation request. As Figure 8 shown, UE 802 may broadcast 814 the network formation request. As shown in the figure, UE 808 may be located outside the location 801. In some cases, UE 808 may be excluded from the network formation request. In some cases, the network formation request may be received by receiving UEs 804, 806, 808. Although UEs 802, 804, 806, and 808 are Figure 8 illustrated as vehicles in, the network formation request may be broadcast by an initiating device (e.g., UE 802) to other UEs such as mobile devices, sensors, etc. In some cases, the network broadcast 814 may be broadcast or multicast to nearby devices. In some cases, the devices participating in the network may not share a common communication capability. For example, UE 806, for example, UE 806 may send 816 communications intended to be received by other UEs within the location 801 specified in the network formation request. Additionally / alternatively, RSU 805 may receive communications from UEs 802, 804, 806, 808 and / or broadcast 818 the communications to these UEs. UEs 802, 804, 806, 808 or RSU 805. In some cases, RSU 805 may initiate network formation and / or broadcast 818 the network formation request. In some cases, another UE (not shown) near the event may initiate network formation and / or broadcast the network formation request.

[0121] Return Figure 6 , at block 608, process 600 may receive event data from one or more devices participating in an event-based network (e.g., Figure 3 RSU 303, vehicle 304, vehicle 305, user equipment 307, Figure 4 vehicle computing system 450 of, Figure 5 computing system 570 of, Figure 7 vehicles 710a, 710b, 710c, 710d of, Figure 8 UEs 802, 804, 806 or RSU 805 of). In some cases, the received data may include at least one or more of the data captured by an input device (e.g., Figure 5 input device 572 of). Such as video data, audio data, etc. In some examples, the received data may include sensor data (e.g., from one or more sensor systems 456). In some cases, the data received from network participants may include a vehicle data log (e.g., data related to acceleration, braking, turning, and / or distance keeping). In some aspects, the data may include RADAR data, LIDAR data, etc.

[0122] In some embodiments, data received from one or more devices participating in an event-based network may include data collected by the one or more devices (e.g., sensor data, video data, audio data, etc.). In some examples, data received from the one or more devices may include a hash of the data collected by the one or more devices. In some cases, the captured data may be retained on the participating devices. In some cases, if there is a need for the original data (e.g., the captured data itself), the hash may be used to verify the authenticity of the data provided by the owner of the captured data. In some cases, providing a hash of the captured data rather than the data itself may provide privacy for the owners of the devices participating in the network. For example, if data collected from a UE's video camera does not capture an event (e.g., a vehicle accident), but instead captures video of passengers, scenery, etc., the hashed data may not reveal the content of the video. In some cases, if needed, the owner of the collected data may opt in to sharing the collected data. For example, in the case of a vehicle accident, the collected data may be requested as evidence in a legal proceeding. In such cases, the hashed data may be used to authenticate the timing and / or location of the data collection without the need to directly store the collected data. In addition to providing privacy benefits, hashed data may also be smaller in size than the collected data. In some cases, the hashed data may have a fixed size that does not depend on the size of the collected data (e.g., 128 bytes, 256 bytes, 512 bytes, 1024 bytes). For example, a video recording of several hundred megabytes (MB) may be represented by 1 kilobyte (KB) of hashed data. Thus, the amount of communication bandwidth required to collect event-based data may be limited. In some examples, the total amount of storage required to collect event-based data may also be reduced by storing the hashed data rather than the collected data itself.

[0123] Return Figure 6 , at block 610, process 600 may append the collected data to a blockchain. In some cases, the blockchain may be shared and stored mutually by the participating devices in the event-based network. In some cases, a centralized blockchain server may not be required to store the blockchain. In some aspects, the blockchain is well-suited for event-based data collection due to its construction of trust in a decentralized, distributed, and autonomous manner. As used herein, a blockchain includes any distributed database having electronic transactions and / or events stored in a ledger and shared among participating members of the blockchain. Process 600 may then share the blockchain with the new appended data with the devices participating in the event-based network.

[0124] Figure 9A is a block diagram illustrating three consecutive blocks of an example blockchain ledger 900 that may be used to store data collected from devices participating in an event-based network according to aspects of the present disclosure.Figure 9A Illustrative examples of three blocks of the blockchain ledger 900, including block A 905, block B 935, and block C 965.

[0125] Each block includes a block header 910 / 940 / 970 and a list of one or more payloads 930 / 960 / 990. In some examples, the block header 910 / 940 / 970 includes the hash 915 / 945 / 975 of the previous block and / or the hash 910 / 940 / 970 of the block header of the previous block, collectively referred to herein as "block hash". For example, the header 970 of block C 965 includes the hash 975 of the header 940 of block B 935. The header 940 of block B 935 similarly includes the hash 945 of the header 910 of block A 905. The header 910 of block A 905 similarly includes the hash 915 of the header (not shown) of the previous block (not shown) preceding block A 905 in the blockchain ledger 900. Including the hash of the header of the previous block protects the blockchain ledger 900 by preventing any block of the blockchain ledger 900 from being modified after the block has been entered into the blockchain ledger 900, because any change to a particular block will cause the hash 915 / 945 / 975 of the block header in the next block to be incorrect. In addition, modifying the hash of the block header in the next block will cause the hash 915 / 945 / 975 of the header of the next block in the block after the next block to be incorrect, and so on. The verification device can verify that the block has not been modified by calculating the hash of the block and / or the block header and then comparing the calculated hash with the stored hash 915 / 945 / 975 stored in the next block. In some distributed ledgers, the block header 910 / 940 / 970 can include the hashes of multiple previous blocks and / or the hashes of the block headers of multiple previous blocks, such as in a distributed acyclic graph (DAG) ledger.

[0126] The block headers 910 / 940 / 970 of each block may include Merkle roots 920 / 950 / 980. The Merkle roots 920 / 950 / 980 may be generated based on the hash of each of the event data (e.g., the collected data and / or hashed data), transactions, smart contracts, and / or other elements identified in the payloads 930 / 960 / 990 of the block. Any attempt to modify the payload after it has entered the block will change the Merkle root. The verification device may verify that the payloads 930 / 960 / 990 have not been modified by calculating the Merkle root and then comparing the calculated Merkle root with the stored Merkle roots 920 / 950 / 980 stored in the block headers 910 / 940 / 970. Changes to the payloads 930 / 960 / 990 and / or to the Merkle roots 920 / 950 / 980 will also change the hash of the block and / or the block header, for which the value is stored as a hash 915 / 945 / 975 in the next block. Each payload of each block may include one or more event data, tokens, one or more transactions, one or more smart contracts, other content, or a combination thereof.

[0127] The block headers 910 / 940 / 970 of each block may also include various elements of metadata, such as the version number of the blockchain ledger platform, the version number of the block itself, a timestamp for verifying each payload, a timestamp for generating the block, a timestamp for entering the block entry into the blockchain ledger 900, a timestamp for requesting the generation of the block, a difficulty target value (e.g., adjusting the mining difficulty), one or more randomized nonce values, a counter identifying how many nonces have been attempted, the title of the blockchain ledger 900, an identifier regarding what the blockchain ledger 900 is tracking (e.g., the data history associated with the triggering event), or a combination thereof. Each individual element added may further be used as information verifiable by the verification device to identify whether the block and the payloads within it are accurate and authorized. One or more randomized nonce values may be used to further complicate the hash, thereby enhancing security.

[0128] Each block 905 / 935 / 965 of the blockchain ledger 900 also includes a payload 930 / 960 / 990. The payload 930 / 960 / 990 of each block 905 / 935 / 965 may include one or more event data (e.g., the collected data and / or hash data), one or more tokens, one or more transactions, one or more smart contracts, one or more other elements, metadata related to any of the previously listed elements, or a combination thereof. In some cases, certain portions of the payload (e.g., event data) may be stored within the payload 930 / 960 / 990 of the blockchain ledger 900 and are thus stored "on-chain". In some cases, certain portions of the payload (e.g., event data) may include an on-chain pointer to data outside of the blockchain ledger 900, where such data is stored "off-chain". The payload 930 / 960 / 990 of the blockchain ledger 900 may store the hash of the off-chain data such that a verification device can compute the hash of the off-chain data and compare the computed hash with the stored hash stored on-chain to verify that the off-chain data is accurate.

[0129] In an illustrative example, a first computing device may store a blockchain ledger including a plurality of blocks. Each computing device among a plurality of computing devices (e.g., in a distributed architecture) also stores a copy of the blockchain ledger. The first computing device may receive a message identifying an expected payload element (e.g., event data). For example, the expected payload element may be the collected data (e.g., sensor data, video, audio, etc.) and / or hash data associated with the collected video data. The first computing device may verify that the expected payload element is valid.

[0130] The first computing device may generate a hash of the most recent block or block header of the blockchain ledger 900. The first computing device may generate a new block header for the new block. The new block header may at least include the hash of the most recent block or block header of the blockchain ledger 900. The first computing device may generate a new block that includes the new block header and a payload having one or more payload elements. The one or more payload elements at least include the expected payload element (e.g., event data) discussed above. The first computing device may generate a Merkle root based on the payload elements and include the Merkle root in the new block header. The first computing device may generate metadata and a random number value based on the payload elements and include the metadata and the random number value in the new block header. The first computing device may append the new block to the plurality of blocks of the blockchain ledger 900 in response to verifying the expected payload element. The first computing device may send the new block to the plurality of computing devices that each store a copy of the blockchain ledger 900 in response to verifying the expected payload element. Each computing device among the plurality of computing devices also appends the new block to its respective copy of the blockchain ledger 900.

[0131] In another illustrative example, a first computing device may store a blockchain ledger 900 that includes a plurality of blocks. Each computing device among a plurality of computing devices (e.g., in a distributed architecture) also stores a copy of the blockchain ledger 900. The first computing device may receive a UI input that identifies an expected payload element (e.g., event data). The first computing device may generate a message that identifies the expected payload element. The first computing device may retrieve a private key associated with an account corresponding to the first computing device. The first computing device may modify the message by encrypting at least a portion of the message with the private key. The first computing device may send the message to a plurality of computing devices other than the first computing device (e.g., other participants in an event-based network). A second computing device among the plurality of computing devices verifies that the expected payload element is valid, e.g., as described in the preceding paragraphs. The first computing device receives a new block from the second computing device. The new block identifies and / or includes the expected payload element (e.g., in its payload). The first computing device appends the new block to the plurality of blocks of the blockchain ledger 900 at the first computing device.

[0132] Although Figure 9A only three blocks 905 / 935 / 965 of the blockchain ledger 900 are illustrated, it should be understood that any blockchain ledger or distributed ledger discussed herein may be longer or shorter and may have more than three blocks or fewer than three blocks.

[0133] Figure 9B is a block diagram of an illustrative example distributed ledger 995. In the example distributed ledger 995, blocks 912 of the blockchain ledger may be stored in a plurality of parallel blockchains 911. In the illustrated example, rather than pruning a forked blockchain, the payload of each block 912 (e.g., payloads 930 / 960 / 990) may include a first pointer 914 to the most recently received block. Additionally, the payload (e.g., payloads 930 / 960 / 990) may include a second pointer to the most recently transmitted block. Using the first pointer 914 and the second pointer 916, the distributed ledger 995 may maintain an accurate accounting and ordering of the blocks appended to the distributed ledger 995, even though individual blocks are included in separate, individual blockchains 911. In some cases, such a distributed ledger may robustly store event data received from a plurality of participating event-based network devices. As used herein, the pointers 914, 916 may be referred to as "block pointers."

[0134] In some cases, it may be desirable for instances of a blockchain stored on different devices (e.g., participants in an event-based network) to be the same. However, in some cases, participating devices may send and / or receive data from different network participants at different times. In some cases, different instances of a blockchain may be referred to as branches and / or forks. In some specific implementations, branches and / or forks may be pruned (e.g., deleted, abandoned, etc.).

[0135] Return Figure 6 , in an illustrative example, at block 610, process 600 may determine the order in which data is appended to a blockchain ledger. In some cases, process 600 may broadcast a message to participating network devices in its central role. In some specific implementations, if a device participating in an event-based network acknowledges the message, process 600 may broadcast the append order to the participating devices.

[0136] In another illustrative example, process 600 may append data to a blockchain based on certain conditions. For example, process 600 may append data to a blockchain only if the blockchain does not already include the collected data (and / or associated hash data) collected by the originating device. In some cases, process 600 may determine whether to append the collected data to the chain based on the length of the chain. For example, the length of the chain may be included in a payload (e.g., Figure 9A payloads 930, 960, 980). In some cases, each participating device in an event-based network may add data to the blockchain only once. In some cases, participating devices may append data to the blockchain sequentially in multiple rounds of appending data to the blockchain. For example, in some cases, an originating device (or another device agreed upon by the participants in the blockchain) may establish an append order that specifies the order in which each participant in the blockchain is allowed to append to the blockchain. In some cases, the first device in the append order may be allowed to add data to the blockchain during the first round, the second device in the append order may be allowed to add data to the blockchain during the second round, and each subsequent device in the append order may append data to the blockchain according to the append order until data from each participant has been appended to the blockchain.

[0137] Return Figure 6, at block 612, process 600 may determine whether an event has been completed. For example, the criteria for determining that an event has been completed may include, but are not limited to, the amount of time since the occurrence of the event, the amount of event data (hash data and / or collected data) stored in the blockchain, sensor data indicating the completion of the event, etc. In some cases, the amount of time may include, but is not limited to, 5 minutes, 15 minutes, 30 minutes, or any other fixed amount of time. In some cases, the amount of time may be determined based on the type of event. For example, the end of a transportation accident event may be determined by the typical response time of emergency service vehicles. In some cases, an event may have a planned duration (e.g., a social event, a concert, or any other planned event), and the time indicating the completion of the event may be determined by the planned end time of the event. In some cases, process 600 may determine that the event has been completed based on data received from one or more of the devices participating in the event-based network. In some cases, process 600 may determine that the event has been completed based on the length of the blockchain. For example, process 600 may determine that the event is completed when the blockchain includes 100, 1000, 10,000, or any other number of event data, 100, 1000, 10,000, or any other number of blocks, 100, 1000, 10,000, or any other number of MB data, and / or any other length measure of the blockchain. For example, one or more of the devices may broadcast an end event request. In some cases, process 600 may determine whether the end event request is appropriate (e.g., to prevent premature termination of the event-based network and the blockchain). In some cases, if process 600 determines that the event has not been completed, process 600 may return to block 608.

[0138] In some cases, at block 614, if process 600 determines that the event has been completed, process 600 may end event data collection. For example, process 600 may consider the content of the event data repository in the event-based blockchain as complete and interrupt adding data to the event-based blockchain. In some cases, process 600 may broadcast an end event request to other devices participating in the event-based network. In some cases, process 600 may interrupt communication with one or more target devices participating in the event-based network.

[0139] In some cases, after the event has ended and the blockchain has been finalized, the data may be retrieved later. In some cases, if only hash data is stored in the blockchain, any entity (e.g., the initiating device, a law enforcement agency, a court, or any other entity) may contact the participating devices to obtain the captured data. In some cases, the hash stored in the blockchain may be used to verify the captured data from the participating devices. In some cases, the blockchain content may also be compared across multiple participants in the event-based network.

[0140] This document describes systems and techniques for event-based networking and / or blockchain formation. In some cases, a network can be formed among devices near the location of an event when the event occurs. A distributed ledger-based storage device (e.g., a blockchain) can be used to build trust among participating members of the event-based network. Participating members of the event-based network may not be able to communicate directly with every member of the event-based network, but event data can still be distributed to all participating members as long as there is an indirect path for communication between the devices. Information stored in the blockchain can provide an ordered representation of the events, which can later be used as evidence of the occurrence of the events. Privacy of the participating members of the event-based network can be provided by storing hashed data on the blockchain and storing the collected data off-chain. The collected data can later be retrieved from one or more participating devices, and the hash can be used to verify the authenticity of the retrieved data. For example, the retrieved data can be hashed, and the resulting hash can be compared with the hashed data in the ledger. In some cases, if the resulting hash data matches the hashed data stored in the blockchain, the authenticity of the retrieved data can be verified. In some cases, the timestamp of the hashed data entry into the blockchain can be used to link the retrieved data to the event (e.g., if the timestamp matches the time of the event).

[0141] Figure 10 is a flowchart illustrating an example of a process 1000 for recording event data. At block 1002, process 1000 includes generating a network formation request based on an event (e.g., by UE 802). In some cases, generating the network formation request includes generating an event identifier (ID). In some examples, the event ID includes at least one or more of an event code, an event location, or an event timestamp.

[0142] At block 1004, process 1000 includes broadcasting the network formation request to one or more targets (e.g., UE 804, 806, RSU 805). In some examples, initiating the network formation request includes detecting the event by at least one or more of a roadside unit, a vehicle, or a mobile device.

[0143] At block 1006, process 1000 includes forming a network including at least one of one or more targets. In some examples, the network includes a V2X network, and the event data associated with the event includes at least one or more of the following: vehicle data logs. In some examples, the vehicle data logs include data related to at least one or more of acceleration, braking, turning, or distance keeping; video data; audio data; RADAR data; or LIDAR data. In some cases, forming the network includes receiving a response to a network formation request from at least one or one or more targets. In some examples, process 1000 includes establishing a communication link with at least one of one or more targets based on receiving the response to the network formation request.

[0144] At block 1008, process 1000 includes obtaining event data associated with the event from at least one of one or more targets. In some examples, the event data associated with the event includes hashed event data corresponding to detailed event data collected from at least one of one or more targets. In some aspects, the hashed event data can be used to verify the detailed event data.

[0145] At block 1010, process 1000 includes appending event data associated with the event obtained from one or more targets (e.g., in payloads 930, 960, 990) to a blockchain (e.g., blockchain ledger 900, distributed ledger 995). In some embodiments, the blockchain includes a plurality of blocks (e.g., block A 905, block B 935, block C 965, block 912), each block including at least a block hash (e.g., hash 915, hash 945, hash 975) and a payload (e.g., payload 930, payload 960, payload 990). In some examples, each block includes at least one block pointer (e.g., first pointer 914, second pointer 916). In some examples, the blocks in the plurality of blocks include hashed event data corresponding to detailed event data (e.g., included in the payload of the block). In some cases, the data size associated with the hashed event data is smaller than the data size associated with the detailed event data. In some examples, the detailed event data is stored outside the blockchain (e.g., stored by vehicles 710a, 710, 710c, 710d, UEs 804, 806, RSUs 805, and / or other devices).

[0146] In some cases, process 1000 includes ending the blockchain based on at least one or more of a time amount or blockchain length. In some examples, ending the blockchain includes broadcasting an end event request.

[0147] In some specific implementations, process 1000 includes receiving a first reply to a network formation request from a first target among one or more targets via a first physical layer connection, and receiving a second reply to the network formation request from a second target among one or more targets via a second physical layer connection. In some cases, the first physical layer connection and the second physical layer connection utilize different communication protocols.

[0148] Figure 11 is a block diagram illustrating an example of a computing system 1100 that can be used by the disclosed system for intelligent vehicle fault and driver misbehavior detection and warning according to some aspects of the present disclosure. Specifically, Figure 11 illustrates an example of a computing system 1100, which can be any computing device that constitutes an internal computing system, a remote computing system, a camera, or any component thereof, where components of the system communicate with each other using connection 1105. Connection 1105 can be a physical connection using a bus, or a direct connection into a processor 1110, such as in a chipset architecture. Connection 1105 can also be a virtual connection, a networked connection, or a logical connection.

[0149] In some aspects, computing system 1100 is a distributed system, where the functions described in the present disclosure can be distributed within one data center, multiple data centers, a peer-to-peer network, etc. In some aspects, one or more of the described system components represent many such components, each of which performs some or all of the functions of the described component. In some aspects, the components can be physical or virtual devices.

[0150] Example system 1100 includes at least one processing unit (CPU or processor) 1110 and connection 1105 that communicatively couples various system components including system memory 1115 (such as read-only memory (ROM) 1120 and random access memory (RAM) 1125) to processor 1110. Computing system 1100 can include a cache 1112 that is directly connected to, in close proximity to, or integrated as part of processor 1110 of high-speed memory.

[0151] Processor 1110 can include any general-purpose processor and hardware services or software services, such as services 1132, 1134, and 1136 stored in storage device 1130, which are configured to control processor 1110 and a dedicated processor in which software instructions are incorporated into the actual processor design. Processor 1110 can be substantially a fully independent computing system that includes multiple cores or processors, buses, memory controllers, caches, etc. The multi-core processor can be symmetric or asymmetric.

[0152] To enable user interaction, computing system 1100 includes an input device 1145 that can represent any number of input mechanisms, such as a microphone for voice, a touch-sensitive screen for gesture or graphical input, a keyboard, a mouse, motion input, voice, etc. Computing system 1100 may also include an output device 1135 that can be one or more of a plurality of output mechanisms. In some instances, a multimodal system may enable a user to provide multiple types of input / output to communicate with computing system 1100.

[0153] Computing system 1100 may include a communication interface 1140 that generally may govern and manage user input and system output. The communication interface may perform or facilitate receiving and / or sending wired or wireless communications using wired and / or wireless transceivers, including using audio jack / plug, microphone jack / plug, Universal Serial Bus (USB) port / plug, Apple TM Lightning TM port / plug, Ethernet port / plug, fiber optic port / plug, proprietary wired port / plug, 3G, 4G, 5G, and / or other cellular data network wireless signaling, Bluetooth TM wireless signaling, Bluetooth TM Low Energy (BLE) wireless signaling, iBeacon TM wireless signaling, Radio Frequency Identification (RFID) wireless signaling, Near Field Communication (NFC) wireless signaling, Dedicated Short Range Communication (DSRC) wireless signaling, 802.11 Wi-Fi wireless signaling, Wireless Local Area Network (WLAN) signaling, Visible Light Communication (VLC), Worldwide Interoperability for Microwave Access (WiMAX), Infrared (IR) communication wireless signaling, Public Switched Telephone Network (PSTN) signaling, Integrated Services Digital Network (ISDN) signaling, ad-hoc network signaling, radio wave signaling, microwave signaling, infrared signaling, visible light signaling, ultraviolet light signaling, wireless signaling along the electromagnetic spectrum, or some combination thereof.

[0154] The communication interface 1140 may also include one or more ranging sensors (e.g., LIDAR sensors, laser rangefinders, RF radars, ultrasonic sensors, and infrared (IR) sensors) configured to collect data and provide measurements to the processor 1110, whereby the processor 1110 may be configured to perform the determinations and calculations required to obtain the various measurements of the one or more ranging sensors. In some examples, the measurements may include time-of-flight, wavelength, azimuth, elevation, distance, linear velocity, and / or angular velocity or any combination thereof. The communication interface 1140 may also include one or more global navigation satellite system (GNSS) receivers or transceivers for determining the location of the computing system 1100 based on one or more signals received from one or more satellites associated with one or more GNSS systems. GNSS systems include, but are not limited to, the GPS in the United States, the Global Navigation Satellite System (GLONASS) in Russia, the Beidou Navigation Satellite System (BDS) in China, and the Galileo GNSS in Europe. There are no restrictions on operating on any particular hardware arrangement, and thus the underlying features here can be easily replaced to obtain improved hardware or firmware arrangements as they are developed.

[0155] The storage device 1130 may be a non-volatile and / or non-transitory and / or computer-readable memory device and may be a hard disk or other type of computer-readable medium that can store data accessible by a computer, such as cassette tapes, flash memory cards, solid-state memory devices, digital versatile discs, cartridges, floppy disks, hard disks, magnetic tapes, magnetic stripes, any other magnetic storage medium, flash memory, memristor memory, any other solid-state memory, compact disc read-only memory (CD-ROM) discs, rewritable compact discs (CDs), digital video discs (DVDs), Blu-ray discs (BDDs), holographic discs, another optical medium, secure digital (SD) cards, micro secure digital (microSD) cards, Cards, smart card chips, EMV chips, subscriber identity module (SIM) cards, mini / micro / nano / pico SIM cards, other integrated circuit (IC) chips / cards, random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash EPROM (FLASHEPROM), cache memory (e.g., level 1 (L1) cache, level 2 (L2) cache, level 3 (L3) cache, level 4 (L4) cache, level 5 (L5) cache, or other (L#) cache), resistive random access memory (RRAM / ReRAM), phase change memory (PCM), spin transfer torque RAM (STT-RAM), other memory chips or cartridges, and / or combinations thereof.

[0156] The storage device 1130 may include software services, servers, services, etc., and when the code defining such software is executed by the processor 1110, the code causes the system to perform functions. In some aspects, the hardware services that perform specific functions may include software components for performing the functions stored in a computer-readable medium connected to the necessary hardware components (such as the processor 1110, connection 1105, output device 1135, etc.). The term "computer-readable medium" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing, or carrying instructions and / or data. The computer-readable medium may include non-transitory media in which data can be stored and that do not include carrier waves and / or transient electronic signals propagated wirelessly or over a wired connection. Examples of non-transitory media may include, but are not limited to, magnetic disks or tapes, optical storage media (such as compact discs (CDs) or digital versatile discs (DVDs)), flash memory, memory, or memory devices. The computer-readable medium may have code and / or machine-executable instructions stored thereon, and the code and / or machine-executable instructions may represent a process, function, subroutine, program, routine, subroutine, module, software package, class, or any combination of instructions, data structures, or program statements. By passing and / or receiving information, data, arguments, parameters, or memory contents, a code segment may be coupled to another code segment or hardware circuit. The information, arguments, parameters, data, etc. may be passed, forwarded, or sent via any suitable means, including memory sharing, message passing, token passing, network transmission, etc.

[0157] Specific details are provided in the above description to provide a thorough understanding of the various aspects and examples presented herein, but those skilled in the art will recognize that the present application is not limited thereto. Thus, although the exemplary aspects of the present application have been described in detail herein, it is to be understood that the various inventive concepts may be implemented and employed in other various ways, and the appended claims are not to be construed as including such variations, unless limited by the prior art. The various features and aspects of the above applications may be used singly or in combination. In addition, without departing from the broader scope of the present specification, the aspects may be used in any number of environments and applications beyond those described herein. Therefore, the specification and drawings should be regarded as illustrative rather than restrictive. For illustrative purposes, the methods are described in a particular order. It should be understood that in alternative aspects, the methods may be performed in a different order than that described.

[0158] For clarity of explanation, in some instances, the present technology may be presented as including separate functional blocks that include devices, device components, steps, or routines in a method embodied in software or a combination of hardware and software. Additional components other than those shown in the figures and / or described herein may be used. For example, circuits, systems, networks, processes, and other components may be shown in block diagram form as components to avoid obscuring these aspects in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail to avoid obscuring the aspects.

[0159] Furthermore, those skilled in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithmic steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described in terms of their functional aspects. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such specific implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0160] The various aspects may be described above as a process or method depicted as a flowchart, flow diagram, data flow diagram, structure diagram, or block diagram. Although a flowchart may depict the operations as a sequential process, many of the operations may be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but a process may have additional steps not included in the figure. A process may correspond to a method, function, procedure, subroutine, subprogram, etc. When a process corresponds to a function, the termination of the process may correspond to the function returning to the calling function or the main function.

[0161] The processes and methods according to the above examples can be implemented using computer-executable instructions stored or otherwise obtained from a computer-readable medium. Such instructions can include, for example, instructions and data that cause or otherwise configure a general-purpose computer, a special-purpose computer, or a processing device to perform a certain function or group of functions. Portions of the computer resources used can be accessed via a network. The computer-executable instructions can be, for example, binary, intermediate format instructions such as assembly language, firmware, source code. Examples of computer-readable media that can be used to store instructions, the information used, and / or the information created during the methods according to the described examples include magnetic or optical disks, flash memory, USB devices with non-volatile memory, networked storage devices, etc.

[0162] In some aspects, computer-readable storage devices, media, and memories can include wires or wireless signals such as bitstreams. However, when mentioned, non-transitory computer-readable storage media explicitly exclude media such as power consumption, carrier signals, electromagnetic waves, and signals themselves.

[0163] Those skilled in the art should understand that information and signals can be represented using any of a variety of different technologies and methods. For example, the data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned in the above description can, in some cases, be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof, depending in part on the specific application, in part on the desired design, in part on the corresponding technology, etc.

[0164] The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein can be implemented or executed using hardware, software, firmware, middleware, microcode, a hardware description language, or any combination thereof, and can be in any form factor. When implemented in software, firmware, middleware, or microcode, the program code or code segments (e.g., a computer program product) for performing the necessary tasks can be stored in a computer-readable or machine-readable medium. The processor can execute the necessary tasks. Examples of form factors include: laptop devices, smartphones, mobile phones, tablet devices, or other personal computers with small form factors, personal digital assistants, rack-mounted devices, stand-alone devices, etc. The functionality described herein can also be embodied in peripheral devices or plug-in cards. By additional example, such functionality can also be implemented on a circuit board among different chips or different processes executed on a single device.

[0165] Instructions, the media for conveying such instructions, the computing resources for executing them, and other structures for supporting such computing resources are example components for providing the functionality described in this disclosure.

[0166] The techniques described herein may also be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques may be implemented in any of a variety of devices, such as a general-purpose computer, a wireless communication device handset, or an integrated circuit device with multiple uses, including applications in wireless communication device handsets and other devices. Any features described as modules or components may be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be at least partially realized by a computer-readable data storage medium including program code that includes instructions for performing one or more of the methods, algorithms, and / or operations described above when executed. The computer-readable data storage medium may form a part of a computer program product, which may include packaging materials. The computer-readable medium may include a memory or data storage medium, such as random access memory (RAM) (such as synchronous dynamic random access memory (SDRAM)), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, and the like. Additionally or alternatively, the techniques may be at least partially realized by a computer-readable communication medium that carries or conveys program code in the form of instructions or data structures that can be accessed, read, and / or executed by a computer, such as a propagated signal or wave.

[0167] The program code may be executed by a processor, which may include one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Such a processor may be configured to perform any of the techniques described in this disclosure. A general-purpose processor may be a microprocessor; but in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Thus, as used herein, the term "processor" may refer to any of the foregoing structures, any combination of the foregoing structures, or any other structure or device suitable for implementing the techniques described herein.

[0168] One of ordinary skill in the art should understand that, without departing from the scope of this specification, the less than (“<”) and greater than (“>”) symbols or terms used herein may be replaced by the less than or equal to (“≤”) and greater than or equal to (“≥”) symbols, respectively.

[0169] In cases where a component is described as “configured to” perform certain operations, such a configuration can be achieved, for example, by designing an electronic circuit or other hardware to perform the operations, by programming a programmable electronic circuit (e.g., a microprocessor or other suitable electronic circuit) to perform the operations, or any combination thereof.

[0170] The phrase “coupled to” or “communicatively coupled to” means that any component is directly or indirectly physically connected to another component, and / or any component directly or indirectly communicates with another component (e.g., connected to the other component through a wired or wireless connection and / or other suitable communication interface).

[0171] Claim language or other language that recites “at least one” of a set and / or “one or more” of a set indicates that one member of the set or multiple members of the set (in any combination) satisfy the claim. For example, claim language that recites “at least one of A and B” or “at least one of A or B” means A, B, or A and B. In another example, claim language that recites “at least one of A, B, and C” or “at least one of A, B, or C” means A, B, C, or A and B, or A and C, or B and C, or A and B and C. The language “at least one” of a set and / or “one or more” of a set does not limit the set to the items listed in the set. For example, claim language that recites “at least one of A and B” or “at least one of A or B” may mean A, B, or A and B, and may additionally include items not listed in the set of A and B.

[0172] Exemplary aspects of the present disclosure include:

[0173] Aspect 1. A method for recording event data, the method comprising: generating a network formation request based on an event; broadcasting the network formation request to one or more targets; forming a network including at least one of the one or more targets; obtaining event data associated with the event from at least one of the one or more targets; and appending the event data associated with the event obtained from the one or more targets to a blockchain.

[0174] Aspect 2. The method according to Aspect 1, wherein generating the network formation request includes: generating an event identifier (ID), wherein the event ID includes at least one or more of an event code, an event location, or an event timestamp.

[0175] Aspect 3. The method according to any one of Aspects 1 to 2, the method further comprising: ending the blockchain based on at least one or more of a time amount or a blockchain length.

[0176] Aspect 4. The method according to Aspect 3, wherein ending the blockchain includes broadcasting an end event request.

[0177] Aspect 5. The method according to any one of Aspects 1 to 4, wherein the event data associated with the event includes hash event data corresponding to detailed event data collected from at least one of the one or more targets, and the hash event data can be used to verify the detailed event data.

[0178] Aspect 6. The method according to any one of Aspects 1 to 5, wherein the blockchain includes a plurality of blocks, each block including at least a block hash and a payload.

[0179] Aspect 7. The method according to Aspect 6, wherein each block includes at least one block pointer.

[0180] Aspect 8. The method according to Aspect 6, wherein the blocks in the plurality of blocks include hash event data corresponding to detailed event data, and the data size associated with the hash event data is smaller than the data size associated with the detailed event data.

[0181] Aspect 9. The method according to Aspect 8, wherein the detailed event data is stored outside the blockchain.

[0182] Aspect 10. The method according to any one of Aspects 1 to 9, wherein initiating the network formation request includes: detecting the event by at least one or more of a roadside unit, a vehicle, or a mobile device.

[0183] Aspect 11. The method according to any one of Aspects 1 to 10, wherein the network includes a vehicle-to-everything (V2X) network, and the event data associated with the event includes at least one or more of the following: a vehicle data log, wherein the vehicle data log includes data related to at least one or more of acceleration, braking, turning, or distance keeping; video data; audio data; RADAR data; or LIDAR data.

[0184] Aspect 12. The method according to any one of Aspects 1 to 11, wherein forming the network includes receiving a reply to the network formation request from at least one or the one or more targets.

[0185] Aspect 13. The method according to aspect 12, the method further comprising: establishing a communication link with at least one of the one or more targets based on receiving the reply to the network formation request.

[0186] Aspect 14. The method according to aspect 12, the method further comprising: receiving a first reply to the network formation request from a first target among the one or more targets through a first physical layer connection, and receiving a second reply to the network formation request from a second target among the one or more targets through a second physical layer connection.

[0187] Aspect 15. The method according to aspect 14, wherein the first physical layer connection and the second physical layer connection utilize different communication protocols.

[0188] Aspect 16: The method according to any one of aspects 1 to 15, wherein appending event data to the blockchain includes at least one or more of the following: obtaining an appendix order from a control device; sequentially appending event data from devices participating in the network; performing branch reduction; performing fork reduction; or generating a hash map.

[0189] Aspect 17. An apparatus for recording event data, the apparatus comprising: at least one memory; and at least one processor, the at least one processor being coupled to the at least one memory and configured to: generate a network formation request based on an event; broadcast the network formation request to one or more targets; form a network including at least one of the one or more targets; obtain event data associated with the event from at least one of the one or more targets; and append the event data associated with the event obtained from the one or more targets to a blockchain.

[0190] Aspect 18. The apparatus according to aspect 17, wherein in order to generate the network formation request, the at least one processor is configured to generate an event ID, wherein the event ID includes at least one or more of an event code, an event location, or an event timestamp.

[0191] Aspect 19. The apparatus according to any one of aspects 17 to 18, wherein the at least one processor is configured to end the blockchain based on at least one or more of a time amount or a blockchain length.

[0192] Aspect 20. The apparatus according to aspect 18, wherein in order to end the blockchain, the at least one processor is configured to broadcast an end event request.

[0193] Aspect 21. The apparatus according to any one of aspects 17 to 20, wherein the event data associated with the event includes hashed event data corresponding to detailed event data collected from at least one of the one or more targets, and wherein the hashed event data can be used to verify the detailed event data.

[0194] Aspect 22. The apparatus according to any one of aspects 17 to 21, wherein the blockchain includes a plurality of blocks, each block including at least a block hash and a payload.

[0195] Aspect 23. The apparatus according to aspect 22, wherein each block includes at least one block pointer.

[0196] Aspect 24. The apparatus according to aspect 22, wherein the blocks in the plurality of blocks include hashed event data corresponding to detailed event data, and wherein the data size associated with the hashed event data is smaller than the data size associated with the detailed event data.

[0197] Aspect 25. The apparatus according to aspect 24, wherein the detailed event data is stored outside the blockchain.

[0198] Aspect 26. The apparatus according to any one of aspects 17 to 25, wherein initiating the network formation request includes: detecting the event by at least one or more of a roadside unit, a vehicle, or a mobile device.

[0199] Aspect 27. The apparatus according to any one of aspects 17 to 26, wherein the network includes a V2X network, and the event data associated with the event includes at least one or more of the following: a vehicle data log, wherein the vehicle data log includes data related to at least one or more of acceleration, braking, turning, or distance keeping; video data; audio data; RADAR data; or LIDAR data.

[0200] Aspect 28. The apparatus according to any one of aspects 17 to 27, wherein forming the network includes receiving a reply to the network formation request from at least one or the one or more targets.

[0201] Aspect 29. The apparatus according to aspect 28, wherein the at least one processor is configured to: establish a communication link with at least one of the one or more targets based on receiving the reply to the network formation request.

[0202] Aspect 30. The apparatus according to aspect 28, wherein the at least one processor is configured to: receive a first reply to the network formation request from a first target among the one or more targets via a first physical layer connection, and receive a second reply to the network formation request from a second target among the one or more targets via a second physical layer connection.

[0203] Aspect 31. The apparatus according to any one of aspects 17 to 30, wherein the first physical layer connection and the second physical layer connection utilize different communication protocols.

[0204] Aspect 32. The apparatus according to any one of aspects 17 to 31, wherein in order to append event data to the blockchain, the at least one processor is configured to perform at least one or more of the following: obtain an append order from a control device; sequentially append event data from devices participating in the network; perform branch reduction; perform fork reduction; or generate a hash graph.

[0205] Aspect 33. A non-transitory computer-readable storage medium having instructions stored thereon, the instructions when executed by one or more processors cause the one or more processors to perform any of the operations according to aspects 1 to 32.

[0206] Aspect 34. An apparatus comprising means for performing any of the operations according to aspects 1 to 32.

Claims

1. A method for recording event data, the method comprising: Generating a network formation request based on an event; Broadcasting the network formation request to one or more targets; Forming a network including at least one of the one or more targets; Obtaining event data associated with the event from at least one of the one or more targets; And Appending the event data associated with the event obtained from the one or more targets to a blockchain.

2. The method according to claim 1, wherein generating the network formation request comprises: Generating an event identifier (ID), where the event ID includes at least one or more of an event code, an event location, or an event timestamp.

3. The method according to claim 1, the method further comprising: Ending the blockchain based on at least one or more of a time quantity or a blockchain length.

4. The method according to claim 3, wherein ending the blockchain includes broadcasting an end event request.

5. The method according to claim 1, wherein the event data associated with the event includes hashed event data corresponding to detailed event data collected from at least one of the one or more targets, and the hashed event data can be used to verify the detailed event data.

6. The method according to claim 1, wherein: The blockchain includes a plurality of blocks, and each block includes at least a block hash and a payload.

7. The method according to claim 6, wherein each block includes at least one block pointer.

8. The method according to claim 6, wherein the blocks in the plurality of blocks include hashed event data corresponding to detailed event data, and the data size associated with the hashed event data is smaller than the data size associated with the detailed event data.

9. The method according to claim 8, wherein the detailed event data is stored outside the blockchain.

10. The method according to claim 1, wherein initiating the network formation request comprises: The event is detected by at least one or more of a roadside unit, a vehicle, or a mobile device.

11. The method according to claim 1, wherein the network includes a vehicle-to-everything (V2X) network, and the event data associated with the event includes at least one or more of the following: A vehicle data log, where the vehicle data log includes data related to at least one or more of acceleration, braking, turning, or distance keeping; Video data; Audio data; RADAR data; or LIDAR data.

12. The method according to claim 1, wherein forming the network includes receiving a reply to the network formation request from at least one or the one or more targets.

13. The method according to claim 12, the method further comprising: Establishing a communication link with at least one of the one or more targets based on receiving the reply to the network formation request.

14. The method according to claim 12, wherein the method further comprises: Receiving a first reply to the network formation request from a first target among the one or more targets through a first physical layer connection, and receiving a second reply to the network formation request from a second target among the one or more targets through a second physical layer connection.

15. The method according to claim 14, wherein the first physical layer connection and the second physical layer connection utilize different communication protocols.

16. A device for recording event data, the device comprising: at least one memory; and at least one processor, the at least one processor coupled to the at least one memory and configured to: generate a network formation request based on an event; broadcast the network formation request to one or more targets; form a network including at least one of the one or more targets; obtain event data associated with the event from at least one of the one or more targets; and append the event data associated with the event obtained from the one or more targets to a blockchain.

17. The device according to claim 16, wherein in order to generate the network formation request, the at least one processor is configured to generate an event ID, wherein the event ID includes at least one or more of an event code, an event location, or an event timestamp.

18. The device according to claim 16, wherein the at least one processor is configured to end the blockchain based on at least one or more of a time amount or a blockchain length.

19. The device according to claim 18, wherein in order to end the blockchain, the at least one processor is configured to broadcast an end event request.

20. The device according to claim 16, wherein the event data associated with the event includes hash event data corresponding to detailed event data collected from at least one of the one or more targets, wherein the hash event data can be used to verify the detailed event data.

21. The device according to claim 16, wherein the blockchain includes a plurality of blocks, each block including at least a block hash and a payload.

22. The device according to claim 21, wherein each block includes at least one block pointer.

23. The device according to claim 21, wherein the blocks in the plurality of blocks include hash event data corresponding to detailed event data, wherein the data size associated with the hash event data is smaller than the data size associated with the detailed event data.

24. The device according to claim 23, wherein the detailed event data is stored outside the blockchain.

25. The apparatus according to claim 16, wherein initiating the network formation request comprises: The event is detected by at least one or more of a roadside unit, a vehicle, or a mobile device.

26. The device according to claim 16, wherein the network includes a V2X network, and the event data associated with the event includes at least one or more of the following: a vehicle data log, wherein the vehicle data log includes data related to at least one or more of acceleration, braking, turning, or distance keeping; video data; audio data; RADAR data; or LIDAR data.

27. The device according to claim 16, wherein forming the network includes receiving a reply to the network formation request from at least one or the one or more targets.

28. The apparatus according to claim 27, wherein the at least one processor is configured to: establish a communication link with at least one of the one or more targets based on receiving the reply to the network formation request.

29. The apparatus according to claim 27, wherein the at least one processor is configured to: receive a first reply to the network formation request from a first target among the one or more targets through a first physical layer connection, and receive a second reply to the network formation request from a second target among the one or more targets through a second physical layer connection.

30. The apparatus according to claim 29, wherein the first physical layer connection and the second physical layer connection utilize different communication protocols.

Images