WO2019161555A1

WO2019161555A1 - Methods and peer node in an emergency event broadcasting system

Info

Publication number: WO2019161555A1
Application number: PCT/CN2018/077155
Authority: WO
Inventors: Zhancang WANG; Bo ZHONG
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2018-02-24
Filing date: 2018-02-24
Publication date: 2019-08-29

Abstract

According to the present disclosure, there is provided an emergency warning broadcasting system operatively connected with a blockchain decentralized network, wherein the blockchain decentralized network is used for facilitating rapid emergency identification and emergency warning broadcasting. Also, methods and peer nodes used in an emergency warning broadcasting system are provided. With the present disclosure, rapid emergency identification and emergency warning broadcasting can be achieved to avoid casualties and property damage.

Description

METHODS AND PEER NODE IN AN EMERGENCY EVENT BROADCASTING SYSTEM

TECHNICAL FIELD

The present disclosure generally relates to the technical field of wireless communications, and particularly to methods and peer nodes used in an emergency event broadcasting system, in particularly, a decentralized emergency event broadcasting system.

BACKGROUND

In traditional techniques, persons in emergencies can request help, regardless of a particular emergency number or a direct local access list. With the callings from mobile communication devices (such as User Equipment (UE) and the like) , emergency dispatch stations receive a large number of calls from those who have haven devices to improve their abilities and speeds to respond.

Generally, a centralized emergency event broadcasting system has been deployed, so that when an emergency event occurs or is about to occur, such as earthquake, fire, flood, landslide and so on, the centralized emergency event system may decide (typically after administrated by a responsible person or officer) to broadcast messages (such as Short Message Service (SMS) and the like) to inform those targets persons around and/or to be influenced by this emergency event.

However, such a centralized emergency event broadcasting system has the following several problems at least.

Firstly, the involvement of higher cost and professional/UE makes it be difficult to deploy into massive scale for practical application scenarios.

Secondly, it may require patrol and manual measurement when devices are massively deployed to cover large area. It is not automatic and may need to involve huge resources to perform the process.

Finally, response time is slow due to using centralized management. This may not meet the fast response requirements when an emergency event happens.

Also, another weak point of centralized emergency broadcasting is once the centralized node is destroyed by some reasons (e.g. human factors, accidents such as earthquake) , the public emergency warning will not work at all.

SUMMARY

According to a first aspect of the present disclosure, there is provided a method used in an emergency warning broadcasting system operatively connected with a blockchain decentralized network, wherein the blockchain decentralized network is used for facilitating rapid emergency identification and emergency warning broadcasting.

In one embodiment, a smart contract is predefined on a plurality of peer nodes constituting the blockchain decentralized network, and the method comprises steps of: receiving a transaction/warning message record associated with the smart contract, wherein the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes respectively; accessing a decentralized ledger stored in the plurality of peer nodes, wherein the decentralized ledger is updated based communications from the blockchain decentralized network; and using smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validate the transaction/warning message record through a predefined consensus agreement.

In one embodiment, the plurality of peer nodes comprise Internet of Things (IoT) sensors and/or User Equipments (UEs) , and/or the IoT sensors automatically detects the one or more emergency events, whereas the UEs automatically or manually reports the one or more emergency events.

In one embodiment, the method further comprises a step of: in response to determining that the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record, granting rewards to a user of the UE that reported the emergency event or giving up rewards to an IoT sensor that reported the emergency event.

In one embodiment, the method further comprises a step of: depositing the rewards to a digital wallet owned by the user of the UE.

In one embodiment, the method further comprises steps of: updating the decentralized ledger with information indicating depositing of the rewards into the digital wallet owned by the user of UE; and providing access to the decentralized ledger to the blockchain decentralized network.

In one embodiment, the rewards are received from an entity system.

In one embodiment, the transaction/warning message record is communicated to an originating node for both validation of the transaction/warning message record and validation of the transaction/warning message record to the blockchain decentralized network.

In one embodiment, the method further comprises steps of: in response to determining that the indicated one or more emergency events do not meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting, communicating, to the peer node that reported the emergency event, that the indicated one or more emergency events do not meet the condition and information indicating false reports necessary to meet the condition; receiving another transaction/warning message record associated with the smart contract, wherein this new transaction/warning message record comprises input data indicating one or more emergency events detected by the peer node; re-accessing the decentralized ledger; and using the smart contract logic associated with the smart contract to determine that the one or more emergency reports meet the condition of the smart contract and to thereby validate the transaction/warning message record.

In one embodiment, the predefined consensus agreement is at least one selected from Practical Byzantine Agreement, gossip protocols, and/or Conflict-free Replicated Data Type (CRDT) protocols.

In one embodiment, the one or more emergency events are detected based on one or more environmental parameters which comprise at least one of temperature, humidity, illumination, smoke, flame, sound, vibration, atmospheric pollution, gas, and/or motion.

In one embodiment, a block of the decentralized ledger comprises at least one of the following items:

· a unique identification of the peer node,

· a timestamp,

· a location of the peer node,

· one or more emergency events,

· one or more environmental parameters,

· a public key of a previous block, and/or

· a public key of the current block.

In one embodiment, the one or more emergency events comprise at least one of an earthquake, a fire, a flood, a landslide.

According to a second aspect of the present disclosure, there is provided an emergency warning broadcasting system operatively connected with a blockchain decentralized network, wherein the blockchain decentralized network is used for facilitating rapid emergency identification and emergency warning broadcasting.

In one embodiment, the blockchain decentralized network consists of a plurality of peer nodes having a smart contract predefined thereon, wherein each peer node comprises one or more sensors, a memory device, a communication device and a processing device operatively coupled to the sensors, the memory device and the communication device, and the processing device is configured to: receive a transaction/warning message record associated with the smart contract, wherein the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes respectively; access a decentralized ledger stored in the memory device, wherein the decentralized ledger is updated based communications from the blockchain decentralized network; and use smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record through a predefined consensus agreement.

In one embodiment, the processing device is further configured to: in response to determining that the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record, initiate rewarding a user of the UE that reported the emergency event with rewards corresponding to the condition or give up rewards to an IoT sensor that reported the emergency event.

In one embodiment, the processing device is further configured to: deposit the rewards to a digital wallet owned by the user of the UE.

In one embodiment, the processing device is further configured to: update the decentralized ledger with information indicating depositing of the rewards into the digital wallet owned by the user of UE; and provide access to the decentralized ledger to the blockchain decentralized network.

In one embodiment, the rewards are received from an entity system.

In one embodiment, the processing device is further configured to: communicate the transaction/warning message record to an originating node for both validation of the transaction/warning message record and validation of the transaction/warning message record to the blockchain decentralized network.

