CN113498603A

CN113498603A - Determining trustworthiness of messages in smart urban telecommunication networks using blockchains

Info

Publication number: CN113498603A
Application number: CN201980093419.7A
Authority: CN
Inventors: 艾哈迈德·阿拉什·奥贝迪
Original assignee: T Mobile USA Inc
Current assignee: T Mobile USA Inc
Priority date: 2018-12-31
Filing date: 2019-12-23
Publication date: 2021-10-12
Also published as: EP3906657A1; EP3906657A4; CA3125177A1; WO2020142325A1

Abstract

Systems and methods are described herein for configuring vehicles and infrastructure (e.g., buildings, smart homes, transportation devices, utilities and related systems, emergency response systems, etc.) to include blockchain nodes, so that smart cities or areas of various devices may be supported by the blockchain network, with some or all of the devices and systems equipped with nodes that act as distributed nodes of the blockchain network.

Description

Determining trustworthiness of messages in smart urban telecommunication networks using blockchains

Background

Various types of networks, including wireless networks, cellular networks, and other types of telecommunications networks, provide communication services to people throughout the world. For example, in most parts of the world, users of mobile devices may access a network and communicate with other users or systems via voice calls, text messages, or data over the internet. These networks are ubiquitous, linking users to many different users and vast amounts of information and services. It can be said that telecommunications networks create a better world for people.

However, such networks include a variety of physical and virtual vulnerabilities that a small percentage of people may attempt and exploit to profit from fraud and other fraudulent activities. Accordingly, network providers will continue to use techniques that can prevent or deter nefarious individuals from attempting to exploit network vulnerabilities to improve telecommunications networks, components thereof, and/or devices and systems that exploit the networks.

Drawings

Embodiments of the present technology will be described and explained by using the drawings.

Fig. 1 is a block diagram illustrating a suitable network environment for devices and components representing nodes of a blockchain network.

Fig. 2A is a block diagram illustrating communication between two different devices, represented as nodes of a blockchain network.

Fig. 2B is a block diagram illustrating communication between a device and a network component, both of which are represented as nodes of a blockchain network.

Fig. 2C is a block diagram illustrating communication between network components represented as nodes of a blockchain network.

Fig. 3 is a block diagram illustrating a vehicle network communicating as nodes on a blockchain network.

Fig. 4 is a block diagram illustrating a network of vehicles and infrastructure communicating as nodes on a blockchain network.

FIG. 5 is a flow chart illustrating a method for a vehicle to perform an action based on messages received from other vehicles.

Fig. 6 is a flow chart illustrating a method of performing an action based on information received from an infrastructure system or device.

The drawings are not necessarily to scale. Similarly, some components or operations may be separated into different blocks or combined into a single block for the purpose of discussing some embodiments of the present technology. Also, while the technology is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. However, there is no intention to limit the technology to the specific embodiments described. On the contrary, the technology is intended to cover all modifications, equivalents, and alternatives falling within the scope of the technology as defined by the appended claims.

Detailed Description

SUMMARY

Systems and methods for providing blockchain functionality to telecommunications networks, components thereof, and devices and systems communicating over telecommunications networks are described herein. Systems and methods (collectively, "systems") may implement devices, systems, components, etc. using agents or other modules that transform or establish them into nodes (or sub-nodes) distributed across a network, such as nodes of a blockchain network.

For example, vehicles and infrastructure (e.g., buildings, smart homes, transportation devices, utilities and associated systems, emergency response systems, etc.) may be configured to include blockchain nodes such that a smart city or area may be supported by a blockchain network, any devices and systems equipped with nodes that act as distributed nodes of the blockchain network.

By utilizing aspects of a blockchain network, a smart city or region can self-regulate or self-manage operations within the network. Thus, the system and devices can utilize the blockchain to determine when communications between the devices are trustworthy (e.g., no sinks and communications from the devices are legitimate), among other benefits.

In some implementations, provisioning the vehicles with blockchain nodes may facilitate reliable and trustworthy communications between vehicles (e.g., V2V communications), and/or communications between vehicles and infrastructure systems to devices (e.g., V2X communications).

For example, the system receives a message from another vehicle in the vicinity of the vehicle at a block link point within the computing system of the vehicle, where the message from the other vehicle includes information associated with a route currently being traveled by the vehicle. The system then determines, via blockchain operations performed by the blockchain link points, whether another vehicle is verified on a blockchain associated with a telecommunications network that facilitates communication between the vehicle and the other vehicle. When the blockchain operation verifies another vehicle, the system performs an action associated with the vehicle based on information associated with the vehicle's current travel route.

Thus, vehicles, including autonomous vehicles (autonomous vehicles), may include systems within a connected regional network of vehicles, the network including blockchain nodes. The node determines whether a signal sent to the autonomous vehicle from one or more devices in the vicinity of the autonomous vehicle is a trustworthy signal based on information maintained by the blockchain for the telecommunications network. Then, when the block link point determines that the signal is trustworthy, the action module causes an action associated with the vehicle to be performed in response to the signal from the one or more devices.

Equipping infrastructure devices and systems with blockchain nodes can facilitate reliable and trustworthy communications between various entities associated with the infrastructure devices and systems (e.g., emergency response systems, security systems, etc.) and recipients of messaging and other communications (e.g., end users or devices).

For example, the system receives an alert from the infrastructure equipment at a block link point of the computing equipment, where the alert from the infrastructure equipment includes information identifying an abnormal condition at the infrastructure equipment. The system then determines, via blockchain operations performed by the blockchain link points, whether the infrastructure equipment is verified on a blockchain associated with a telecommunications network that facilitates communication between the computing equipment and the infrastructure equipment. When the infrastructure equipment is determined to be verified for blockchain operation, the system performs an action in response to an alarm from the infrastructure equipment.

Thus, a computing device may include a system for monitoring the operation of devices within a smart city. The system may include a block link point comprised by a device within a smart city that determines whether signals sent to the device from other devices within the smart city are trustworthy signals based on information maintained by the block link for a telecommunications network associated with the smart city. Further, the system may include an action module such that when the blockchain node determines that the signal is trustworthy, the action module performs some action in response to the signal from the other device.

