Patent Description:
In network systems of facilities that are part of the critical infrastructure of a region, a state or a country, there is a high interest in keeping them running even in times of crisis, extreme large-scale disasters, or other events that can stress such networks.

Critical infrastructure is a term used by governments to describe assets that are essential for the functionality of a society and economy - the infrastructure. Most commonly associated with this term are facilities for shelter, heating (e. natural gas, fuel oil, district heating), agriculture, food production and distribution, water supply (e. drinking water, waste water/sewage, stemming of surface water (e. dikes and sluices), public health (e. emergencies, hospitals, ambulances), transportation systems (e. fuel supply, railway network, airports, harbors, inland shipping), security services (e. police, military), electricity generation, transmission and distribution (e. natural gas, fuel oil, coal, nuclear power), renewable energy which are naturally replenished on a human timescale, such as sunlight, wind, rain, tides, waves, and geothermal heat, telecommunication (e. coordination for successful operations). Further, the business or economic sector as well as goods and services and financial services (e. banking, clearing) may also be affected by such crises.

In this context, such facilities and, above all, their networks must not only operate stably and reliably in a crisis situation, but must also observe certain legal, infrastructural or other rules. Mostly or primarily, government organizations or surveillance are directly connected to these institutions or are in close contact with them.

Such critical infrastructure facilities and/or public sectors described above usually have one or more central component in their networks that handle these legal or other conditions with the help of so-called policy rules for the network.

Thereby, policy rules operate under a set of conditions that the one or more central component of the network determines and, if mandatory, the governmental organizations agree to.

In extreme situations (e. environmental events, war) but also in some cases of everyday overload situations (e. traffic jams, fire, etc.), the otherwise rather rigid and locally limited regulations must be extended to a wider geographical area and, if necessary, also to a wider area of responsibility, while remaining dynamic, i. adjusted to the current situation.

The non-patent literature document titled "Performance Testing for VoIP Emergency Services: a Case Study of the EMYNOS Platform and a Reflection on potential Blockchain Utilisation for NG112 Emergency Communication", KUMAR SUBUDHI BUDANKAILU ET AL, discloses the integration of emergency communication infrastructure (i.e. NG112) with emerging blockchain platforms and their utilisation for fraud detection. <CIT> discloses a method for determining policy information associated with an emergency call. <CIT> discloses a method for clustering of the emergency services routing proxy which allow a group of ESRPs, running as individual servers or a group of virtual servers, to be referenced using a single URI.

Currently, in such facility networks of critical infrastructure and/or the public sector there are preconfigured policy rules with certain priority orders and/or time slots based on multiple conditions and schemes. These rules have been inserted and updated manually to one or more network component and are maintained by the administrators of the central component. If there is any reason to reconsider and update them, the administrator of the system has to modify them manually. This means that they are static, no real time update exists and in case of large-scale disasters, they are not efficient.

Therefore, the present invention is based on the object to provide a method and a corresponding system for retrieving and applying dynamic policy rules in a network. It is an object of the present invention to provide a system and method for making the update process of policing rules dynamic, efficient and secure. Furthermore, another objective of the present invention is to keep the entire update process tamper-proof, transparent and reproducible among the authorized participants of this process.

This object is solved by a method having the features according to claim <NUM> and a system having the features of claim <NUM>. Preferred embodiments of the invention are defined in the respective dependent claims.

According to the invention, a method for retrieving and applying dynamic policy rules in a network is provided, the method comprising the steps of:.

According to a preferred embodiment, the one or more service client further comprising an agent or callee which can provide services and/or the one or more requesting client further comprising a requester or caller having a task request.

According to another preferred embodiment, the central unit is an Emergency Service Routing Proxy, ESRP, the one or more service client is a Public Safety Answering Point, PSAP; and the one or more requesting client is a Telecommunication Service Provider, TSP.

According to still another preferred embodiment, the attribute comprising at least one of skill, qualification, meta-traumatic experience, expertise, average response time, language, multitasking, number of agents or service providers, number of active calls, number of diverted calls, number of agents or service providers with a certain skill or expertise, CPU usage, memory, historical statistics, capacity, delays, jitter, Quality of Service, QoS, network performance, bandwidth, network metrics or network traffic.

Further, according to a preferred embodiment, wherein before the step of analyzing the method further comprising:.

According to yet another preferred embodiment, in the case the blockchain policy rules have to be updated, the method further comprising the steps:.

According to the invention, a system for retrieving and applying dynamic policy rules in a network is provided, wherein the system comprises a blockchain network, one or more request client, a central unit, a client application interface, a Policy Server of a blockchain-based Policy Store Platform for consuming services with the Policy Server and the blockchain network, a predictor component, one or more service client and wherein the system is configured to perform the corresponding method.

According to a preferred embodiment, the system at least comprising:.

According to another preferred embodiment, the one or more service client further comprising an agent or callee which can provide services and/or the one or more requesting client further comprising a requester or caller having a task request.

According to still another preferred embodiment, the blockchain network further comprising:.

Further, according to a preferred embodiment, wherein the central unit is an Emergency Service Routing Proxy, ESRP, the one or more service client is a Public Safety Answering Point, PSAP, and the one or more requesting client is a Telecommunication Service Provider, TSP.

In more detail, the present invention proposes a method and a system that calculates, evaluates, publishes and updates policy rules based on predictive algorithms and blockchain techniques for systems in the area of critical infrastructure but also for a public/business sector. Thereby, the blockchain network behaves as the central system of all operations. The provided policy rules and their priorities are securely encrypted and stored in a blockchain database. All policies are recorded within the system and shared transparently among the participants. Since they are generated, they cannot be edited or modified. In case something occurs, there is always the transaction reported as point of reference to invoke and inspect the update and further actions and/or processes resulting from this. Further, the invention offers an automated process triggered whenever new or updated data and metrics receive the blockchain network. This eliminates the human intervention and keeps the system always updated, especially when time plays a crucial role in the update process.

All these updated data is correlated in order to provide a dynamic capacity of the network. This capacity would be re-estimated and re-evaluated whenever an event occurs. The result of all these policy rule evaluations leads to a reliable network with high quality of service, avoiding the calculation and evaluation of complex decisions under stressed conditions where time matters and minimizing the risk of an overcrowded network that could become unavailable in a short period of time.

In the following, the invention will be described in more detail, using the example of emergency call networks, as a representative example of the many use cases in critical infrastructure or public/business sector networks.

In extreme large-scale disasters, there is a rapid explosion of emergency calls that reach the emergency systems and Public Safety Answering Points (PSAPs). This situation is further worsened with the overload calls that reach the PSAPs daily due to pandemics such as COVID-<NUM>.

At the legacy PSAPs, there is a mutual agreement among PSAPs to support them and take emergency calls under certain circumstances such as large-scale disasters, network outage, etc. Call diversion is the official term when the calls that were originally meant for one PSAP based on geolocation, are finally sent to another PSAP. Next generation (NG) emergency systems (e. NG <NUM> or NG <NUM>) address the call diversion challenging through the Policy Store and Emergency Services Routing Proxy (ESRP) components. These components are responsible to develop a list of rules and conditions (rulesets) to deal with its call diversion needs, called Policy Routing Rules (PRRs). The Policy Store is the repository for the collection of PRRs for an agency (e.g., PSAP). PRRs are entered into the Policy Store of the next generation emergency system via a Policy Store Web Service. The ESRP makes a policy-based routing decision based on the location of the calling party after evaluating the origination policy ruleset and additional information. The additional information includes PSAP state and skilled based criteria of the call agents such as the caller's language preference, etc..

Currently, the existing solutions propose to switch from routing tables that meet certain conditions to more flexible distribution schemes where routing schemes based on multiple conditions would be applied. These rules have been inserted and updated manually to the Policy Store component and are maintained by the administrators of the ESRP. The multi-conditions criteria that are considered for the call diversion are basically the PSAPs' service state (normal or abnormal) and agents' skills (i. language, availability). However, the PSAP's service state and the skill-based techniques are not efficient and adequate in order to decide the call diversion, especially when we have to deal with a large-scale disaster where numerous emergency calls are generated per second. In these cases, we deal with the challenge to overcrowd certain PSAPs while other remain idle or at a low load.

The present invention proposes a system and a method for publishing and updating policy rules based on predictive algorithms and blockchain techniques. A blockchain network can behave as the central system of all operations. This solution would be a significant tool in order to dynamically update the policy rules applied at the Policy Store and divert the emergency calls in an efficient way to the most reliable PSAP(s) avoiding the risk of overcrowded PSAPs that could turn to be unfunctional in a short period of time, experience high waiting time and finally increase abandoned calls.

The invention and embodiments thereof will be described below in further detail in connection with the drawings. The various embodiments and/or their individual sub-items and features can be combined with each other in any logical way. Even if some of the embodiments are described on the basis of emergency call networks, they are explicitly not limited to them but can also be applied to other networks of the critical infrastructure or the economy.

<FIG> schematically shows a conceptual overview of a blockchain-based Policy Store Platform <NUM> according to an embodiment of the invention. This embodiment of the invention proposes a system and a method for applying and updating policy rules based on predictive algorithms and blockchain techniques. In this context, the policy rules and priority updates are built into the blockchain to facilitate, verify, and define the most appropriate service provider <NUM> or service endpoint. Policy rules operate under a set of conditions that a central unit determines, and governmental organizations <NUM> agree to. When those conditions are met, the policies are created in order to divert service requests efficiently and with high quality of service, avoiding the retargeting of services among various endpoints especially under stressed conditions where time matters. As can be seen from <FIG>, the participants of a blockchain-based Policy Store Platform <NUM> in this embodiment are requesting clients <NUM>, service clients <NUM> with their service providers or agents <NUM> and surveillance, e. governmental organizations <NUM>. The clients <NUM>, <NUM> are registered and certified by the surveillance, e. governmental organizations <NUM>. Governmental organizations <NUM> supply to the blockchain platform <NUM> the contracts among the various service clients <NUM> to support each other when there are outages either scheduled or unscheduled such as a scheduled maintenance window or mass disasters. Governmental organizations <NUM> also verify the authorization and authentication of the service clients <NUM>. Each service client <NUM> is responsible to register and certify the active service providers or agents <NUM> upon their login to their specified service client application that handles different services. The information is securely encrypted and stored in a blockchain database <NUM> using cryptographic hash block encoded into a Merkle tree.

<FIG> schematically shows a conceptual overview of a blockchain-based Policy Store Platform <NUM> concerning an emergency network according to an embodiment of the invention. Currently, no solution exists that enables dynamic policy enforcement and priority update at the emergency systems. In this context, the policy rules and priority updates are built into the blockchain to facilitate, verify, and define the most appropriate PSAP endpoints <NUM> A, <NUM> B, <NUM> N. Policy rules operate under a set of conditions that a ESRP <NUM> as a central unit determines, and governmental organizations <NUM> agree to. When those conditions are met, the policies are created in order to divert emergency calls efficiently and with high quality of service, avoiding the retargeting of the call among various endpoints under stressed conditions where time matters. As can be seen from <FIG>, the participants of a blockchain-based Policy Store Platform <NUM> in this embodiment are telecommunication providers <NUM> A, <NUM> B, <NUM> N, callers <NUM> A, <NUM> B, <NUM> N, PSAP endpoints <NUM> A, <NUM> B, <NUM> N with their active logged in call agents <NUM> A, <NUM> B, <NUM> N and governmental organizations <NUM>. The telecommunication service providers <NUM> A, <NUM> B, <NUM> N and PSAPs <NUM> A, <NUM> B, <NUM> N are registered and certified by the governmental organizations <NUM>. Governmental organizations <NUM> supply to the blockchain platform <NUM> the contracts among the various PSAPs <NUM> A, <NUM> B, <NUM> N to support each other when there are outages either scheduled or unscheduled such as a scheduled maintenance window or mass disasters. Governmental organizations <NUM> also verify the authorization and authentication of the PSAPs <NUM> A, <NUM> B, <NUM> N. Each PSAP <NUM> A, <NUM> B, <NUM> N is responsible to register and certify the active call takers <NUM> A, <NUM> B, <NUM> N upon their login to the PSAP application (i. a public safety network administration application and call handling systems) that handles emergency calls. The information is securely encrypted and stored in a blockchain database using cryptographic hash block encoded into a Merkle tree.

In <FIG> an architectural overview of a blockchain-based Policy Store Platform <NUM> according to another embodiment of the invention is shown. All participants of a blockchain-based Policy Store Platform <NUM> interact with each other through an application <NUM> based on the blockchain. Thereby, a client-side application <NUM> provides an interface to enable all PSAPs <NUM> A, <NUM> B, <NUM> N, telecommunication service providers <NUM> A, <NUM> B, <NUM> N and active call takers <NUM> A, <NUM> B, <NUM> N, to be registered/subscribed to the blockchain platform <NUM>. The client application interface <NUM> enables them to submit transactions to the blockchain network <NUM> of the blockchain-based Policy Store Platform <NUM> for consuming services such as registration of PSAP <NUM> A, <NUM> B, <NUM> N, agent <NUM> A, <NUM> B, <NUM> N and telecommunication providers <NUM> A, <NUM> B, <NUM> N, notifications, and update tasks when there are changes on each participants statements or requesting to supply policy rules so as to target the calls to the appropriate endpoint. The blockchain-based Policy Store Platform <NUM> comprises a Policy Server <NUM> component and the blockchain network <NUM>. The Policy Server <NUM> component is a service provider which interacts as an intermediate message broker among the blockchain network <NUM> and the client-side application interface <NUM>. Blockchain network <NUM> facilitates the decision process and supplies the appropriate policies to the ESRP <NUM>. Thereby, the blockchain network <NUM> integrates blockchain mining and predictor algorithms and tools as well as a blockchain database <NUM>. The blockchain predictor component uses artificial intelligence algorithms and machine learning techniques in order to train algorithms using the aggregated data, provide predictive models and make decisions to target the calls to the appropriate PSAP endpoints <NUM> A, <NUM> B, <NUM> N based on various criteria.

<FIG> shows a sequence diagram of updating telecommunication provider's <NUM> information according to another embodiment of the invention. Telecommunication providers <NUM> measure and provide predictive metrics for PSAPs' capacity by means of network characteristics such as delays, jitter, network traffic, etc. The information regarding to each PSAP metrics is sent to a blockchain-based Policy Store Platform <NUM> through a client application interface <NUM>, also called client app. A Policy Server <NUM> component (also called Policy Server App) receives a request to create a new transaction with the updated information of the network metrics and marks the previous one as obsolete. Before submitting the update, an enrollment is required to supply the transaction. The update is a process of requesting to read and write data to the blockchain database <NUM>. Upon the verification of the certificates, the blockchain-based Policy Store Platform <NUM> is updated with the new metrics. A block representing this transaction is created. The transaction respectively the block is then forwarded to the blockchain network <NUM>.

<FIG> shows a sequence diagram as in <FIG>, showing subscribing and updating information about each PSAP <NUM> and its agents. In the same way, each PSAP <NUM> is responsible to calculate and report information related to its capacity. PSAP's <NUM> capacity is not limited to its CPU usage, memory, historical statistics, and other measurements but is a dynamic attribute calculated using artificial intelligence and machine learning algorithms and correlated with various attributes that cover a wide area of network and call taker's metrics. When an agent logs in the PSAP application that handles the emergency calls, data mining and analytics algorithms are triggered in order to provide an estimation related to agent's average response time, performance, specialties (i. handle multiple text emergency calls, sign language, etc.), skills, etc. In this context, the PSAP information as well as the agents' information upon their login or logout to the PSAP <NUM> are reported to the blockchain platform <NUM> through the client application interface <NUM>. When an event occurs, the updated data is reported to the Policy Server <NUM> component and upon their verification, they are stored at the blockchain database for further use. The transactions that correspond to this event are generated and propagated to the blockchain network <NUM>. Blocks that represent these transactions are created.

In <FIG> chaining blocks of agents <NUM> A, PSAP <NUM> A and telecommunication provider <NUM> A are depicted. For each PSAP and its call agents, multiple blocks are created which represent the above (<FIG>/<FIG>) described transactions. These blocks are created based on different attributes (i. specialty <NUM>, skill n, etc.) to be easily tracked. The number of the blocks per agents varies based on his/her skills, qualifications, expertise and high stressful meta-traumatic emergency incidents addressed by them (i. serious injured people from vehicle accidents, bomb explosions, etc.) to confront extreme emergency cases during the previous or current day which affect their performance. The agents' blocks are then used as input and can be correlated with the PSAP's blocks and the telecommunication provider's blocks in order to create chains that satisfy certain criteria such as handle Spanish voice calls, etc. In <FIG>, for example, a chain of <NUM> blocks is shown. Block <NUM> contains attributes of telecommunication provider-A <NUM> A. This in turn is linked to Block <NUM>, which contains attributes of PSAP-A, <NUM> A. This Block <NUM> is in turn linked to Block <NUM> which contains attributes of the PSAP agent-A <NUM> A. In all transactions, blocks are recorded within the system and shared transparently among the participants. Since they are generated, they cannot be edited or modified. In this manner blockchain provides trust and ensures the wide spread of the transactions.

The process of applying and updating dynamic policies is described subsequently on the basis of <FIG>. When emergency calls arrive at the ESRP <NUM> component, the ESPR <NUM> component is responsible to target the emergency calls to the most appropriate PSAP <NUM> based on various aspects of call routing policy rules. In our proposal, the ESRP <NUM> performs task requests through the client application <NUM> to the Policy Server <NUM> with more complex criteria so as to efficiently target calls to the most suitable PSAPs <NUM> avoiding multiple hops with uncertainty of the outcome. Thus, the ESRP <NUM> requests to receive the transactions, by means of chain of blocks that correspond to the policy rules, in order to target the incoming calls to the appropriate endpoints based on various attributes such as their geolocation data, the type of the call, the number of the incoming calls as well as some special requirements for skills, etc. These requests are propagated to the blockchain network. Based on the collected information from the transactions per agents, PSAPs <NUM> and telecommunication network metrics, as described above (<FIG>, <FIG> and <FIG>), the blockchain predictor component of the blockchain network <NUM> analyzes the requested data, retrieves the stored data per PSAP <NUM> and agents, and makes decisions on which PSAPs <NUM> and agents in correlation with the network capabilities satisfy the requested criteria. The output of the decision process is a list of blockchains, policy rules, that satisfy the request task. As presented in <FIG>, the result of the policies is forwarded to the Policy Server <NUM> which transmits the policies to the client application <NUM> and the ESRP <NUM> component. The ESRP <NUM> component applies these policies to the emergency calls and routes them to the indicated PSAP <NUM> endpoint(s). In the following, the decision process will be described in greater detail. Inside the blockchain-based Policy Store Platform <NUM>, the blockchain predictor component uses training algorithms and predictive models to determine a set of learning models. Each training algorithm is fed with preprocessed data of available variables i. agents' blocks, the number of the incoming calls, PSAP <NUM> and agent historical data, etc. The output of this regression process is a set of decision models that can be used to estimate the datasets into weighted relationships which can be tracked and automated with the adoption of blockchain technology. The PSAP's <NUM> and telecommunication provider's blocks created during the update transaction process are preprocessed with the trained data and correlated with each other in order to estimate the PSAP <NUM> capacity to handle the different types of calls and target the calls to the appropriate PSAP <NUM> endpoint(s). The output of a block can be used as an input for other blocks creating chain(s) of blocks that represent(s) transactions able to satisfy certain policies provided by the learning algorithms.

A visual description of the training and predictive process inside the blockchain network is presented in <FIG> for the training process and in <FIG> for the prediction process. In the first step of the training process, data is loaded from the blockchain database <NUM>. In this example these are PSAP blocks, telecommunication provider blocks and agent blocks. In the next step, the data is preprocessed using filters, historical analysis, correlated data and clustering. The next step is the learning process where a classification and regression of the data is performed. As a result of this learning process, different blockchain-based PSAP capacity models are obtained. In the prediction process, real-time blocks are processed. For example, aggregated blocks of PSAPs, telecommunication providers or agents are processed. These data blocks are first preprocessed, which means that various filters, historical analyses, correlated data and clustering can be applied. As a result, blockchain-based models are obtained from which the PSAP capacity can be predicted.

Whenever a request from ESRP <NUM> arrives at the blockchain-based Policy Store Platform <NUM>, the criteria of the request are analyzed, and the existing blockchain-based policies are evaluated. In <FIG>, for example, a request is made to the blockchain Policy Store Platform <NUM> regarding target calls with criteria (X, Y, Z). If the PSAP's capacity, in the caller's location, is sufficient to satisfy the request, the policies are transmitted to the ESRP <NUM>. If the PSAP's capacity is not sufficient, then cooperative models from different PSAPs are requested and applied. In case that no cooperative model to satisfy the criteria exists, the negotiation process with the remaining PSAPs takes place through the blockchain network. The PSAP with the highest weighted capacity after the negotiation process would be selected and the appropriate policies would be sent. In both the cases, the blockchain network is triggered to identify the blockchains that were affected and provides new predictive models and capacities for these PSAPs (<FIG>).

Blockchain-based dynamic policy creation based on requested parameters according to another embodiment of the invention for a specific example is depicted in <FIG>. For this example, it is assumed that a request to target <NUM> Spanish audio calls located at location-x requested by the ESRP <NUM> is made. The blocks that correspond to this location are retrieved and validated. If the PSAP <NUM> A block(s) at the location-x is/are valid according to stored trained data in the database <NUM>, then the network metrics from the telecommunication provider(s) <NUM> A that support the PSAP151 A are evaluated. In case the network metrics are sufficient to handle the number of calls, then the telecommunication provider <NUM> A is valid to take it into account for the chaining block process. Then the agent's <NUM> B-<NUM> block is chained with its PSAP <NUM> A block and the block of the network metrics for the PSAP <NUM> B that the agent belongs to. A chain with these blocks corresponds to a rule that the current agent <NUM> B-<NUM> is able to handle m-number of x-type emergency calls in a predefined period of time. Another chain exists that corresponds to the rule of handle n-number of y-type of emergency calls. Respectively, several chains for less complicated or more complicated scenarios are created based on the PSAPs <NUM> A, <NUM> B, <NUM> N capacity and the training.

For more complex requirements, when there are multiple types of calls that require, for example, different network bandwidth, the applied predictive methods may be based on historical statistics and current monitoring metrics provide estimation of the capacity of the PSAP <NUM> A, meaning the maximum calls that can be handled, the average waiting time for a diverted call in the queue classified with the agent's171 A-<NUM> to <NUM> characteristics. In this case telecommunication service provider <NUM> B supports PASP <NUM> A and provides its network metrics. Multiple chains are created, each one declares a distinct policy with its priority order (see <FIG>). For example, blockchain-based policy <NUM> would be used to target the x webRTC calls to the Agent <NUM> A-<NUM> (Agent 0xrte367mh12sd67) and alternate Agent <NUM> A-<NUM> (Agent 0xcv653908fhk) while the policy-<NUM> would be used to target the remaining text and audio calls to the Agents <NUM> A-<NUM> Ox7bdjihtlk7yodnmbnq and <NUM> A-<NUM>0xrte367mh12 respectively. The ESRP <NUM> would be able to send these types of calls to these Agents until the expiration of the policy in case there is no further update.

These policy blockchains are updated dynamically when an agent logs in or out the PSAP as well as when the network metrics and PSAP capacity change (see <FIG>). For example, when high traffic is identified by the telecommunication providers for a specific PSAP(s), an update request is propagated to the blockchain network. Each entity of the blockchain network is informed and updated with the latest information. This triggers the blockchain predictive mechanism of identifying the chains and blocks that are affected, updating the existing chains, and creating new blocks and chains for the new policies (see <FIG>). This means that when a request arrives at the blockchain network to requesting to divert calls to other PSAPs, the policy rules and the priorities at the Policy Store <NUM> side are updated with each PSAP's status and saturation level in order to divert emergency calls to the most suitable PSAP(s) avoiding overcrowded PSAPs.

<FIG> shows a flowchart of a blockchain-based policy update process according to another embodiment of the invention. In the example shown in <FIG>, the initial blocks are first propagated per PSAP, per telecommunications provider and per agents, and the initial PSAPs capacity is thus propagated. Then, the policy rules and priorities for various events are calculated and stored in the database. The blockchain network now waits for incoming data and analyzes it continuously. If the policy rules and priorities are affected by incoming data and their processing, an update process is initiated. In a first step of the update process the affected blocks are marked and a break of existing policy chains occurs. Then the policy rules and priorities are recalculated and updated. Afterwards, the chain is moved in front of the disconnected block and an alternative blockchain transaction is selected. The emergency call is then diverted.

It is assumed that four PSAPs exist, located in the Unites States of America at different states: Florida, California, New York and Arizona. An extremist bomb attack occurs at the most overcrowded mall at New York City near the PSAP facilities while the monsoon period is at the same time and a serious tsunami has devasted a wide range of Miami. The New York PSAP needs to be evacuated immediately due to the risk of a second explosion in the nearby area. So, the vast amount of incoming emergency calls that report victims should be diverted to other PSAPs. Based on the existing policy rules, the candidate PSAP to receive the diverted calls is the Florida PSAP. However, Florida PSAP experience a high load of emergency calls. Based on the existing solution, if there is not any manual intervention to downgrade the priority of Florida PSAP and upgrade the priority of California PSAP, calls will arrive at the Florida PSAP increasing the call traffic and the waiting time to respond to emergency calls. At the same time Arizona's PSAP remains idle and California's PSAP receives low traffic even if it has high capacity by means of numerous call agents that could handle the waiting calls at Florida call queue.

Claim 1:
A method for retrieving and applying dynamic policy rules in a network, comprising the steps of:
- requesting, by one or more request client (<NUM>), one or more task, from a central unit (<NUM>) which is connected with a Policy Server (<NUM>) of a blockchain-based Policy Store Platform (<NUM>), by using a client application interface (<NUM>);
- transmitting, by the central unit (<NUM>), the one or more task to the Policy Server (<NUM>) and by indicating attributes concerning the one or more task;
- transmitting, by the Policy Server (<NUM>), the one or more task to a blockchain network (<NUM>) of the blockchain-based Policy Store Platform (<NUM>);
- analyzing, by a predictor component of the blockchain network (<NUM>), the one or more task with the attributes and retrieving stored data of blockchain-based policies in correlation with network capabilities which satisfy the one or more requested task attribute;
- forwarding, by the predictor component, as a result a list of blockchain policy rules that satisfy the one or more tasks to the Policy Server (<NUM>) in case blockchain policy rules are found to be satisfying;
- transmitting, by the Policy Server (<NUM>), the list of blockchain policy rules to one or more service client (<NUM>) and the one or more requesting client (<NUM>) using the client application interface (<NUM>) and the central unit (<NUM>);
- applying, by the central unit (<NUM>), the transmitted rules and routing the one or more task to the one or more service client (<NUM>).