In one embodiment, the processing device is further configured to: in response to determining that the indicated one or more emergency events do not meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting, communicate, to the peer node that reported the emergency event, that the indicated one or more emergency events do not meet the condition and information indicating false reports necessary to meet the condition; receive another transaction/warning message record associated with the smart contract, wherein this new transaction/warning message record comprises input data indicating one or more emergency events detected by the peer node; re-access the decentralized ledger; and use the smart contract logic associated with the smart contract to determine that the one or more emergency reports meet the condition of the smart contract and to thereby validate the transaction/warning message record.

· a unique identification of the peer node,

· a timestamp,

· a location of the peer node,

· one or more emergency events,

· one or more environmental parameters,

· a public key of a previous block, and/or

· a public key of the current block.

According to a third aspect of the present disclosure, there is provided a peer node comprising: one or more sensors; a memory device; a communication device; and a processing device operatively coupled to the sensors, the memory device and the communication device, wherein the processing device is configured to: receive a transaction/warning message record associated with a smart contract predefined on a blockchain decentralized network consisting of a plurality of peer nodes, wherein the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes respectively; access a decentralized ledger stored in the memory device, wherein the decentralized ledger is updated based communications from the blockchain decentralized network; and use smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record through a predefined consensus agreement.

According to a fourth aspect of the present disclosure, there is provided a peer node comprising: a receiving unit configured to receive a transaction/warning message record associated with a smart contract predefined on a blockchain decentralized network consisting of a plurality of peer nodes, wherein the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes respectively; an accessing unit configured to access a decentralized ledger stored in the peer node, wherein the decentralized ledger is updated based communications from the blockchain decentralized network; and a validating unit configured to use smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record through a predefined consensus agreement.

According to a fifth aspect of the present disclosure, there is provided a peer node comprising: one or more sensors; a memory device; a communication device; and a processing device operatively coupled to the sensors, the memory device and the communication device, wherein the memory device having stored thereon a computer program which, when executed on the processing device, causes the processing device to carry out the method according to the first aspect of the present disclosure.

According to a sixth aspect of the present disclosure, there is provided a computer-readable storage medium, having stored thereon a computer program which, when executed on at least one processor, causes the at least one processor to carry out the method according to the first aspect of the present disclosure.

With the present disclosure, rapid emergency identification and emergency warning broadcasting can be achieved to avoid casualties and property damage.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features, and advantages of the present disclosure will become apparent from the following descriptions on embodiments of the present disclosure with reference to the drawings, in which:

Fig. 1 shows a block diagram of an emergency warning broadcasting system 100 according to at least one of the embodiment of the present disclosure, in which the smart contract of emergency waning is deployed and executed on peer nodes such as massive IoT sensors and UEs;

Fig. 2 shows an exemplary Practical Byzantine Agreement used in present disclosure for fault/fraud prevention;

Fig. 3 shows hierarchy layers of some embodiments of the present disclosure for decentralized emergency event warning broadcasting;

Fig. 4 shows a typical technical implementation according to some embodiments of the present disclosure with signal flows;

Fig. 5 shows a configuration of an environmental data measurement platform on a local sensor such as a massive IoT sensor and a UE;

Fig. 6 is a flow chart of a decentralized emergency event warning broadcasting process according to some embodiments of the present disclosure;

Fig. 7 shows an embodiment of present disclosure applicable in a mountain slide warning broadcasting scenario;

Fig. 8 shows a flow chart 800 of a method used in an emergency warning broadcasting system according to an embodiment of the present disclosure;

Fig. 9 shows a peer node 900 used in an emergency warning broadcasting system according to at least some embodiments of the present disclosure;

Fig. 10 shows a peer node 1000 used in an emergency warning broadcasting system according to at least some other embodiments of the present disclosure; and

Fig. 11 schematically shows an embodiment of a peer node 1100 which may be used as IoT sensors and/or UEs.

In the drawings, similar or same steps and/or elements are designated with similar or same referential numbers. It is to be noted that not all the steps and/or elements shown in the drawings are necessary for some embodiments of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

In the discussion that follows, specific details of particular embodiments of the present techniques are set forth for purposes of explanation and not limitation. It will be appreciated by those skilled in the art that other embodiments may be employed apart from these specific details. Furthermore, in some instances detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail.

References in the specification to “one embodiment, ” “an embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed terms.

Those skilled in the art will appreciate that the functions described may be implemented in one or in several nodes. Some or all of the functions described may be implemented using hardware circuitry, such as analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc. Likewise, some or all of the functions may be implemented using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Where nodes that communicate using the air interface are described, it will be appreciated that those nodes also have suitable radio communications circuitry. Moreover, the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, including non-transitory embodiments such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

Hardware implementations of the presently disclosed techniques may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit (s) (ASIC) and/or field programmable gate array (s) (FPGA (s) ) , and (where appropriate) state machines capable of performing such functions.

In terms of computer implementation, a computer is generally understood to comprise one or more processors or one or more controllers, and the terms computer, processor, and controller may be employed interchangeably. When provided by a computer, processor, or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, the term “processor” or “controller” also refers to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.

Since various wireless systems may benefit from exploiting the ideas covered within this disclosure as will be appreciated by those skilled in the art, terms like “base station” , “user equipment” , “access point” and “network node” as used herein should be understood in a broad sense. Specifically, the base station should be understood to encompass a legacy base station in a 2 ^nd Generation (2G) network, a NodeB in a 3 ^rd Generation (3G) network, an evolved NodeB (eNode B) in a 4 ^th Generation (4G) , a gNB in a 5 ^th Generation (5G) or NR network or future evolved network (e.g., Long-Term Evolution (LTE) network, LTE-Advanced (LTE-A) network etc. ) , and the like. The user equipment should be understood to encompass a mobile telephone, a smartphone, a wireless-enabled tablet or personal computer, a wireless machine-to-machine unit, and the like.

The comprehensive Internet of Things (IoT) sensors and a method of using massive IoT sensors to capture various information about the installer are proposed via low-cost device and inspect an emergency site installation in real time through the information collected to process a warning message that will be generated when an emergency occurs.

Recently, an investigation is done for verifying and showing the technology feasibility to inspect and provide warning when landslide is about to happen, using massive IoT and LTE networks. Our investigation on this application domain with Narrow-Band (NB) IoT technology, compared to traditional way of emergency broadcasting, is shown below.

In present disclosure, various sensors required by the application scenarios can be combined to the massive IoT sensors and data of the combined sensors is provided to the emergency event warning blockchain system which can be used for Internet of things (IoT) application services of various fields.