Thus, the system may equip some or all devices and systems of a region or city with blockchain nodes to build, manage, and utilize blockchains or distributed ledgers for the region or city, among other benefits, in determining whether a communication (e.g., a message or data communication) is trustworthy and sent from a known and trustworthy device or system.

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present technology. It may be evident, however, that embodiments of the present technology may be practiced without some of these specific details.

Telecommunications network as an example of a blockchain network of nodes

As described herein, in some embodiments, a system manages devices, components, and systems of or associated with a telecommunications network as nodes on a blockchain network. Thus, the device operates as a node (or child node) that is distributed across a blockchain network.

Nodes on a blockchain network perform a variety of functions for the network. They process transactions and maintain a copy of the blockchain (e.g., a replicated database or ledger). Thus, the distributed nodes are combined into a blockchain network. For example, for cryptocurrency (e.g., bitcoin), the nodes check for new currency transactions according to a consensus agreement (consensus protocol), which is a unified protocol system among all nodes of the network when validating transactions processed by the nodes. Thus, the node itself, relying on a consensus agreement, decides whether to validate the transaction at the node.

There may be different types of nodes, such as full nodes, child nodes, and proxies. The full node maintains a complete copy of each tile (e.g., record) and transaction within the blockchain network and verifies the tile/transaction according to a consensus agreement. However, the child node and the agent can only verify their own transactions. In some cases, a group of child nodes or agents may act together as a node or a full node. Further, the nodes, children, and proxies may act as endpoint nodes (when communication between nodes in the network is terminated or terminated) or redistribution nodes (where communication is redistributed to other nodes of the network).

Telecommunications networks are well suited to manage communications between components (e.g., devices, cells, access points, registers, databases, gateways, etc.) by representing the components as nodes of a blockchain network. For example, any device associated with, in communication via, and/or within or providing a network may be a node and used to verify transactions, authenticate other devices, perform actions or operations, or otherwise communicate over the network based on blockchain transactions.

Fig. 1 is a block diagram of a suitable network environment 100 illustrating devices and components representing nodes of a blockchain network. As shown, the telecommunications network 110 may extend to virtually any area, location, facility (structure), or environment, serving devices and systems of various sizes-from mobile devices, to smart homes and other single facilities, to communities, cities, and other facilities or groups of devices.

The telecommunications network is provided via a network architecture 120, such as various components that provide communication services (e.g., voice calls, text and other messages, data communications, etc.) to mobile devices and other user equipment. As described herein, a network architecture may include access points or networks, gateways, core network components (e.g., operational components, packet control components, policy control functions, billing components, subscriber databases, etc.), and so forth.

Devices, systems, and geographic regions may access the telecommunications network 110 through a variety of different sites, access points, and/or networks. For example, a small cell site (e.g., a femtocell, picocell, or other small cell) 130 may provide access to the network 110 to a small or target area, such as a smart home hub (hub)132 and its various connected (internet of things, or IoT) devices 134, 136. The small cell site 130 can provide direct access to the smart home hub 132 and the devices 134, 136 (and any mobile devices) or the devices can access the network 110 via the smart home hub 132.

In addition to small cell site 130, devices, systems, and/or areas may access network 110 via a base station or other cell site, such as base station 140. For example, the

mobile devices

142, 144 may communicate over the network 110 by accessing the network 110 via the base station 140.

In addition, devices, systems, and/or other areas, such as a smart city and its various components and infrastructure, may access network 110 via a provisioned access network 150, such as access network 150 supported by access points 155 (e.g., wireless access points, hotspots, routers, etc.), or other cellular sites 160 (e.g., small cells or base stations positioned to serve a particular area or center).

For example, the smart city 170 may include facilities 172 (e.g., houses, buildings, schools, hospitals, etc.) connected to the network 110 via the access network 150. Vehicle 174 may also access network 110 via access network 150. In addition, various utilities 176 and their systems or devices (e.g., power grid components, water supply systems, natural gas or other fuel systems, wireless infrastructure systems, emergency response systems, etc.) may communicate over network 110. In addition, devices 178 (e.g., traffic lights and other devices, street lights, parking meters, etc.) access network 110 via access network 150.

Some or all of these systems and

devices

172, 174, 176, 178 may communicate with each other via the network 110. For example, the vehicle 174 may communicate with other vehicles 174, or with certain devices 178 (e.g., traffic lights), or with services provided by the utility 176 (e.g., emergency response services), or with the facility 172 (e.g., smart home devices) over the network 110. As another example, a utility (e.g., a power grid) may communicate with other utilities (e.g., emergency response systems), vehicles 174, and the like.

Thus, in some embodiments, the telecommunications network 110 (managed by the network architecture 120) provides communication services to a wide range of all different devices and systems capable of communication — from a single

mobile device

142, 144 to the devices, systems, and facilities of a large scale connected city 170. Further, although fig. 1 depicts an example of how these devices and systems access network 110, other configurations are possible. For example, the mobile device 142 may access the network 110 via the small cell site 130, and the IoT device 132 may access the network 110 via the base station 140, among other configurations.

As described herein, some or all of the devices or systems depicted in fig. 1 or other figures may act or be configured to function as nodes or sub-nodes of a blockchain network. A node or a child node may be implemented as a module, an agent, or another component of a device or system. An agent or module may be a functional module or engine implemented in a combination of software (e.g., executable instructions, or computer code) and hardware (e.g., at least one memory and a processor). Thus, as used herein, a module or engine is, in some examples, a processor-implemented module or set of codes and represents a computing device having a processor that is at least temporarily configured and/or programmed by executable instructions stored in a memory to perform one or more of the particular functions described herein.

As a node (or child node), a device or system is used to maintain a distributed ledger (e.g., blockchain) of transactions. Further, the devices or systems may cooperate to verify, certify, or authenticate data and/or transactions communicated between the nodes. Thus, devices or systems operating as nodes of a blockchain network operate to provide security, reliability, and/or redundancy between them and portions or segments of the telecommunications network 110.

A blockchain associated with a network and various devices or systems may be configured to track or store information specific to communication over the network. For example, a blockchain transaction may include information identifying a location of a user or device (e.g., GPS information, cell tower or base station information, access point information, etc.), a device or user identifier such as a Mobile Station International Subscriber Directory Number (MSISDN) or International Mobile Equipment Identity (IMEI) information, biometric information, and other biometric or physical user identifiers, and the like.

For example, a device may access a network and run an instance of an etherhouse virtual machine and utilize a variety of device or network specific information when authenticating onto the network via a variety of blockchain transactions. By tracking and maintaining this information, the blockchain can then authenticate the device via highly trusted information, knowing that the actual device (or the person behind the device) is valid and authorized to access the network.

To this end, devices or systems that are nodes may perform particular functions when communicating with other devices or systems, depending on their role within network 110 or how they are utilized. For example, a mobile device (e.g., mobile device 142) may act as an endpoint node of a blockchain network, while a gateway component of network architecture 120 may act as a redistribution node.

Pursuant to an example, a mobile device, while communicating with other devices, can compare to perform a blockchain transaction to compare credentials of other devices communicating with the mobile device, while a gateway component can maintain a complete ledger of the entire network of blocks or transactions and allow access to core network components when both the requesting device and the core network components are verified by the gateway component. Fig. 2A-2C provide examples of such functionality for different devices, components, or systems.

Fig. 2A is a block diagram illustrating communication 200 between two different devices, represented as nodes of a blockchain network. For example, device 210 may send a message to device 220 over network 110. The device may also send a certificate or other identifier of the device via node component 215 or a similar agent associated with device 210. Device 220, via its node component or proxy, may verify device 210 based on the transmitted certificate.

For example, device 220 may compare the certificate of device 210 to one or more previous transactions performed by device 210 over the network. When the certificate is associated with an authenticated or acceptable transaction (or prior verification), device 220 verifies device 210 with network 110 (enabling device 210 to utilize all or some of the services provided by network 210). After verification, device 220 may transmit a verification message back to device 210 (which may add the message to the blockchain via node 215). Thus, in some embodiments, one device may verify and/or authenticate another device to the network 110 or other devices or systems associated with the network 110 by utilizing a blockchain process.

Fig. 2B is a block diagram illustrating communication 230 between a device and a network component, both of which are represented as nodes of a blockchain network. For example, device 210 may send a message to network component 240 (e.g., a network component of architecture 120), such as when attempting to access network 110 via one or more access points. Device 210 communicates the information to network component 240 via its associated proxy 250, and network component 240 compares the information to the record of the blockchain via its associated blockchain link point 245, thereby authenticating device 210 to network 110.

Such a process may occur, for example, each time device 210 accesses network 110, or in response to a possible attempt to access network 110 without the permission or knowledge of various network components 240. Once authenticated, node 245 adds transactions to the blockchain on behalf of activities within network 110, and device 210 communicates over network 110 upon request. Thus, in some embodiments, network component 240 may perform an authentication process at each or some of the components for a device attempting to access a service provided by network 210.

Fig. 2C is a block diagram illustrating communications 260 between network components represented as nodes of a blockchain network. At times, one network component 270 may perform various blockchain processes to permit another network component (e.g., component 240) to perform its intended functions for the network 110.

For example, the network component 240 may send a message to the network component 270 via its proxy 245 as part of normal core network functions or processes. To avoid persisting (persisting) messages from the failed component, network component 270 may compare the messages to the blockchain via its node 275 and allow network component 240 to continue operating within network 110. Thus, in some embodiments, the network components themselves may act as nodes of the blockchain to maintain the integrity and reliability of the operation and processes of the telecommunications network 110.

Thus, in various embodiments, telecommunications network 110 utilizes the functionality of a distributed ledger to provide a means for various components, devices, or systems to act as an authentication, validation, or verification interface for network 110. The following section shows details of a particular embodiment employing such functionality.

Fig. 1 and the discussion herein provide a brief, general description of a suitable computing environment in which devices and network components that function as nodes on a blockchain network may be supported and implemented. Although not required, various components or aspects of the system are described in the general context of computer-executable instructions, such as routines executed by a general-purpose computer (e.g., a mobile device, a server computer, or a personal computer). The system may be used with other communications, data processing, or computer system configurations, including: internet appliances, hand-held devices (including tablet computers and/or Personal Digital Assistants (PDAs)), various cellular or mobile telephones, multiprocessor systems, microprocessor-based or programmable consumer electronics, set top boxes, network PCs, minicomputers, mainframe computers, and the like. Indeed, the terms "computer," "host," and "host computer," as well as "mobile device" and "handheld (handset)" are used interchangeably herein in general, and refer to any of the above devices and systems, as well as any data processor.

Aspects of the system may be embodied in a special purpose computing device or data processor that is specifically programmed, configured, or constructed to perform one or more of the computer-executable instructions explained in detail herein. Aspects of the system may also be practiced in distributed computing environments where tasks or modules are performed by remote processing devices that are linked through a communications network, such as a Local Area Network (LAN), Wide Area Network (WAN), or the internet. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Aspects of the system may be stored or distributed on computer-readable media (e.g., physical and/or tangible non-transitory computer-readable storage media), including magnetically or optically readable computer disks, hardwired or preprogrammed chips (e.g., EEPROM semiconductor chips), nanotechnology memory, or other data storage media. Indeed, computer-implemented instructions, data structures, screen displays, and other data under aspects of the system may be distributed over the internet or other networks (including wireless networks) over a propagated signal on a propagation medium (e.g., an electromagnetic wave, a sound wave, etc.) over a period of time, or they may be provided over any analog or digital network (packet-switched, circuit-switched, or other scheme). Portions of the system may reside on a server computer and corresponding portions may reside on a client computer such as a mobile or portable device, and thus, although certain hardware platforms are described herein, aspects of the system are equally applicable to nodes on a network. In alternative embodiments, the mobile device or portable device may represent the server portion, and the server may represent the client portion.