The present disclosure develops a decentralized form of emergency event warning broadcasting mechanism (based on blockchain and smart contract) that is aimed at transforming how we deal with emergency events and warning broadcasting to avoid casualties and property damage. Although the birth of the blockchain technology has paved way for cryptocurrency, we see the chance to improve it for emergency warning in real world events which may leads us towards the future of massive IoT and wireless communication applications.

Figure 1 shows a block diagram of an emergency warning broadcasting system 100 according to at least one of the embodiment of the present disclosure, in which the smart contract of emergency waning is deployed and executed on peer nodes such as massive IoT sensors and UEs.

As shown in Figure 1, the emergency warning broadcasting system 100 according to at least one of the embodiment of the present disclosure includes a blockchain or distributed ledger system with smart contract applications 130, massive IoT sensors 112, user equipment (UE) 114, backend system 140, web API 150, base station broadcasting nodes 120 for connectivity and interface to other blockchain systems 160 or complex systems. Here, the blockchain is a form of public/private ledger that requires no reconciliation of interactions among massive IoT sensors 112, UEs 114 or both, resulting in a seamless digital emergency warning powered by a node-based exchange of emergency event data such as Mountain Slide and Earthquake. The disclosure intends to usher change into the landscape of smart contracts into emergency event warning broadcasting in wireless communications. Therefore, the disclosure is capable to make seamless connections between smart contractual agreements and massive IoT networks as well as web-based APIs.

In present disclosure, smart contracts among massive IoT sensors 112, UEs 114, web API 150 and all are simple logical instructions for easy technical implementation. These instructions are based on logical operators such as “if” , “and” , and “then” , among others, and presents the overview of the emergency event information in a simplified format. This front-end solution to smart contracts makes this disclosure a seamless way to connect critical resources, such as cellular networks, web APIs 150, and backend systems 140, to the digital ledger that is the blockchain system 130. The smart contract of emergency warning is deployed and executed on peer nodes such as massive IoT sensors 112 and UEs 114. However, in prior arts, it would take more steps to solve connectivity issues between external resources and the centralized decision making, wasting time and effort along the process which is risky to emergency event warning broadcasting. In emergency events, fast response is essential to reduce loss and prevent more casualties, e.g. mountain slide or earthquake. Although another weak point of centralized emergency broadcasting is once the centralized node is destroyed by some reason e.g. human factors, accidents such as earthquake, the public emergency warning will not work at all. Therefore, with present disclosure, all these weak points can be compensated.

As smart contracts are logic-based, information interactions only occur when certain conditions that are specified in the agreement are met, for example, when an emergency event is detected from massive IoT sensors 112 or reported from a user of UE 114 when he/she observes the emergence event happen at the first time. In this disclosure, to manage the fault reporting among massive IoT sensors 112 and/or UEs 114, a fault tolerance is introduced to guarantee that the emergency event warning is true (i.e., the consensus network 110) . This kind of coordination is decentralized and does not require trusted parties (not as in prior arts) . The secure operation of present disclosure is achieved through protocols that coordinate and verify operations carried out by either massive IoT sensors 112 or UEs 114. It can employ different strategies for coordination, including Practical Byzantine Agreement (as shown in Figure 1 as Practical Byzantine fault tolerance (PBFT) among the massive IoT sensors 112 and/or UEs 114) , gossip protocols, or Conflict-free Replicated Data Type (CRDT) protocols, depending on the requirements of the application scenarios.

Figure 2 shows an exemplary Practical Byzantine Agreement used in present disclosure for fault/fraud prevention.

For example, we can define management faults to be Practical Byzantine faults caused by massive IoT sensors 112 or UEs 114 in the fault/fraud management protocol. The present disclosure relies on the fault tolerance of its underlining fault/fraud management protocol. Violations on the faults tolerance assumptions for management faults can compromise confidence level and safety of the emergency warning broadcasting system. With an emergency warning scheme where the fault/fraud protocol requires Practical Byzantine Agreement to audit information providers (massive IoT sensors 112 and UEs 114) as an example, in such protocol, the consensus network 110 receives proofs of confidence from information providers and runs Practical Byzantine Agreement to agree on the validity of these proofs. If the Practical Byzantine Agreement tolerates up to f faults out of n total nodes, then the disclosure can tolerate f < n/2 faulty nodes, as shown in Figure 2. On violations of these assumptions, audits can be compromised.

As shown in Figure 2, Practical Byzantine Agreement can maintain a consistent ledger node (massive IoT sensor 112 or UE 114) so that the confidence level of emergency warning could be very high in present disclosure and unreliable human factors can be gotten rid of during the process. In Figure 2, it keeps all peers up-to-date and fixes any peer nodes in error (for example, peer node with “456” in white block in (a) of Figure 2, it is fixed into “123” consistent with other two nodes on left side in (b) of Figure 2) . On the other hand, for the fault/fraud ledger nodes (for example, peer node “789” in black block in (a) and (b) of Figure 2) , the present disclosure will quarantine all the fault/fraud nodes and prevent them to further provide emergency warning information. This allows for more secure emergency warning use cases while staying completely free from the associated risks of violated rules on either side of the information reporting or interactions.

Referring back to Figure 1, link chain (s) in Figure 1 of present disclosure acts as a secure blockchain middleware that facilitates safe and easy connectivity between any of existing APIs 150, widely-used massive IoT sensor networks 112 and UEs 114 in cellular networks that uses incentive tokens to encourage UE users to provide true, accurate emergency event information in time, and other public or private blockchain systems 160. With the link chain connectivity, emergency warning smart contract can offer anyone the secure way towards decentralized blockchain infrastructure for logical trust-based agreements to build upon confidence and trust within the digital emergency event warning broadcasting network.

Therefore, some embodiments of present disclosure can be summarized as,

1. Emergency event warning system may comprise massive IoT sensors 112 and UEs 114 which measure various environmental information (at installation places) in real time and transmit the environmental information to a wireless communication network. UEs 114 which can either report/measures various environmental information or receive emergency event warning broadcasting from at least one blockchain system through the wireless communication network in real time. The blockchain smart contract application may record requests/reports when the massive IoT sensor 112 is recognized, analyze and inspect the collected data to determine whether an emergency event occurs at the installation places, and generate an alarm. The emergency event warning blockchain with smart contracts 130 may receive and collect data from the UE 120 through the wireless communication network and generate warning message for the environmental information from the collected data.

2. Massive IoT sensors 112 and UEs 114 may collect environmental information automatically and/or manually and may report them via a wireless communication module transmitting the environmental information measured from at least one sensor installed to the blockchain system 130 through the wireless communication network. A distributed ledger may at least record report information, power and operating states of the massive IoT sensors, and etc.