In some embodiments, a device may include a network communication component that enables the device to communicate with a remote server or other portable electronic device by transmitting and receiving wireless signals over a communication network using licensed, semi-licensed, or unlicensed spectrum. In some cases, a telecommunications network may include multiple networks, even multiple heterogeneous networks, such as one or more border networks, voice networks, broadband networks, service provider networks, Internet Service Provider (ISP) networks, and/or public switched network telephone networks (PSTNs), operatively interconnected via gateways to facilitate communications between the various networks. The communication networks may also include third party communication networks, such as a Global System for Mobile (GSM) mobile communication network, a code division/time division multiple access (CDMA/TDMA) mobile communication network, a third or fourth generation (3G/4G) mobile communication network (e.g., general packet radio service (GPRS/EGPRS)), enhanced data rates for GSM evolution (EDGE), Universal Mobile Telecommunications System (UMTS), or Long Term Evolution (LTE) network, a 5G mobile communication network, IEEE 802.11(WiFi), or other 3GPP or non-3 GPP communication networks.

Example of determining that network communication is trustworthy

As described herein, in some embodiments, the systems and methods configure devices and systems (such as devices and systems that are part of the smart city 170) to determine themselves that communications (e.g., messages, data, voice, etc.) originate or come from trusted sources, such as other devices and systems.

In some cases, the systems and devices that interact with each other may be vehicles, such as autonomous vehicles, electric vehicles, or any other vehicle that contains a Controller Area Network (CAN) or other computer system or network that manages sensors and controls some or all aspects of vehicle operation. Fig. 3 is a block diagram illustrating a vehicle network 300 communicating as nodes on a blockchain network.

Vehicles 174A-C may communicate through telecommunications network 110, which is provided by network architecture 120 as a wireless, LTE, IMS, or other type of network. Vehicles 174A-C may include computing devices or systems that facilitate connectivity between network 110 and vehicles 174A-C. Thus, in some cases, a vehicle as described herein is a connected vehicle (connected vehicle).

As an example, the networked vehicle may be connected to the network 110 via one or more network devices attached to or provided with the vehicle, such as T-

Sync Up Drive^TM) Such as via an OBD-II port of a vehicle dashboard, or other control of an networked vehicleA device area network (CAN) bus component or device. For example, the attached devices may collect information and/or diagnose various events, problems, or changing states of the vehicle and its components, monitor and track the operation of the vehicle, and the like. Thus, the device and/or the internal computing system establishes the networked vehicle as a device on the communication network 110.

Of course, other devices may provide similar information associated with networked vehicles, such as mobile devices associated with the driver of the vehicle (e.g., they may be subscribers of network 110), Subscriber Identity Modules (SIMs) integrated with the vehicle, such as eSIMs (or other dynamically reprogrammable modules), and/or other communication components that are part of the vehicle and/or in-vehicle devices and that are configured to communicate over communication network 110.

In some cases, vehicles 174A-C may include a variety of sensors to facilitate capturing information associated with the vehicle and its surroundings. Vehicles 174A-C may include ultrasonic sensors, radar sensors, imaging sensors, GPS or accelerometers, etc.

The vehicles may also include vehicle-to-vehicle communication (V2V) components that enable the vehicles to communicate with each other in real time, such as relaying information from one vehicle to another. For example, vehicle 174C may be further forward on the route of travel and relay information 174A back to vehicle 174C that identifies potential problems encountered along the route-traffic, environmental conditions, vehicle movement (e.g., lane changes), vehicle problems (e.g., notification of tire leaks), etc. Some example V2V applications include an Intersection Movement Assistance (IMA) application, a Left Turn Assistance (LTA) application, and the like.

In some cases, autonomous vehicles may be particularly reliant on unreliable or unreliable communications between vehicles, such as communications sent by a lost vehicle (or a lost system within a vehicle), and thus vulnerable.

Thus, as described herein, the system may equip or equip vehicles 174A-C with

nodes

310, 320, and 330, which perform blockchain operations to determine whether communications received from other vehicles are reliable and from trustworthy sources.

As shown, some or all of the vehicles 174A-C communicating over the network 110 may be configured or equipped to include blockchain nodes, such as nodes including blockchain agents configured to perform blockchain transactions, operations, or other processes associated with blockchains or ledgers, that track and maintain a history of all transactions performed by the vehicles 174A-C within the telecommunications network 110.

In some embodiments, the nodes are implemented as JavaScript modules (e.g., "node. js") or other similar modules (e.g., solid modules), and the ledger or blockchain is configured as a JavaScript array. Thus, each vehicle 174A-C may include a blockchain node. Vehicles with blockchain nodes can access the representative network 110, perform operations associated with the blockchain, and add transaction data (e.g., blocks) to a complete copy of the blockchain in the blockchain associated with activities and actions performed by the vehicles or other vehicles of the network 110.

In addition to vehicles 174A-C, Smart city 170 may include a variety of infrastructure entities. Fig. 4 is a block diagram illustrating a network 400 of vehicles and infrastructure communicating as nodes on a blockchain network.

Network 400 includes facility 172, utility 176, and devices 178 as described herein. For example, pole stations, traffic signals, and other smart road or smart city devices 178 (e.g., such as 5G micro base stations placed in buildings, on utility poles, etc.) may be connected to the network 110 and facilitate the exchange of information between the vehicles 174A-C and the network 110. Similarly, one or more networked devices may communicate with a vehicle when the vehicle is parked at a home, parking garage, or parking space. Thus, in some instances, a vehicle may encounter and exchange information with a variety of networked devices while traveling, and these devices provide access to the communication network 110.

Further, infrastructure entities may communicate with user devices 440, such as mobile devices, laptops, tablets, etc., over network 110, associated with users and configured to monitor, track, analyze, and/or provide information regarding the status of operations at the entities and/or other information associated with facilities 172, vehicles 174, utilities 176, devices 178, etc. of smart city 170.