3. The blockchain system 130 may automatically collect and store environmental data by receiving the environmental information from at least one massive IoT sensor 112 and/or UE 114 by automatically executing the smart contract application. A warning alarm smart contract may determine whether emergency event occurs according to a result of analyzing the environmental data and may generate a warning alarm when it determines that the emergency event occurs. A distributed ledger may record a history managing and inspecting a history for the installation place and the massive IoT sensors 112 and/or UEs 114 by duplicate in all nodes. The blockchain may transmit the collected environmental data to the emergency event warning smart contract which automatically sends out emergency event warning according to the result analyzed from the environmental data.

4. UEs 114 have two roles. One is the same function of sensor 112 but manually reporting the emergency event to the blockchain. The other is working as the receiver of emergency event warning broadcasting. UEs 114 are connected with the massive IoT sensors 112 through either local or remote wireless network. When the massive IoT sensor 112 is recognized, the UE 114 will automatically connect to the massive IoT sensor 112 as peer nodes in the blockchain system.

5. Some embodiments of the present disclosure propose a novel method for emergency event warning system, which comprises measuring various environmental information for an installation place from massive IoT sensors 112 and reporting various environmental information from UEs 114 including a predetermined number of sensors which are measuring various environmental information on installation places. The IoT sensors 112 or UEs 114 measure or report the environmental information in real time and transmit the environmental information to a blockchain system 130 via a wireless communication network. The blockchain system recognizes emergency event by UE’s reporting or measuring of the massive IoT sensor and receives the environmental information through the wireless communication network to collect environmental data. According to the smart contract defined, the blockchain system 130 analyzes the collected environmental data and warns and predicts whether emergency event occurs at an installation place from an analyzed result without a centralized decision-making process. The blockchain system 130 generates an alarm (to be broadcast via the base station 120) when it is determined that the emergency event occurs at the installation place according to a result of the warning and prediction.

6. In some embodiments of the present disclosure, the environmental data can be transmitted to emergency event warning blockchain through the wireless communication network when the environmental data transmitted from the UEs 114 or massive IoT sensors 112 are collected. A ledger of blockchain system 130 will manage a history of the environmental data in response to installation place of the massive IoT sensors 112 and/or locations of UEs 114. Smart contract program analyzes the collected environmental data and inspects the analyzed environmental data through an analyzed result in real time to at least generate an alarm broadcast to the UE via wireless network when it is determined that emergency event situation occurs at the installation place.

7. In some embodiments of the present disclosure, the resulted emergency event warning may also be relayed in a peer to peer network that the node positioned adjacent to the installation place and connected with the UE through the wireless communication network can receive the warning message from peer nodes to provide a rapid response to emergency warning.

Figure 3 shows hierarchy layers of some embodiments of the present disclosure for decentralized emergency event warning broadcasting.

For hierarchy perspective, it consists five layers to perform emergency warning broadcasting through a decentralized ledger system, as shown in Figure 3.

Referring to Figure 3, from top to bottom, there are application layer, incentive layer, consensus layer, network layer and data layer.

Application layer provides application interfaces on top of blockchain, and includes smart contract of emergency event prediction and judgment, hyper ledger managing a history of the environmental data in response to installation place of the massive IoT sensors 112 and/or locations of UEs 114, and warning broadcasting function of broadcasting the generated alarm to at least part of the UEs 114 (for example, those UEs nearby the location where the emergency event occurs or is to occur) via the underneath network layer.

Incentive layer distributes rewards to UE users who provide a valid and verified emergency event warning report. The incentive strategy may be based on the description of smart contract defined in the application layer. In response to determining the one or more actions meets the condition of the smart contract for emergency warning broadcasting, thereby validating the transaction/warning message record, rewarding the user with rewards corresponding to the condition will be initiated. However, if the bookkeeper selected in smart contract is not a human based device (not a UE, for example, an IoT sensor) . Then, the rewarding will be ignored. The incentive strategy process is incorporated in the system that is operatively connected with a blockchain decentralized network.

Consensus layer designates a globally accepted set of measures/report for processing, and a total or partial order on these measures/report of local environmental information, for example, Proof of Work, Sharding Consensus, Practical Byzantine Agreement and so on.

Network layer broadcasts and/or relays emergency warning messages among nodes and collects measures/reports from massive IoT sensors 112 and UEs 114. In addition, network layer may also have a function of local validation for the measures and reports from massive IoT sensors 112 and UEs 114.

Finally, data layer comprises blockchain data structure and physical storage, for example, Data Block, Chain Structure, Cryptographic Protocol, Digital Signature and so on.

Figure 4 shows a typical technical implementation according to some embodiments of the present disclosure with signal flows.

In Figure 4, a surrounding environmental state at an installation place are measured by using massive IoT sensor 412 in which various sensors are combined and are transmitted via eNB 420 supporting NB-IoT /LTE to blockchain with smart contract defined. The backend system 440 then inspects whether emergency event occurs through measurement data in real time, and an emergency situation will be transmitted from the blockchain 430 via eNB 420 to UEs 414 of users through an alarm when the emergency event occurs. The massive IoT sensors 412 are easily installed regardless of a place and thus system construction cost is low. They can remotely sense various environmental conditions with physical parameters, e.g. temperature, humidity, illumination, smoke, flame, sound, vibration, atmospheric pollution, gas, motion, and the like in order to embody a practical environment event for emergency warning broadcasting.

Some embodiments of the present disclosure may use a smart contract based on blockchain technique (blockchain 430) to analyze various information collected by the massive IoT sensors 412, configure the various information as decision making data, and process for applying the emergency broadcasting and even to provide a specific emergence safety service through cellular wireless network (eNB 420) for propagation without a centralized emergency broadcasting agent to provide faster response. This emergency event warning system measures and provides various information for installation places by using massive IoT sensors 412 and reports from UEs 414 of local users. It measures and collects various environmental information for the installation places in real time by using massive IoT sensors 412 in which a plurality of IoT sensors are combined together, and provides the various environmental information to UEs 414 of local users therethrough to inspect whether an emergency event occurs at the installation places.

Additionally, critical resources, such as cellular networks (eNB 420) , web APIs 450, and backend systems 440can be seamlessly connected to the digital ledger that is the blockchain 430.

Figure 5 shows a configuration of an environmental data measurement platform on a local sensor such as a massive IoT sensor and a UE (for example, 112 and 114 in Figure 1 and/or 412 and 414 in Figure 4) .

As shown in Figure 5, local sensors 540 comprise massive IoT sensors or UEs of users (which are combined among a plurality of sensors) measuring various environmental information (at installation places and locations) in real time. With local client software engine 530, the measured environmental information is transmitted to a wireless communication network (Data Network) . The blockchain system (emergency handling blockchain 520) includes a smart contract application that records and collects data by receiving the environment information from the massive IoT sensors or UEs through the wireless communication network in real time. Also, the smart contract analyzes and inspects the collected data to determine whether emergency event occurs at the installation places and generate an alarm.

The blockchain 520 serves as a distributed, decentralized service application which performs environmental data automatic collecting and stores environmental data received from one or more massive IoT sensors or UEs of local users by automatically executing the smart contract application. A warning alarm agreement function in the blockchain 520 determines whether emergency event occurs according to a result of analyzing the environmental data and generates a warning alarm when the emergency event occurs. A ledger of blockchain 520 manages or inspects a history for the installation place and the massive IoT sensors by transmitting the collected environmental data to the blockchain system with smart contracts.

Web API for service provision 510 is used for interconnection with upper-layer functions or applications to data mining or analytics purposes.

Figure 6 is a flow chart of a decentralized emergency event warning broadcasting process according to some embodiments of the present disclosure.

As shown in Figure 6, in step S610, a sensor (massive IoT sensors and UEs of local users) generates a transaction (for example, an emergency event report) associated with the smart contract to a wireless communication network. Then, in step S620, the report is broadcast to all peer nodes in the network. In step S630, the network of nodes (blockchain system) validates the report and the status of sensor by algorithms (smart contract, for example, according to Practical Byzantine Agreement) . In step S640, once verified, the report is combined with other reports to create a new block of data for the ledger. Herein, a verified report involves token, smart contracts, records and sensed data. In step S650, the network broadcasts the report and triggers emergency measures (for example, emergency event warning) . Thereafter, in step S660, the new block is then added to the existing blockchain, in a way that is permanent and unalterable. Finally, in step S670, the report and emergency warning broadcasting are completed.

Referring to Figure 6, to initiate an emergency measure/report, massive IoT sensors and UEs of local users need a client end software installed, being identified by a unique ID, address and a private key. An emergency measure/report created by the client software informs the blockchain network about the environmental information of the local position detected. The measure/report is created/generated with the digital signature of the sender (either massive IoT sensor or UE of local user) . The generated emergency report is then represented as a “block” and broadcast to the peer to peer blockchain network. The network of nodes validates the emergency report and the environmental information with a predetermined smart contract algorithm (for example, according to Practical Byzantine Agreement) .

Figure 7 shows an embodiment of present disclosure applicable in a mountain slide warning broadcasting scenario.

In Figure 7, massive IoT sensors 712 are deployed on a mountain for sensing various environmental information, for example, motions of blocks and soils on the mountain, humidity of soils, and so on. At the foot of the mountain, there are premises and people living there, and also there is a road passing by the mountain. The massive IoT sensors 712 measure in real time the various environmental information and provide them via eNB 720 to a decentralized blockchain system 730 with smart contract therethrough to inspect whether emergency event occurs at the installation place. UE 714 of a user sitting in a car running along the road or UE 714 of a user living in the premises can be used for manually reporting the emergency event and/or receiving emergency event alarm (for example, as shown in the dialogue block “

Urgent Alarm! ” ) broadcast by the blockchain system 730.

It configures an environmental data measurement node using the massive IoT sensors 712 and manual reports from UEs 714 of local users. That is, the environmental data measurement sensor 712 of the emergency event warning system is constituted by a client hardware. The client hardware represents the massive IoT sensors 712 or UEs 714. Also, a client software is installed in the client hardware as a software engine of IoT sensors 712 or UEs 714. It processes data by receiving a sensed signal and develops various application programming interfaces (APIs) usable in a mobile application. The plurality of massive IoT sensors are installed at the installation place to measure various environmental information for the installation place in real time. The massive IoT sensors 712 transmit the measured environmental information by using the cellular communication network 720. The detailed work flow of the embodiment of present disclosure applicable in the mountain slide warning broadcasting scenario as shown in Figure 7 may refer to those steps S610 –S670 having been described in conjunction with Figure 6 in details.

Figure 8 shows a flow chart 800 of a method used in an emergency warning broadcasting system according to an embodiment of the present disclosure. Please be noted that the optional steps are identified with dashed blocks and can be omitted according the actual requirements or application scenarios.

The emergency warning broadcasting system is operatively connected with a blockchain decentralized network. The blockchain decentralized network is used for facilitating rapid emergency identification and emergency warning broadcasting. Also, a smart contract is predefined on a plurality of peer nodes constituting the blockchain decentralized network. The plurality of peer nodes may comprise Internet of Things (IoT) sensors and/or User Equipments (UEs) . The IoT sensors can automatically detect the one or more emergency events, whereas the UEs can automatically or manually reports the one or more emergency events.

Referring to Figure 8, in step S810, a transaction/warning message record associated with the smart contract is received. Here, the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes respectively.

In step S820, a decentralized ledger stored in the plurality of peer nodes is accessed, and the decentralized ledger is updated based communications from the blockchain decentralized network.

In step S830, smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network is used to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validate the transaction/warning message record through a predefined consensus agreement. For example, the predefined consensus agreement can be at least one selected from Practical Byzantine Agreement, gossip protocols, and/or Conflict-free Replicated Data Type (CRDT) protocols, or other possibly suitable protocols developed in the future.

If the transaction/warming message record is validated in step S830 (S830: Yes) , the method goes to step S840 in which rewards are granted to a user of the UE that reported the emergency event or rewards to an IoT sensor that reported the emergency event are given up.

In step S850, the rewards can be deposited to a digital wallet owned by the user of the UE. Thereafter, in step S860, the decentralized ledger can be updated with information indicating depositing of the rewards into the digital wallet owned by the user of UE; and access to the decentralized ledger is provided to the blockchain decentralized network.

In one embodiment, the rewards can be received from an entity system, for example, a supplier, a government institute, or the like.

In an embodiment, the transaction/warning message record can be communicated to an originating node for both validation of the transaction/warning message record and validation of the transaction/warning message record to the blockchain decentralized network.

On the other hand, if the transaction/warming message record is not validated in step S830 (S830: No) , the method goes to step S842 in which the peer node that reported the emergency event is communicated that the indicated one or more emergency events do not meet the condition and information indicating false reports necessary to meet the condition. Then, in step S844, another transaction/warning message record associated with the smart contract is received, wherein this new transaction/warning message record comprises input data indicating one or more emergency events detected by the peer node. With the newly received transaction/warning message record, the method goes back to step S820 and S830 to perform validation of the newly received transaction/warning message record.

In some embodiments, the one or more emergency events can be detected based on one or more environmental parameters which comprise at least one of temperature, humidity, illumination, smoke, flame, sound, vibration, atmospheric pollution, gas, and/or motion.