For example, one or more devices 178, such as a utility meter (e.g., an Automatic Meter Reading (AMR) device), may send information indicative of the consumption of the utility, the operational status of the utility at the facility 172, and the like to the user device 440 via the network 110. The other devices 178 may transmit status information, alerts, or other signals, such as alerts indicating an emergency at a location or area, signals providing information to other devices 178, vehicles, etc., or other information or data.

For example, with respect to vehicles, the network 110 may facilitate vehicle-to-all (V2X) communications, such as communications between the vehicles 174A-C and pedestrians (e.g., at the user device 440), roads or traffic devices (e.g., traffic signals, such as smart signals, traffic lights, digital signs, lighting, parking timers, charging systems, and other smart devices or systems along a travel route), and so forth.

Further, infrastructure entities may include smart grid components (e.g., power stations, transformers, etc., network infrastructure components, light poles), retail environments, emergency response equipment, systems, or entities, cameras, smart home or building sensors (e.g., temperature sensors, gas or fire alarms, etc.), campus or regional grid systems, and the like.

As described herein, the system may equip or equip the infrastructure entities with

nodes

410, 420, and 430, and the user equipment with or equip node 445. The

nodes

410, 420, 430, 445 may perform block chain operations to determine whether communications between entities are trustworthy and not originating from a lost entity (e.g., poison pill entity) that may compromise the network 110 or infrastructure entities.

Nodes

410, 420, 430, 445 include blockchain agents configured to perform blockchain transactions, operations, or other processes associated with blockchains or ledgers that track and maintain a history 110 of some or all transactions performed within the telecommunications network within the smart city 170.

As described herein, in some embodiments, the nodes are implemented as JavaScript modules (e.g., "node. js") or other similar modules (e.g., solid modules) and the ledger or blockchain is configured as a JavaScript array. Thus, each vehicle 174A-C may include a blockchain node. A system or device having blockchain nodes can access a complete copy of the blockchain on behalf of the network 110, perform operations associated with the blockchain, and add transaction data (e.g., blocks) to the blockchain associated with activities and actions performed by the systems and devices of the network 110.

Thus, as shown in fig. 3 and/or 4, the system facilitates managing and verifying communications between vehicles and/or infrastructure over the communication network 110 by utilizing the vehicles 174A-C and the infrastructure systems and

devices

172, 174, 176, 178 as distributed nodes of a block chain.

FIG. 5 is a flow chart illustrating a method of performing an action for a vehicle based on messages received from other vehicles. Method 500 may be performed by block link points (e.g.,

nodes

310, 320, 330) of vehicles 174A-C and, thus, is described herein by reference only. It should be appreciated that method 500 may be performed on any suitable hardware or network component.

In operation 510, a block link point of a vehicle (e.g., a node included in a CAN of the vehicle) receives a message from another vehicle in the vicinity of the vehicle. For example, the node may receive a message from another vehicle that includes information associated with a route currently being traveled by the vehicle, or other vehicle-to-vehicle communication, as described herein.

Example messages, content, or information that may be communicated between vehicles includes information identifying current traffic conditions on a travel route, current weather conditions on a travel route, vehicle movement information, and so forth.

For example, when the vehicle is an autonomous vehicle, the information may include lane assistance information, intersection movement assistance information, left turn assistance information, or other information or data of other vehicles that identifies to the vehicle the movement of another vehicle along the travel route.

In operation 520, the block link point determines, via block chain operations performed by the block link point, whether the other vehicle is verified on a block chain associated with a telecommunications network that facilitates communication between the vehicle and another vehicle. For example, a node may perform operations associated with a blockchain for the network 110 to compare or otherwise identify blocks or transactions associated with another vehicle, which can provide information to verify that the other vehicle is legitimate, trustworthy, and/or not lost (e.g., operating as intended).

In some embodiments, the node may determine or list certain vehicles on a white list, a gray list, or a black list based on information contained on the blockchain for the vehicle. For example, a vehicle is blacklisted when blockchain operations indicate that the vehicle is stolen, graylisted when blockchain operations indicate that the vehicle is not authenticated (certified) for some period of time (via the blockchain or via one or more motor vehicle entities), and whitelisted when the vehicle is provided with a root certificate or other verifiable information.

Thus, in some cases, the blockchain operation may compare the content of a message received from another vehicle with the content of a previous message transmitted from another vehicle and contained by the blockchain, compare the identification information of another vehicle in the message content received from another vehicle with the identification information in the previous message content transmitted from the other vehicle and contained by the blockchain, determine that the other vehicle is verified when the information in the message matches information contained in a transaction of the blockchain associated with the other vehicle, and so on.

In operation 530, when it is determined that another vehicle is checked through the blockchain operation, the computing system of the vehicle performs an action associated with the vehicle (or causes the action to be performed) based on information associated with a route on which the vehicle is currently traveling. For example, the vehicle may change lanes, slow down or decelerate, accelerate or accelerate, adjust or modify a planned travel route, and the like.

In operation 540, the node retrieves route information from other sources (e.g., other devices connected to the vehicle via network 110) when it is determined that the other vehicle is not checked by the blockchain operation. For example, a node may request information from other sources (e.g., transportation devices, other vehicles, etc.) to confirm or supplement information received from another vehicle that was not verified.

In some cases, the node may suspend or prevent performance of an action associated with the vehicle based on information associated with a route currently being traveled by the vehicle until the information is confirmed by another source of the information.

In operation 550, the computing system of the vehicle performs (or is caused to be performed) an action associated with the vehicle based on information associated with the route the vehicle is currently traveling and retrieved from other sources. For example, similar to operation 530, the vehicle may change lanes, slow or decelerate, speed or accelerate, adjust or modify a planned travel route, and the like.

Once or during the performance of the action, in some cases, the node may perform a transaction to the blockchain, including hash values of previous blocks in the blockchain, a timestamp for the transaction, and transaction data identifying information for the action performed by the vehicle and identifying other vehicles sending the message.