In an embodiment, a block of the decentralized ledger may comprise at least one of the following items:

· a unique identification of the peer node,

· a timestamp,

· a location of the peer node,

· one or more emergency events,

· one or more environmental parameters,

· a public key of a previous block, and/or

· a public key of the current block.

In an embodiment, the one or more emergency events may comprise at least one of an earthquake, a fire, a flood, a landslide.

Figure 9 shows a peer node 900 used in an emergency warning broadcasting system according to at least some embodiments of the present disclosure.

As shown in Figure 9, the peer node 900 may comprise one or more sensors 910, a memory device 920, a communication device 930, and a processing device 940 operatively coupled to the sensors 910, the memory device 920 and the communication device 930.

The processing device 940 can be configured to receive a transaction/warning message record associated with a smart contract predefined on a blockchain decentralized network consisting of a plurality of peer nodes, wherein the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes respectively; access a decentralized ledger stored in the memory device 920, wherein the decentralized ledger is updated based communications from the blockchain decentralized network; and use smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record through a predefined consensus agreement. For example, the predefined consensus agreement can be at least one selected from Practical Byzantine Agreement, gossip protocols, and/or Conflict-free Replicated Data Type (CRDT) protocols, or other possibly suitable protocols developed in the future.

Alternatively, also referring to Figure 9, the peer node 900 may comprise one or more sensors 910, a memory device 920, a communication device 930, and a processing device 940 operatively coupled to the sensors 910, the memory device 920 and the communication device 930. The memory device 920 may have a computer program stored thereon. When the computer program is executed on the processing device 940, the processing device 940 can be caused to carry out the steps S610 –S670 or S810 –S860 of the above method described in details in conjunction with Figure 6 or Figure 8.

Referring back to Figure 1 and Figure 9, an emergency warning broadcasting system 100 is operatively connected with a blockchain decentralized network. The blockchain decentralized network is used for facilitating rapid emergency identification and emergency warning broadcasting. The blockchain decentralized network consists of a plurality of peer nodes 900 having a smart contract predefined thereon. The plurality of peer nodes 900 may comprise Internet of Things (IoT) sensors 112 and/or User Equipments (UEs) 114. The IoT sensors 112 can automatically detect the one or more emergency events, whereas the UEs 114 can automatically or manually reports the one or more emergency events.

Each peer node 112/114/900 may comprises one or more sensors 910, a memory device 920, a communication device 930 and a processing device 940 operatively coupled to the sensors 910 , the memory device 920 and the communication device 930. The processing device 940 can be configured to receive a transaction/warning message record associated with the smart contract, wherein the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes 112/114/900 respectively; access a decentralized ledger stored in the memory device 920, wherein the decentralized ledger is updated based communications from the blockchain decentralized network; and use smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record through a predefined consensus agreement. For example, the predefined consensus agreement can be at least one selected from Practical Byzantine Agreement, gossip protocols, and/or Conflict-free Replicated Data Type (CRDT) protocols, or other possibly suitable protocols developed in the future.

The processing device 940 can be further configured to, in response to determining that the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record, initiate rewarding a user of the UE that reported the emergency event with rewards corresponding to the condition, or give up rewards to an IoT sensor that reported the emergency event.

The processing device 940 can be further configured to deposit the rewards to a digital wallet owned by the user of the UE.

The processing device 940 can be further configured to update the decentralized ledger with information indicating depositing of the rewards into the digital wallet owned by the user of UE; and provide access to the decentralized ledger to the blockchain decentralized network.

The processing device 940 can be further configured to communicate the transaction/warning message record to an originating node for both validation of the transaction/warning message record and validation of the transaction/warning message record to the blockchain decentralized network.

On the other hand, the processing device 940 can be further configured to, in response to determining that the indicated one or more emergency events do not meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting, communicate, to the peer node that reported the emergency event, that the indicated one or more emergency events do not meet the condition and information indicating false reports necessary to meet the condition; receive another transaction/warning message record associated with the smart contract, wherein this new transaction/warning message record comprises input data indicating one or more emergency events detected by the peer node; re-access the decentralized ledger; and use the smart contract logic associated with the smart contract to determine that the one or more emergency reports meet the condition of the smart contract and to thereby validate the transaction/warning message record.

· a unique identification of the peer node,

· a timestamp,

· a location of the peer node,

· one or more emergency events,

· one or more environmental parameters,

· a public key of a previous block, and/or

· a public key of the current block.

Figure 10 shows a peer node 1000 used in an emergency warning broadcasting system according to at least some other embodiments of the present disclosure.

As shown in Figure 10, the peer node 1000 may comprise a receiving unit 1010 configured to receive a transaction/warning message record associated with a smart contract predefined on a blockchain decentralized network consisting of a plurality of peer nodes, wherein the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes respectively; an accessing unit 1020 configured to access a decentralized ledger stored in the peer node, wherein the decentralized ledger is updated based communications from the blockchain decentralized network; and a validating unit 1030 configured to use smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record through a predefined consensus agreement. For example, the predefined consensus agreement can be at least one selected from Practical Byzantine Agreement, gossip protocols, and/or Conflict-free Replicated Data Type (CRDT) protocols, or other possibly suitable protocols developed in the future.

Figure 11 schematically shows an embodiment of a peer node 1100 which may be used as Internet of Things (IoT) sensors 112 and/or User Equipments (UEs) 114.

Comprised in the peer node 1100 are here a processing unit 1106, e.g., with a Digital Signal Processor (DSP) . The processing unit 1106 may be a single unit or a plurality of units to perform different actions of procedures described herein. The peer node 1100 may also comprise an input unit 1102 for receiving signals from other entities, and an output unit 1104 for providing signal (s) to other entities. The input unit and the output unit may be arranged as an integrated entity or as illustrated in the example of Figure 11.

Furthermore, the peer node 1100 comprises at least one computer program product 1108 in the form of a non-volatile or volatile memory, e.g., an Electrically Erasable Programmable Read-Only Memory (EEPROM) , a flash memory and a hard drive. The computer program product 1108 comprises a computer program 1111, which comprises code/computer readable instructions, which when executed by the processing unit 1106 in the peer node 1100 causes the peer node 1100 in which it is comprised to perform the actions, e.g., of the procedure described earlier in conjunction with Figure 6 or Figure 8.

In an embodiment, the computer program 1110 may be configured as a computer program code structured in computer program modules 1181 –1187 corresponding to the actions of S610 –S670 respectively or computer program modules 1191 –1198 corresponding to the actions of S810 –S860 respectively.

For concise and simplicity, the relevant actions of the processing unit 1106 caused by the computer program modules 1181 –1187 or 1191 –1198 are exactly corresponding to those performed by massive IoT sensors 112 or UEs 114 so that peer node 1100 can be used as the massive IoT sensors 112 or UEs 114 described in the present disclosure.

Although the code means in the embodiments disclosed above in conjunction with Figure 11 are implemented as computer program modules which when executed in the processing unit causes the device to perform the actions described above in conjunction with the figures mentioned above, at least one of the code means may in alternative embodiments be implemented at least partly as hardware circuits.

The processor may be a single CPU (Central processing unit) , but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and/or related chips sets and/or special purpose microprocessors such as Application Specific Integrated Circuit (ASICs) . The processor may also comprise board memory for caching purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may comprise a computer readable medium on which the computer program is stored.

For example, the computer program product may be a flash memory, a Random-access memory (RAM) , a Read-Only Memory (ROM) , or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories within the UE.

In an embodiment of the present disclosure, there is provided a computer-readable storage medium (e.g., computer program product 1108) storing instructions that when executed, cause one or more computing devices to perform the methods according to the present disclosure.

Therefore, some embodiments of present disclosure can be summarized as,

1. An emergency warning broadcasting system operatively connected with a blockchain decentralized network and for using the blockchain decentralized network for facilitating rapid emergency identification and warning broadcasting of a smart contract rewards program.

2. The nodes in emergency warning broadcasting system comprising: multiple IoT sensors, a memory device, a communication device and a processing device operatively coupled to the memory device, communication device and IoT sensors. Also the node is configured to execute a piece of program code to: receive a transaction/warning message record associated with a smart contract, wherein the transaction/warning message record comprises either IoT sensor data or human reporting of emergency that indicate one or more emergency events detected by IoT sensors or a user respectively; access a decentralized ledger stored in the memory device, wherein the decentralized ledger is updated based on communications from a blockchain decentralized network; and using smart contract logic associated with the smart contract on the application layer of the decentralized blockchain system, determine whether the indicated one or more emergency events meet a condition of the smart contract for warning identification and broadcasting, thereby validating the transaction/warning message record through a proper consensus agreement e.g. Practical Byzantine agreement etc.

3. The nodes can be either an unmanned IoT sensor node or a UE with human control.

4. The nodes are configured to execute a piece of program code in response to determining the one or more emergency events meet a predetermined condition of the smart contract for emergency identification and broadcasting, thereby validating the transaction/warning message record, initiate rewarding the user with rewards corresponding to the condition or give up rewarding the IoT sensor node that reported the emergency event.

5. The nodes are configured to execute a piece of program code further to communicate the transaction/warning message record to an originating node for both validation of the transaction/warning message record and validation of the transaction/warning message record to the block chain distributed network.

6. The nodes update the distributed ledger with information indicating validation of the transaction record and provide access to the distributed ledger to the block chain distributed network.

7. The nodes can be configured to execute a piece of program code to deposit the rewards into a digital wallet owned by the user of UE or give up rewards for unmanned IoT sensor node.

8. The nodes are configured to execute a piece of program code to update the distributed ledger with information indicating depositing of the rewards into the digital wallet owned by the user of UE and provide access to the distributed ledger to the blockchain decentralized network. It is also possible to receive, from an entity system, a rewards deposit comprising the rewards and information associating the rewards with the smart contract. A reward deposit comprises the rewards and information associating the rewards with the transaction/warning message record. The nodes are capable to receive the rewards deposit and validating the transaction/warning message record, initiate rewarding the user of UE with the rewards corresponding to the condition.

9. The nodes are configured to execute a piece of program code further to determine that the indicated one or more emergency reports do not meet the condition; communicate, to the user of UEs or unmanned IoT sensor nodes , that the indicated one or more emergency reports do not meet the condition and information indicating false reports necessary to meet the condition; receive another transaction/warning message record associated with the smart contract, wherein the transaction/warning message record comprises input data indicating one or more emergency reports detected by the user or IoT sensor node; re-access the distributed ledger; using the smart contract logic associated with the smart contract, determine that the one or more emergency reports meet the condition of the smart contract, thereby validating the transaction/warning message record; and in response to validating the transaction/warning message record, initiate rewarding the user of UE with rewards corresponding to the condition or give up rewarding if the node is an unmanned IoT sensor node.

Although the present technology has been described above with reference to specific embodiments, it is not intended to be limited to the specific form set forth herein. For example, the embodiments presented herein are not limited to the existing NR/LTE configuration; rather they are equally applicable to new NR/LTE configurations defined in future. The technology is limited only by the accompanying claims and other embodiments than the specific above are equally possible within the scope of the appended claims. As used herein, the terms “comprise/comprises” or “include/includes” do not exclude the presence of other elements or steps. Furthermore, although individual features may be included in different claims, these may possibly advantageously be combined, and the inclusion of different claims does not imply that a combination of features is not feasible and/or advantageous. In addition, singular references do not exclude a plurality. Finally, reference signs in the claims are provided merely as a clarifying example and should not be construed as limiting the scope of the claims in any way.

Claims

A method used in an emergency warning broadcasting system operatively connected with a blockchain decentralized network, wherein the blockchain decentralized network is used for facilitating rapid emergency identification and emergency warning broadcasting.
The method according to claim 1, wherein a smart contract is predefined on a plurality of peer nodes constituting the blockchain decentralized network, and the method comprises steps of:

receiving a transaction/warning message record associated with the smart contract, wherein the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes respectively;

accessing a decentralized ledger stored in the plurality of peer nodes, wherein the decentralized ledger is updated based communications from the blockchain decentralized network; and

using smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validate the transaction/warning message record through a predefined consensus agreement.
The method of claim 2, wherein

the plurality of peer nodes comprise Internet of Things (IoT) sensors and/or User Equipments (UEs) , and/or

the IoT sensors automatically detects the one or more emergency events, whereas the UEs automatically or manually reports the one or more emergency events.
The method of claim 2 or 3, wherein the method further comprises a step of:

in response to determining that the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record,

granting rewards to a user of the UE that reported the emergency event or giving up rewards to an IoT sensor that reported the emergency event.
The method of claim 4, wherein the method further comprises a step of:

depositing the rewards to a digital wallet owned by the user of the UE.
The method of claim 5, wherein the method further comprises steps of:

updating the decentralized ledger with information indicating depositing of the rewards into the digital wallet owned by the user of UE; and

providing access to the decentralized ledger to the blockchain decentralized network.
The method of any of claim 4 –6, wherein the rewards are received from an entity system.
The method of any of claims 2 –7, wherein