Thus, in some embodiments, the system utilizes blockchain nodes to verify V2V communications, V2X communications, and the like. As described herein, any vehicle may operate a distributed node of a blockchain configured as a system within a computer area network of the vehicle (e.g., an autonomous vehicle) that includes a blockchain node that determines, based on information for a telecommunications network maintained by the blockchain, whether signals or information sent to the autonomous vehicle from one or more devices in the vicinity of the autonomous vehicle is trustworthy signals or information, and an action module that causes an action associated with the vehicle to be performed in response to the signals or information from the one or more devices when the blockchain node determines that the signals are trustworthy.

As described herein, in addition to communication between a vehicle and another vehicle, system, or device (V2V and V2X communication), the system described herein may configure infrastructure entities as distributed nodes of a blockchain associated with network 110 in order to verify that communications originating from the entities are trustworthy and free of a breach, among other benefits.

Fig. 6 is a flow diagram illustrating a method 600 of performing an action based on information received from an infrastructure system or device. The method 600 may be performed by a block chain node (e.g.,

nodes

410, 420, 430, 445) of an infrastructure entity and, thus, is described herein by reference only. It should be appreciated that method 600 may be performed on any suitable hardware or network component.

In operation 610, a blockchain node of a computing device receives a message alert from an infrastructure device, wherein a message from the infrastructure device includes information identifying a current condition at the infrastructure device. For example, the node 445 of the user device 440 may receive an alert from one or more of the facility 172, utility 176, or other device 178, where the alert identifies an abnormal condition at the entity.

The alarm or other message may represent, for example, an emergency at a location including infrastructure equipment, such as a power failure at an area providing power via a power grid, a triggering of a safety alarm, smoke alarm, etc. at a location or within a facility, and the like.

As one example, when the infrastructure device 178 is a utility meter associated with a utility, the information identifying an abnormal condition at the infrastructure device may include information representative of a fault of one or more components providing the utility (e.g., communicating such information to an automated data collection meter (AMR) device from the utility meter). As another example, the infrastructure device is an emergency alert device for a location, and the computing device is a mobile device configured to alert emergency responders to an emergency situation at the location.

In operation 620, the block chain node of the computing device determines, via block chain operations performed by the block chain node, whether the infrastructure equipment is verified on a block chain associated with a telecommunications network that facilitates communication between the computing device and the infrastructure equipment. For example, a node may perform operations associated with a blockchain for network 110 to compare or otherwise identify blocks or transactions associated with infrastructure equipment that can provide information to verify that the equipment is legitimate, trustworthy, and/or not compromised (e.g., operating as planned).

Thus, in some cases, the blockchain operation may compare the content of the received message with the content of a previous message transmitted from the device and contained by the blockchain. The operation then compares the identification information for the device in the message content received by the slave device with the identification information in the previous message content transmitted by the slave device and contained by the blockchain. The operation may then determine that the device is verified, etc., when the information in the message matches the information contained in the blockchain transaction associated with the device.

When it is determined by the blockchain operation that the infrastructure equipment is verified, the user equipment performs (or is caused to be performed) an action in operation 630 in response to the message from the infrastructure equipment. For example, the user device 445 may automatically respond to the message to mitigate abnormal conditions at the infrastructure equipment, alert (alert) the user (e.g., emergency responder) or send a notification of certain conditions or states at a location, and so forth.

Upon determining that the infrastructure device is not being checked by the blockchain operation core, the blockchain nexus of the user device performs an action to prevent or otherwise mitigate (mitigate) the infrastructure device from transmitting additional messages to other computing devices. For example, the node may send a message to other devices to ignore messages from devices determined to be lost. The node may also alert a user associated with the user device that the failed device is transmitting an error or illegal message to the device over network 110.

In some cases, a blockchain nexus of a computing device may perform a transaction on a blockchain that includes hash values of previous blocks in the blockchain, a timestamp for the transaction, and transaction data identifying an action performed in response to a message from an infrastructure device.

Thus, the system may configure the infrastructure entities as distributed nodes of a blockchain. Each of the facility 172, utility 176, or device 178 may include a system for monitoring the operation of devices within a smart city, including the block link points contained by the devices within the smart city. The system determines whether signals sent to a device from other devices within a smart city are trustworthy signals based on information maintained by a blockchain for a telecommunications network associated with the smart city. When the block link point determines that the signal is trustworthy, an action module of the system then causes the associated action to be performed in response to the signal from the other device.

Thus, in some embodiments, the system enables a smart city to monitor itself by utilizing vehicles and entities within the city (or other location) as distributed nodes of a blockchain. The city may then utilize any node in checking the validity or trustworthiness of the network communication and perform actions to mitigate the lost device or system, as appropriate, among other benefits.

Conclusion

Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise", "comprising", and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is, in the sense of "including, but not limited to". As used herein, the terms "connected," "coupled," or any variant thereof, mean any direct or indirect connection or coupling between two or more elements; the coupling or connection between the elements may be physical, logical, or a combination thereof. Further, as used herein, the terms "herein," "above," "below," and words of similar import refer to this application as a whole and not to any particular portions of this application. Where the context permits, words above using the singular or plural number in the detailed description may also include the plural or singular number respectively. With respect to a list of two or more items, the word "or" encompasses all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

As used herein, above a threshold means that the value of the item being compared is higher than the other specified values, the item being compared is among some specified number of items having the greatest value, or the item being compared has a value within a specified highest percentage value. As used herein, below a threshold means that the value of the compared item is below the specified other values, the compared item is in some specified number of items with the minimum value, or the compared item has a value within a specified bottom percentage value. As used herein, within a threshold means that the value of the compared item is between two specified other values, the compared item is between a specified number of items in the middle, or the compared item has a percentage range of values specified in the middle.

The above detailed description of examples of the present technology is not intended to be exhaustive or to limit the technology to the precise form disclosed above. Although specific examples of the technology are described above for illustrative purposes, various equivalent modifications are possible within the scope of the technology. For example, while processes or blocks are presented in a given order, alternative implementations may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or subcombinations. Each of these processes or blocks may be implemented in a number of different ways. Further, while processes or blocks are sometimes shown as being performed in series, these processes or blocks may instead be performed or implemented in parallel, or may be performed at different times. Moreover, any particular number mentioned herein is merely an example: alternative implementations may employ different values or ranges.