the transaction/warning message record is communicated to an originating node for both validation of the transaction/warning message record and validation of the transaction/warning message record to the blockchain decentralized network.
The method of claim 2 or 3, wherein the method further comprises steps of:

in response to determining that the indicated one or more emergency events do not meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting,

communicating, to the peer node that reported the emergency event, that the indicated one or more emergency events do not meet the condition and information indicating false reports necessary to meet the condition;

receiving another transaction/warning message record associated with the smart contract, wherein the another transaction/warning message record comprises input data indicating one or more emergency events detected by the peer node;

re-accessing the decentralized ledger; and

using the smart contract logic associated with the smart contract to determine that the one or more emergency reports meet the condition of the smart contract and to thereby validate the transaction/warning message record.
The method of any of claims 1 –9, wherein the predefined consensus agreement is at least one selected from Practical Byzantine Agreement, gossip protocols, and/or Conflict-free Replicated Data Type (CRDT) protocols.
The method of any of claims 1 –10, wherein the one or more emergency events are detected based on one or more environmental parameters which comprise at least one of temperature, humidity, illumination, smoke, flame, sound, vibration, atmospheric pollution, gas, and/or motion.
The method of any of claims 1 –11, wherein

a block of the decentralized ledger comprises at least one of the following items:

· a unique identification of the peer node,

· a timestamp,

· a location of the peer node,

· one or more emergency events,

· one or more environmental parameters,

· a public key of a previous block, and/or

· a public key of the current block.
The method of any of claims 1 –12, wherein

the one or more emergency events comprise at least one of an earthquake, a fire, a flood, a landslide.
An emergency warning broadcasting system operatively connected with a blockchain decentralized network, wherein the blockchain decentralized network is used for facilitating rapid emergency identification and emergency warning broadcasting.
The emergency warning broadcasting system according to claim 14, wherein the blockchain decentralized network consists of a plurality of peer nodes having a smart contract predefined thereon,

wherein each peer node comprises one or more sensors, a memory device, a communication device and a processing device operatively coupled to the sensors, the memory device and the communication device, and the processing device is configured to:

receive a transaction/warning message record associated with the smart contract, wherein the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes respectively;

access a decentralized ledger stored in the memory device, wherein the decentralized ledger is updated based communications from the blockchain decentralized network; and

use smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record through a predefined consensus agreement.
The emergency warning broadcasting system of claim 15, wherein

the plurality of peer nodes comprise Internet of Things (IoT) sensors and/or User Equipments (UEs) , and/or

the IoT sensors automatically detects the one or more emergency events, whereas the UEs automatically or manually reports the one or more emergency events.
The emergency warning broadcasting system of claim 15 or 16, wherein the processing device is further configured to:

in response to determining that the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record,

initiate rewarding a user of the UE that reported the emergency event with rewards corresponding to the condition or give up rewards to an IoT sensor that reported the emergency event.
The emergency warning broadcasting system of claim 17, wherein the processing device is further configured to:

deposit the rewards to a digital wallet owned by the user of the UE.
The emergency warning broadcasting system of claim 18, wherein the processing device is further configured to:

update the decentralized ledger with information indicating depositing of the rewards into the digital wallet owned by the user of UE; and

provide access to the decentralized ledger to the blockchain decentralized network.
The emergency warning broadcasting system of any of claim 17 –19, wherein the rewards are received from an entity system.
The emergency warning broadcasting system of any of claims 19 –20, wherein the processing device is further configured to:

communicate the transaction/warning message record to an originating node for both validation of the transaction/warning message record and validation of the transaction/warning message record to the blockchain decentralized network.
The emergency warning broadcasting system of claim 15 or 16, wherein the processing device is further configured to:

in response to determining that the indicated one or more emergency events do not meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting,

communicate, to the peer node that reported the emergency event, that the indicated one or more emergency events do not meet the condition and information indicating false reports necessary to meet the condition;

receive another transaction/warning message record associated with the smart contract, wherein another transaction/warning message record comprises input data indicating one or more emergency events detected by the peer node;

re-access the decentralized ledger; and

use the smart contract logic associated with the smart contract to determine that the one or more emergency reports meet the condition of the smart contract and to thereby validate the transaction/warning message record.
The emergency warning broadcasting system of any of claims 14 –22, wherein the predefined consensus agreement is at least one selected from Practical Byzantine Agreement, gossip protocols, and/or Conflict-free Replicated Data Type (CRDT) protocols.
The emergency warning broadcasting system of any of claims 14 –23, wherein the one or more emergency events are detected based on one or more environmental parameters which comprise at least one of temperature, humidity, illumination, smoke, flame, sound, vibration, atmospheric pollution, gas, and/or motion.
The emergency warning broadcasting system of any of claims 14 –24, wherein

a block of the decentralized ledger comprises at least one of the following items:

· a unique identification of the peer node,

· a timestamp,

· a location of the peer node,

· one or more emergency events,

· one or more environmental parameters,

· a public key of a previous block, and/or

· a public key of the current block.
The emergency warning broadcasting system of any of claims 14 –25, wherein

the one or more emergency events comprise at least one of an earthquake, a fire, a flood, a landslide.
A peer node comprising:

one or more sensors;

a memory device;

a communication device; and

a processing device operatively coupled to the sensors, the memory device and the communication device,

wherein the processing device is configured to:

receive a transaction/warning message record associated with a smart contract predefined on a blockchain decentralized network consisting of a plurality of peer nodes, wherein the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes respectively;

access a decentralized ledger stored in the memory device, wherein the decentralized ledger is updated based communications from the blockchain decentralized network; and

use smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record through a predefined consensus agreement.
A peer node comprising:

a receiving unit configured to receive a transaction/warning message record associated with a smart contract predefined on a blockchain decentralized network consisting of a plurality of peer nodes, wherein the transaction/warning message record indicates one or more emergency events detected or reported by the plurality of peer nodes respectively;

an accessing unit configured to access a decentralized ledger stored in the peer node, wherein the decentralized ledger is updated based communications from the blockchain decentralized network; and

a validating unit configured to use smart contract logic associated with the smart contract on an application layer of the decentralized blockchain network to determine whether the indicated one or more emergency events meet a predefined condition of the smart contract for emergency identification and emergency warning broadcasting and to thereby validating the transaction/warning message record through a predefined consensus agreement.
A peer node comprising:

one or more sensors;

a memory device;

a communication device; and

a processing device operatively coupled to the sensors, the memory device and the communication device,

wherein the memory device having stored thereon a computer program which, when executed on the processing device, causes the processing device to carry out the method according to any one of claims 1 to 13.
A computer-readable storage medium, having stored thereon a computer program which, when executed on at least one processor, causes the at least one processor to carry out the method according to any one of claims 1 to 13.