The teachings of the techniques provided herein may be applied to other systems, not necessarily the systems described above. The elements and acts of the various examples described above can be combined to provide further implementations of the technology. Some alternative implementations of the technology may include not only additional elements of those described above, but also fewer elements.

These and other changes can be made to the techniques described in detail above. While the above description describes certain examples of the technology, and describes the best mode involved, no matter how detailed the above appears in text, the technology can be practiced in many ways. The details of the system may vary widely in its specific implementation, but are still covered by the techniques disclosed herein. As noted above, particular terminology used when describing certain features or aspects of the technology should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the technology with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the technology to the specific examples disclosed in the specification, unless the above detailed description section explicitly defines such terms. Accordingly, the actual scope of the technology encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the technology under the claims.

Certain aspects of the technology are presented below in certain claim forms to reduce the number of claims, but applicants contemplate aspects of the technology in any number of claim forms. For example, while only one aspect of the technology is recited as a computer-readable media claim, other aspects may likewise be embodied as a computer-readable media claim, or in other forms, such as in means-plus-function claims. Any claims applicable to 35 u.s.c. § 112(f) will begin with the word "means for", but the use of the word "for" in any other context is not intended to refer to 35 u.s.c. § 112 (f). Accordingly, the applicants reserve the right to pursue such further claims after the application is filed, in order to pursue such further claim forms in the application or a continuing application.

Claims

1. A non-transitory computer-readable medium whose contents, when completed by a computing system of a vehicle, cause the computing system to perform a method, the method comprising:

receiving, at a block link point within the computing system of the vehicle, a message from another vehicle in the vicinity of the vehicle,

wherein the message from the other vehicle includes information associated with a route currently being traveled by the vehicle;

determining, via a blockchain operation performed by the blockchain node, whether the other vehicle is verified on a blockchain associated with a telecommunications network that facilitates communication between the vehicle and the other vehicle; and

when the blockchain operation determines that the other vehicle is verified, performing an action associated with the vehicle based on the information associated with the route currently being traveled by the vehicle.

2. The non-transitory computer-readable medium of claim 1, further comprising:

when the blockchain operation determines that the other vehicle is not verified:

retrieving route information from other sources; and

performing the action associated with the vehicle based on information associated with the route currently being traveled by the vehicle and retrieved from the other sources.

3. The non-transitory computer-readable medium of claim 1, further comprising:

when the blockchain operation determines that the other vehicle is not a trustworthy source of information, suspending performance of an action associated with the vehicle based on information associated with the route the vehicle is currently traveling on until the information is confirmed by an additional source of information.

4. The non-transitory computer-readable medium of claim 1, wherein the blockchain node within the computing system of the vehicle includes a Javascript script that acts as a blockchain proxy for the computing system configured to operate as a distributed node for a blockchain associated with the telecommunications network.

5. The non-transitory computer-readable medium of claim 1, further comprising:

performing, by the blockchain node within the computing system of the vehicle, a transaction to the blockchain that includes a hash value of a previous blockchain in the blockchain, a timestamp for the transaction, and transaction data identifying the action performed by the vehicle and information identifying the other vehicle that sent the message.

6. The non-transitory computer-readable medium of claim 1, wherein determining, via blockchain operations performed by the blockchain node, whether the other vehicle is verified on a blockchain comprises comparing content of the message received from the other vehicle to a previous message transmitted from the other vehicle and contained by the blockchain.

7. The non-transitory computer-readable medium of claim 1, wherein determining, via a blockchain operation performed by the blockchain node, whether the other vehicle is verified on a blockchain comprises comparing identification information of the other vehicle in the content of the message received from the other vehicle with identification information in the content of a previous message transmitted from the vehicle and contained by the blockchain.

8. The non-transitory computer-readable medium of claim 1, wherein determining whether the other vehicle is verified on a blockchain via blockchain operations performed by the blockchain node comprises determining that the other vehicle is verified when information within the message matches information contained in the blockchain transaction associated with the other vehicle.

9. The non-transitory computer-readable medium of claim 1, wherein the information associated with a route currently being traveled by the vehicle includes information identifying current traffic conditions along the route currently being traveled by the vehicle.

10. The non-transitory computer-readable medium of claim 1, wherein the vehicle and the other vehicle are autonomous vehicles, and wherein the information associated with a route currently being traveled by the vehicle includes lane assistance information.

11. The non-transitory computer-readable medium of claim 1, wherein the vehicle and the other vehicle are autonomous vehicles, and wherein the information associated with a route currently being traveled by the vehicle includes intersection movement assistance information.

12. The non-transitory computer-readable medium of claim 1, wherein the vehicle and the other vehicle are autonomous vehicles, and wherein the information associated with a route currently being traveled by the vehicle includes left turn assist information.

13. The non-transitory computer-readable medium of claim 1, wherein performing the action associated with the vehicle based on the information associated with the route the vehicle is currently traveling comprises decelerating the vehicle.

14. The non-transitory computer-readable medium of claim 1, wherein performing the action associated with the vehicle based on the information associated with the route currently being traveled by the vehicle comprises accelerating the vehicle.

15. The non-transitory computer-readable medium of claim 1, wherein performing the action associated with the vehicle based on the information associated with the route the vehicle is currently traveling comprises lane changing the vehicle.

16. The non-transitory computer-readable medium of claim 1, wherein performing the action associated with the vehicle based on the information associated with the route the vehicle is currently traveling comprises modifying a GPS planned travel route of the vehicle.

17. A method performed by a telecommunications network, the method comprising:

receiving, at a block link point within a computing system of a vehicle, a message from a device in proximity to the vehicle,

determining, via a blockchain operation performed by the blockchain node, whether the device is verified on a blockchain associated with the telecommunications network,

wherein the telecommunications network facilitates communication between the vehicle and the device; and

performing an action associated with the vehicle based on the information received from the device when the device is determined by the blockchain operation to be verified.

18. The method of claim 17, further comprising:

when it is determined that the device is not checked by the blockchain operation core:

retrieving information from other devices in the vicinity of the vehicle; and

performing the action associated with the vehicle based on the information retrieved from the other sources.

19. The method of claim 17, wherein the device is a device operative to control travel of a vehicle in the vicinity of the vehicle.

20. A system within a connected area network of autonomous vehicles, the system comprising:

a blockchain node that determines whether signals transmitted to the autonomous vehicle from one or more devices in the vicinity of the autonomous vehicle are trustworthy signals based on information maintained by the blockchain for the telecommunications network; and

an action module that causes an action associated with the vehicle to be performed in response to the signal from the one or more devices when the blockchain node determines that the signal is trustworthy.

21. A non-transitory computer-readable medium whose contents, when completed by a computing system, cause the computing system to perform a method, the method comprising:

receiving an alert from an infrastructure device within an infrastructure device smart city at a block link point of a computing device,

wherein the infrastructure device is a device that monitors a condition of a facility, location, or utility within the infrastructure device smart city;

wherein the alert from the infrastructure equipment comprises information identifying an abnormal condition at the infrastructure equipment;

determining, via a blockchain operation performed by the blockchain node, whether the infrastructure device is verified on a blockchain associated with a telecommunications network that facilitates communication between the computing device and the infrastructure device within the smart city; and

performing an action in response to the alert from the infrastructure equipment when the blockchain operation determines that the infrastructure equipment is verified.

22. The non-transitory computer readable medium of claim 21, wherein the infrastructure device transmits an alert associated with a facility, location, or utility emergency within the smart city, the method further comprising:

when the infrastructure device is determined not to be operated by the blockchain operating core:

performing an action to prevent the infrastructure device from transmitting further alerts associated with the facility, location, or emergency at the utility within the smart city to other computing devices.

23. The non-transitory computer-readable medium of claim 21, wherein the blockchain node of the computing device comprises a Javascript script that acts as a blockchain proxy for the computing device and is configured to operate as a distributed node of the blockchain associated with the telecommunications network.

24. The non-transitory computer-readable medium of claim 21, further comprising:

performing, by the blockchain node of the computing device, a transaction to the blockchain that includes a hash value of a previous tile in the blockchain, a timestamp for the transaction, and transaction data identifying the action performed in response to the alert from the infrastructure device.

25. The non-transitory computer-readable medium of claim 21, wherein determining whether the infrastructure equipment is verified via blockchain operations performed by the blockchain nodes comprises comparing content of the alert received from the infrastructure equipment to content of a previous alert transmitted from the infrastructure equipment.

26. The non-transitory computer-readable medium of claim 21, wherein determining whether the infrastructure equipment is verified via blockchain operations performed by the blockchain node comprises comparing credential information within the alert received from the infrastructure equipment to credential information of a previous alert transmitted from the infrastructure equipment.

27. The non-transitory computer-readable medium of claim 21, wherein the information identifying an abnormal condition at the infrastructure equipment comprises information representing an emergency at a location including the infrastructure equipment.

28. The non-transitory computer readable medium of claim 21, wherein the infrastructure equipment is part of a power grid that provides power to an area, and wherein the information identifying an abnormal condition at the infrastructure equipment comprises information representing a power failure at the area providing power via the power grid.

29. The non-transitory computer-readable medium of claim 21, wherein the infrastructure equipment is a utility meter associated with a utility, and wherein the information identifying an abnormal condition at the infrastructure equipment comprises information representative of a failure of one or more components providing the utility.

30. The non-transitory computer-readable medium of claim 21, wherein performing an action in response to the alarm from the infrastructure equipment comprises automatically responding to the alarm to mitigate the abnormal condition at the infrastructure equipment.

31. The non-transitory computer-readable medium of claim 21, wherein performing an action in response to the alert from the infrastructure equipment comprises sending a notification to one or more users identifying the abnormal condition at the infrastructure equipment.

32. A method performed by a telecommunications network, the method comprising:

receiving messages from infrastructure equipment at block link points of a computing device;

wherein the message identifies a current condition at the infrastructure equipment;

determining, via a blockchain operation performed by the blockchain node, whether the infrastructure device is verified on a blockchain associated with a telecommunications network that facilitates communication between the computing device and the infrastructure device; and

when the blockchain operation determines that the infrastructure equipment is verified, performing an action in response to the current condition at the infrastructure equipment.

33. The method of claim 32, further comprising:

performing an action to prevent the infrastructure device from transmitting further messages to other computing devices.

34. The method of claim 32, wherein the blockchain node of the computing device includes a Javascript script that acts as a blockchain proxy for the computing device and is configured to operate as a distributed node of the blockchain associated with the telecommunications network.

35. The method of claim 32, further comprising:

performing, by the blockchain node of the computing device, a transaction to the blockchain that includes a hash value of a previous tile in the blockchain, a timestamp for the transaction, and transaction data identifying the action performed in response to the message from the infrastructure device.

36. The method of claim 32, wherein determining whether the infrastructure equipment is verified via blockchain operations performed by the blockchain nodes comprises comparing content of the message received from the infrastructure equipment to content of a previous message transmitted from the infrastructure equipment.

37. The method of claim 32, wherein determining whether the infrastructure equipment is verified via a blockchain operation performed by the blockchain node comprises comparing credential information within the message received from the infrastructure equipment to credential information maintained by the blockchain for the infrastructure equipment.

38. The method of claim 32, wherein the infrastructure equipment is a utility meter that monitors usage of a utility at a location, and wherein the computing device is an Automatic Meter Reading (AMR) device that automatically collects data from the utility meter.

39. The method of claim 32, wherein the infrastructure equipment is emergency alert equipment for a location, and wherein the computing device is a mobile device configured to alert emergency responders to an emergency at the location.

40. A system for monitoring device operation within a smart city, the system comprising:

determining, by a block link point comprised by a device within the smart city, whether signals sent to the device from other devices within the smart city are trustworthy signals based on information maintained by the block link for a telecommunications network associated with the smart city; and

an action module that causes an associated action to be performed in response to the signal from the other device when the blockchain node determines that the signal is trustworthy.