Patent Description:
The present disclosure relates to wireless communications, and more particularly, to a method and system for securing networks of virtual wireless base stations.

The advent of pure software virtual wireless base stations holds the promise of vast flexibility and efficiencies, given that the virtual wireless base stations can be hosted on general-purpose server hardware, and that individual virtual wireless base stations can be instantiated and de-instantiated as network traffic demand increases and decreases. However, networks of virtual wireless base stations may incur certain vulnerabilities.

Potential vulnerabilities include the following: first, an intruder may instantiate a rogue wireless base station into the network and begin to demand resources, leading to a denial of service attack; second, an intruder may take control of an existing trusted wireless base station and attempt to alter parameters within it with the intent of harming the network; and third, an intruder may instantiate a copy of an existing trusted wireless base station, including its public/private key, and use this to harm the network. A denial of service attack may be an expected form of attempted harm, in which a fake, compromised, or copied wireless base station may attempt to obtain resources, such as authorization for connections, thereby draining the resources of the other (proper) wireless base stations in the network.

Accordingly, what is needed is a system and method for preventing these and other potential forms of threats to a network of virtual wireless base stations.

The concept of using blockchain technology to protect electronic transactions is known. It is further known to use this technology to electronically validate software licenses. An example of this is presented in "<NPL>. This publication proposes the utilization of a cryptocurrency blockchain similar to Bitcoin to provide decentralized, peer-to-peer, publicly auditable software license validation.

According to an aspect of the present disclosure, there is provided a system for protecting a network of virtual wireless base stations, comprising: a plurality of license servers, each of the license servers having a blockchain implementation; and a plurality of virtual wireless base stations, wherein each of the plurality of license servers is in communication with each of the plurality of virtual wireless basestations, and wherein the blockchain implementation of the license servers secures the network of virtual wireless base stations.

According to another aspect of the present disclosure, there is provided a method for initializing a secure wireless telecommunications network, comprising: instantiating a plurality of local license servers; exchanging a first PKI (Public Key Infrastructure) data between each of the plurality of local license servers and a master license server; registering each of the plurality of local license servers by exchanging a second PKI data between each of the plurality of local license servers; instantiating a plurality of virtual wireless base stations; registering each of the virtual wireless base stations by exchanging a third PKI data between each of the plurality of virtual wireless base stations and storing an IP address corresponding to each of the virtual wireless base stations; obtaining a plurality of connection licenses at the master license server; allocating the plurality of connection licenses amongst the plurality of local license servers, wherein each of the local license servers has a blockchain implementation; transmitting information relating to the plurality of allocated connection licenses to each of the plurality of local license servers; distributing the plurality of allocated connection licenses to the plurality of virtual wireless base stations, wherein the distributing includes generating a plurality of transactions; and appending an indication of each of the plurality of transactions to each blockchain implementation.

According to another aspect of the present disclosure, there is provided a method for securely distributing excess capacity within a wireless communications network, comprising: identifying an excess of capacity within a first virtual wireless base station; broadcasting a first message to a plurality of license servers indicating the excess of capacity, wherein each of the license servers has a blockchain implementation; verifying that the first virtual wireless base station has proper possession of the excess capacity; transmitting information relating to the excess capacity from the first virtual wireless base station; broadcasting a second message to the license servers indicating a change of ownership of the excess capacity; and appending the blockchain implementation corresponding to each of the plurality of license servers with a first new block indicating the change of ownership of the excess capacity.

According to another aspect of the present disclosure, there is provided a method for securely responding to a localized lack of capacity within a wireless communications network, comprising: identifying a lack of capacity within a first virtual wireless base station; broadcasting a first message to a plurality of license servers indicating the lack of capacity, wherein each of the license servers has a blockchain implementation; confirming an identity of the first virtual wireless base station; determining that one of the plurality of license servers has a sufficient capacity to meet the lack of capacity; transmitting information relating to the sufficient capacity to the first virtual wireless base station; broadcasting a second message to the license servers indicating a change of ownership of the excess capacity; and appending the blockchain implementation corresponding to each of the plurality of license servers with a first new block indicating the change of ownership of the excess capacity.

According to another aspect of the present disclosure, there is provided a method for securely responding to a localized lack of capacity within a wireless communications network, comprising: identifying a lack of capacity within a first virtual wireless base station; broadcasting a first message to a plurality of license servers indicating the lack of capacity, wherein each of the license servers has a blockchain implementation; confirming an identity of the first virtual wireless base station; determining that none of the plurality of license servers has a sufficient capacity to meet the lack of capacity; broadcasting a second message to a plurality of virtual wireless base stations, wherein the plurality of virtual wireless base stations does not include the first virtual wireless base station; receiving a positive response from a second virtual wireless base station within the plurality of virtual wireless base stations indicating that the second virtual wireless base station has an excess capacity equal to or greater than the lack of capacity; transmitting information relating to a response capacity from the second virtual wireless base station to the first virtual wireless base station; broadcasting a third message to the license servers indicating a change of ownership of the response capacity; and appending the blockchain implementation corresponding to each of the plurality of license servers with a final new block indicating the change of ownership of the response capacity.

According to another aspect of the present disclosure, there is provided a method for identifying and replacing a compromised virtual wireless base station in a telecommunications network, the method comprising: receiving an audit report from a virtual wireless base station, the audit report including a number of owned connection licenses; determining from a blockchain implementation a number of transacted connection licenses corresponding to the virtual wireless base station; identifying a discrepancy between the number of owned connection licenses and the number of transacted connection licenses; identifying from the blockchain implementation an identification number corresponding to each of the number of transacted connection licenses; instantiating a replacement virtual wireless base station; shutting down the virtual wireless base station; and transmitting the transacted connection licenses to the replacement virtual wireless base station.

According to another aspect of the present disclosure, there is provided a non-transitory memory encoded with machine readable instructions, which when executed by one or more processors, cause the one or more processors to perform a process for initializing a secure wireless telecommunications network, the process comprising: instantiating a plurality of local license servers; exchanging a first PKI (Public Key Infrastructure) data between each of the plurality of local license servers and a master license server; registering each of the plurality of local license servers with a bus master, wherein the registering each of the plurality of local license servers includes exchanging a second PKI data between each of the plurality of local license servers and the bus master; instantiating a plurality of virtual wireless base stations; registering each of the virtual wireless base stations with the bus master, wherein the registering each of the plurality of virtual wireless base stations includes exchanging a third PKI data between each of the plurality of virtual wireless base stations and the bus master, and storing an IP address corresponding to each of the virtual wireless base stations; obtaining a plurality of connection licenses from a master license server; allocating the plurality of connection licenses to each of the plurality of local license servers, wherein each of the local license servers has a blockchain implementation; transmitting the plurality of allocated connection licenses to each of the plurality of local license servers; distributing the plurality of allocated connection licenses to the plurality of virtual wireless base stations, wherein the distributing includes generating a plurality of transactions; and appending an indication of each of the plurality of transactions to each blockchain implementation.

According to another aspect of the present disclosure, there is provided a non-transitory memory encoded with machine readable instructions, which when executed by one or more processors, cause the one or more processors to perform a process for securely distributing excess capacity within a wireless communications network, the process comprising: identifying an excess plurality of connection licenses within a first virtual wireless base station; broadcasting a first message to a plurality of local license servers indicating the excess plurality of connection licenses, wherein each of the local license servers has a blockchain implementation; verifying that the first virtual wireless base station has proper possession of each of the excess plurality of connection licenses; identifying a broker local license server within the plurality of local license servers; transmitting the excess plurality of connection licenses from the first virtual wireless base station to the broker local license server; broadcasting a second message to the local license servers indicating a change of ownership of the excess plurality of connection licenses; and appending the blockchain implementation corresponding to each of the plurality of local license servers with a first new block indicating the change of ownership of the excess plurality of connection licenses.

According to another aspect of the present disclosure, there is provided a non-transitory memory encoded with machine readable instructions, which when executed by one or more processors, cause the one or more processors to perform a process for securely responding to a localized lack of capacity within a wireless communications network, the process comprising: identifying a need for one or more connection licenses within a first virtual wireless base station; broadcasting a first message to a plurality of local license servers indicating the need for one or more connection licenses, wherein each of the local license servers has a blockchain implementation; confirming an identity of the first virtual wireless base station; determining that one of the plurality of local license servers is able to provide a responsive one or more connection licenses; transmitting the responsive one or more connection licenses to the first virtual wireless base station; broadcasting a second message to the local license servers indicating a change of ownership of the responsive one or more connection licenses; and appending the blockchain implementation corresponding to each of the plurality of local license servers with a first new block indicating the change of ownership of the responsive one or more connection licenses.

According to another aspect of the present disclosure, there is provided a non-transitory memory encoded with machine readable instructions, which when executed by one or more processors, cause the one or more processors to perform a process for securely responding to a localized lack of capacity within a wireless communications network, the process comprising: identifying a need for one or more connection licenses within a first virtual wireless base station; broadcasting a first message to a plurality of local license servers indicating the need for one or more connection licenses, wherein each of the local license servers has a blockchain implementation; confirming an identity of the first virtual wireless base station; determining that none of the plurality of local license servers is able to provide a responsive one or more connection licenses; broadcasting a second message to a plurality of virtual wireless base stations, wherein the plurality of virtual wireless base stations does not include the first virtual wireless base station; receiving a positive response from a second virtual wireless base station within the plurality of virtual wireless base stations indicating that the second virtual wireless base station is able to provide the responsive one or more connection licenses; transmitting the responsive one or more connection licenses from the second virtual wireless base station to the first virtual wireless base station; broadcasting a third message to the local license servers indicating a change of ownership of the responsive one or more connection licenses; and appending the blockchain implementation corresponding to each of the plurality of local license servers with a final new block indicating the change of ownership of the responsive one or more connection licenses.

According to another aspect of the present disclosure, there is provided a non-transitory memory encoded with machine readable instructions, which when executed by one or more processors, cause the one or more processors to perform a process for identifying and replacing a compromised virtual wireless base station in a telecommunications network, the process comprising: receiving an audit report from a virtual wireless base station, the audit report including a number of owned connection licenses; determining from a blockchain implementation a number of transacted connection licenses corresponding to the virtual wireless base station; identifying a discrepancy between the number of owned connection licenses and the number of transacted connection licenses; identifying from the blockchain implementation an identification number corresponding to each of the number of transacted connection licenses; instantiating a replacement virtual wireless base station; shutting down the virtual wireless base station; and transmitting the transacted connection licenses to the replacement virtual wireless base station.

<FIG> illustrates an exemplary system <NUM> for securing a wireless communication network according to the disclosure. System <NUM> includes a plurality of virtual eNodeBs (Evolved Node Bs) <NUM>, each of which are coupled to a bus <NUM> that has a bus master <NUM>. Each virtual eNodeB <NUM> is a virtual base station which is software-implemented in a compute environment. Also coupled to bus <NUM> is a plurality of local license servers <NUM>, each of which are also coupled to a master license server <NUM>. Master license server <NUM> is further coupled to a license provider <NUM> over an internet connection <NUM>. Each virtual eNodeB <NUM> may be connected to a subset of a plurality of UEs <NUM>.

Each local license server <NUM> and the master license server <NUM> may have a blockchain implementation <NUM> for securing the network of virtual eNodeBs <NUM>. Each blockchain implementation <NUM> of system <NUM> may be a component within a distributed ledger system employing known technologies, but implemented to secure the network of virtual eNodeBs <NUM>. The master license server <NUM> may reside in the core network of a given network operator or in the network of an infrastructure provider. The local license servers <NUM> may be distributed throughout a region, such as a metropolitan area. Although three local license servers <NUM> are illustrated in system <NUM>, it will be understood that different numbers of local license servers <NUM> are possible and within the scope of the disclosure, preferably in an odd numbered quantity. Bus <NUM> may be a VPN (Virtual Private Network) or similar internet-based communication network. Bus master <NUM> may be deployed in a standalone server or may be deployed within a server hosting one of the local license servers <NUM>.

The local license servers <NUM> may be clustered in groups (not shown), which may correspond to a geographical area. Additionally, a given group of local license servers <NUM> may be defined such that given the hourly, weekly, and event-driven fluctuations in demand, the aggregate demand within a single group of local license servers <NUM> may remain substantially constant. In other words, a given group may encompass residential areas, office complexes, and one or more large venues (e.g., stadium, airport, campus, etc.).

As noted above, each virtual eNodeB <NUM> is a virtual base station which is software-implemented in a compute environment. The compute environment has hardware components including one or more processors and a non-transitory computer readable memory, and when configured with appropriate software the hardware components operate to implement the virtual eNodeB <NUM>. In some implementations, the software is stored in the non-transitory computer readable memory of the compute environment. In other implementations, the software is stored elsewhere, but executed in the compute environment, for example through an API (Application Programing Interface) provided by the compute environment. Each virtual eNodeB <NUM> has an eNodeB agent <NUM>, which may be a software module running on compute hardware dedicated to its corresponding virtual eNodeB <NUM>. As used herein, when a virtual eNodeB <NUM> is described as performing a function within system <NUM>, it will be understood that it may do so via its corresponding agent <NUM>. Further, each agent module <NUM> may be a standalone software entity from its corresponding virtual eNodeB <NUM>, or it may be integrated into the software of the virtual eNodeB <NUM>.

While the system <NUM> and the present disclosure as a whole may focus on systems having a network of virtual eNodeBs, it is to be understood that other virtual wireless base stations are possible and are within the scope of the disclosure. Embodiments of the disclosure are generally applicable to any suitable virtual wireless base station, such as a virtual LTE (Long-Term Evolution) eNodeB, a virtual <NUM> NR (New Radio) gNodeB, or a CU (Central Unit) or DU (Distributed Unit) of a virtual <NUM> gNodeB, for example. It will be understood that such variations are possible and within the scope of the disclosure.

For the purposes of this disclosure, a "virtual wireless base station" is a software-implemented base station in a compute environment. Although the compute environment can include some specialized hardware components, examples of which are described later, a virtual wireless base station remains at least partially software-based. As a result, a virtual wireless base station is generally capable of being remotely upgradeable or configurable. This is because it is possible to remotely upgrade or configure software. This is in contrast to a hardware-based base station, which is generally not capable of being remotely upgradeable or configurable. Instead, upgrading or configuring a hardware-based base station normally involves deployment of a person to physically modify or replace the hardware-based base station on site.

<FIG> illustrates an exemplary telecommunications network <NUM> in which system <NUM> is deployed. In addition to the components of system <NUM>, network <NUM> includes a plurality of local compute environments <NUM>, each hosting a plurality of virtual eNodeBs <NUM>. The other virtual eNodeBs hosted by compute environment <NUM> may correspond to other network operators or private networks. Also hosted on compute environment <NUM> is an orchestrator module <NUM>; and a fronthaul interface <NUM>, in addition to agent <NUM>. Each compute environment <NUM> may be coupled to one or more remote units <NUM> over a fronthaul connection <NUM>. Fronthaul interface <NUM> and fronthaul connection <NUM> may employ a CPRI (Common Public Radio Interface) or a packet-based protocol. Further, each virtual eNodeB <NUM> of a given network operator may be coupled to the network operator's core network <NUM> via backhaul interface connection <NUM>.

Orchestrator module <NUM> may perform the following functions: instantiate, de-instantiate and configure virtual eNodeBs <NUM>; coordinate communication between each virtual eNodeB <NUM> and the remote units <NUM> by configuring fronthaul interface <NUM>; and configure the remote units <NUM> for proper operation with each of the virtual eNodeBs <NUM>.

The disclosed exemplary system <NUM> distributes connection licenses from a license provider <NUM> to each of the virtual eNodeBs <NUM>, wherein each connection license may correspond to a single active connection between a given virtual eNodeB <NUM> and a connected UE <NUM>. The license may take the form of a "connection token" as described in co-owned <CIT>, SYSTEM AND METHOD FOR ADAPTIVELY TRACKING AND ALLOCATING CAPACITY IN A BROADLY-DISPERSED WIRELESS NETWORK.

The following is a brief explanation on the use of connection licenses. A given network operator pays an infrastructure provider for a subscription to a predetermined set of connection licenses. The license provider <NUM> transmits the connection licenses to master license server <NUM> over internet connection <NUM>. The local license servers <NUM> and virtual eNodeBs <NUM> may be dispersed over a broad geographical area, such as a metropolitan region, in which different areas (and thus different virtual eNodeBs <NUM>) experience alternating fluctuations in demand, depending on the day of the week, time of day, special events, etc. Under a connection license scheme, a network operator may buy a set number of connection licenses and distribute them to the different virtual eNodeBs <NUM>, via one or more local license servers <NUM>, according to the demand experienced by each virtual eNodeB <NUM>. This way, the network operator only pays for the active connections it uses and may shift its network capacity around to accommodate fluctuations in demand. Accordingly, the use of connection licenses is an example of how to represent network capacity, quantized as UE connections, either active connections (assigned connection licenses) or available connections (unassigned connection licenses).

Each connection license may include a license ID number and potentially additional parameters. Each connection may correspond to a single active UE connection, or to an aggregate (e.g., <NUM> or <NUM>) active UE connections. A connection license may have additional parameters in addition to the representation of an active connection. For example, a given license may include a parameter indicating a licensed high/low data rate. In this case, a high data rate license may apply to an active connection to a high speed camera or automotive control system, whereas a low data rate license may apply to an active connection to an IoT (Internet of Things) device, such as a water meter or temperature sensor. Further, there may be different types of licenses, such as the aforementioned connection licenses, and feature licenses, which may apply to a given virtual eNodeB <NUM>. A feature license may include a license to a specific Carrier Aggregation capability, CBRS (Citizens Broadband Radio Service) channel capability, EIRP (Effective Isotropic Radiated Power), higher order MIMO (Multiple-Input and Multiple-Output) capability, etc. The connection licenses and feature licenses may both be deployed in system <NUM> and managed under a single blockchain <NUM>. Alternatively, each local license server <NUM> may maintain two blockchains <NUM>, one for connection licenses and the other for feature licenses (not shown). It will be understood that such variations are possible and within the scope of the disclosure.

Each of the components within system <NUM> may comprise machine readable instructions that are encoded within one or more non-transitory memory devices and executed on one or more processors that perform their respective described functions. As used herein, "non-transitory memory" may refer to any tangible storage medium (as opposed to an electromagnetic or optical signal) and refer to the medium itself, and not to a limitation on data storage (e.g., RAM (Random Access Memory) vs. ROM (Read Only Memory)). For example, non-transitory medium may refer to an embedded volatile memory encoded with instructions whereby the memory may have to be re-loaded with the appropriate machine-readable instructions after being power cycled. Further, each of the components within system <NUM> may be deployed within its compute environment <NUM> using container technology.

In some implementations, each compute environment <NUM> includes a server, which may comprise one or more rack servers or blade servers, each of which may have multiple processor cores. Alternatively, instead of rack or blade servers, the compute environment <NUM> can include a server having a custom form factor and proprietary design. Regardless, the server of the compute environment <NUM> has one or more processor cores, which are coupled to one or more storage devices. The server is coupled to the Internet via an internet connection and a server network interface. The server may also have a fronthaul network interface card. If the fronthaul is implemented under the CPRI specification, then the fronthaul network interface card may be a PCIe (Peripheral Component Interconnect) board having circuitry that converts digital signal data to/from a CPRI format for transport over a fronthaul link. The server may further have hardware accelerator components, such as FPGAs (Field Programmable Gate Arrays) that are deployed on standard computer interface cards and programmed using well known IP (Intellectual Property) blocks to execute specific high speed computation for signal processing, as may be required.

Each of the steps of the processes below are described in exemplary terms as being performed by one or more components within system <NUM>. In doing so, it will be understood that where it states that a certain module (e.g., master license server <NUM>, local license server <NUM>, virtual eNodeB <NUM>, etc.) performs a certain task, it means that one or more processors within the respective compute environment of that module executes machine readable instructions for the given module to implement the process described.

<FIG> illustrates an exemplary process <NUM> for initializing system <NUM> according to the disclosure.

In step <NUM>, the processors of their respective compute environments instantiate master license server <NUM>, the local license servers <NUM> and their respective blockchains <NUM> (or initial elements thereof), and the virtual eNodeBs <NUM> including their agents <NUM>. Each of these modules then establish communications over their respective connections.

In step <NUM>, the master license server <NUM> establishes secure communications with each local license server <NUM> via an exchange of PKI (Public Key Infrastructure) information. In doing so, the local license servers <NUM> and the master license server <NUM> each generate their own public/private key pairs and exchange the public keys with each other, thereby establishing secure communications among the trusted components (master license server <NUM> and local license servers <NUM>).

In step <NUM>, each virtual eNodeB <NUM> registers itself with bus master <NUM>. In doing so, the bus master <NUM> and each of the virtual eNodeB <NUM> may exchange PKI information to establish secure communications as among trusted devices. Further to step <NUM>, the bus master <NUM> and each virtual eNodeB <NUM> may exchange PKI information to establish secure communications between the virtual eNodeBs <NUM> and the local license servers <NUM> as well as between each virtual eNodeB <NUM> and the other virtual eNodeBs <NUM> over the bus <NUM>. The result of this is that each of the virtual eNodeBs <NUM> has a trust relationship with each of the local license servers <NUM> and with the other virtual eNodeBs <NUM>. Further to step <NUM>, the bus master <NUM> may store the IP addresses of each of the trusted virtual eNodeBs <NUM> and local license servers <NUM> to provide additional security for situations described below.

In step <NUM>, the master license server <NUM> obtains an initial block of connection licenses from license provider <NUM>. In a variation, this may be a subset of the total intended set of connection licenses. Master license server <NUM> then allocates the obtained connection licenses to each local license server <NUM>. This may include creating a master table of connection licenses that maps each connection license to a destination local license server <NUM>. This master table may form the foundation or genesis block of the blockchain <NUM> within master license server <NUM>. In the case in which virtual eNodeB <NUM> features are also licensed, master license server <NUM> may create a second table for the feature licenses, along with the destination local license servers for those feature licenses, forming the foundation or genesis block of a second blockchain <NUM> for eNodeB features. Otherwise, if feature licenses are being used, they may be included in the master table along with the connection licenses.

In step <NUM>, the master license server <NUM> distributes the licenses to the local license servers <NUM>. In doing so, master license server <NUM> may transmit a copy of the master table generated in step <NUM> to each of the local license servers <NUM>. The master table received by each of the local licensed servers <NUM> identifies which local license server <NUM> is allocated which connection licenses. Further, the master table received by each local license server <NUM> may serve as the genesis block of its own blockchain <NUM>. Each local license server <NUM> may then allocate its designated connection licenses to each of its designated virtual eNodeBs <NUM> mapping its allocated connection licenses to its designated virtual eNodeBs <NUM>. The result is that each local license server <NUM> has an identical copy of the master table provided by the master license server, with its individual allocated connection licenses mapped to its designated virtual eNodeBs <NUM>.

In step <NUM>, at least one of the local licensing servers <NUM> distributes its connection licenses to the virtual eNodeBs <NUM>, according to a corresponding set of one or more of the agent modules <NUM> of the allocation it performed in step <NUM>. On receipt of its connection licenses, each virtual eNodeB <NUM> may store the allocated licenses in memory within its respective agent module <NUM>. In the case of a separate set of feature licenses, each virtual eNodeB <NUM> agent module <NUM> may store that information as well, which its corresponding virtual eNodeB <NUM> may use to configure itself for operating with the licensed features. On acceptance of its respective connection licenses, each virtual eNodeB <NUM> may generate and digitally sign a message about the successful transaction that it may then broadcast to the local license servers <NUM>. In response, each local license server <NUM> and the master license server <NUM> may append their own blockchains <NUM> with information regarding the successful transfer of ownership of each connection license, including the previous and new owners of the connection license. Accordingly, at the end of step <NUM>, each virtual eNodeB <NUM> has its intended connection licenses and may thus begin connecting to UEs <NUM>; and each of the local license servers <NUM> has an identical blockchain indicating the current state of ownership of each of the connection licenses obtained by the master license server <NUM> in step <NUM>. Each virtual eNodeB <NUM> may assign a given connection license to a given UE <NUM> when that UE <NUM> connects to the virtual eNodeB <NUM>. As this continues, agent <NUM> may designate assigned connection licenses as in use (assigned), and the remainder of its connection licenses as inactive or unassigned.

In an example, each local license server <NUM> distributes its connection licenses to a given cell within virtual eNodeB <NUM>, identified by the cell's ECGI (global cell ID). Alternatively, each receiving virtual eNodeB <NUM> may assign each connection license to a given cell.

Variations to the blockchains <NUM> are possible. For example, each block in the block chain <NUM> may contain a single connection license transaction. Alternatively, each block may contain all of the connection licenses within a given transaction involving a set of connection licenses. As an example of the latter case, if in step <NUM> a given local license server <NUM> provides a set of multiple connection licenses to a given virtual eNodeB <NUM>, the receiving virtual eNodeB <NUM> may transmit information about the change in ownership as a single transaction of the multiple connection licenses. In this case, each block in the blockchain <NUM> may be of different sizes, depending on the number of connection licenses in a given transaction. The same may be true of feature licenses, whereby a given virtual eNodeB may receive - and thus transmit information about - a set of multiple connection licenses as well as a set of eNodeB feature licenses (Carrier Aggregation, EIRP, CBRS channels, etc.) as a single transaction. It will be understood that such variations are possible and within the scope of the disclosure.

<FIG> illustrates an exemplary blockchain <NUM> according to the disclosure. Blockchain <NUM> has a master table 302a, which is provided to the local license server <NUM> by master license server <NUM> in step <NUM> above. Master table <NUM>(a) serves as the genesis block of blockchain <NUM>. The processor(s) hosting local license server <NUM> executes instructions to do the following: to store master table 302a, designating it as transaction zero (T<NUM>); and to compute the hash of master table 302a and store it as master table hash 302b. As each virtual eNodeB <NUM> receives connection licenses from local license servers <NUM>, it transmits information about the transaction to all of the local license servers <NUM> over bus <NUM>, each of which logs the transaction in its respective blockchain <NUM>. As illustrated, a transaction T<NUM> corresponds to the transfer of ownership of a single connection license "<NUM>" from local license server "<NUM>" to virtual eNodeB "<NUM>". Each local license server <NUM> executes instructions to store transaction T<NUM> as block 404a, and then computes a hash of the combination of the master table hash 402b and block 404a, thereby generating T<NUM> hash 404b. This continues for each individual connection license transaction, as illustrated.

<FIG> illustrates another exemplary blockchain <NUM> according to the disclosure. Blockchain <NUM> of <FIG> logs connection license transactions in blocks having multiple connection licenses in a single transaction. Accordingly, master table 302a and master table hash 302b may be the same as in the example of <FIG>. However, in this example, the distribution of connection licenses performed in step <NUM> above results in each virtual eNodeB <NUM> transmitting to all of the local license servers <NUM> information about it having gained ownership of a set of connection licenses, identifying the connection licenses by number. In this case, each local license server <NUM> executes instructions to create a single block for the given transaction in which virtual eNodeB's <NUM> takes ownership of the connection licenses in the transaction. In the example illustrated in <FIG>, all of the connection licenses transmitted from local license server <NUM> to virtual eNodeB "<NUM>" in step <NUM> are logged as a single transaction T<NUM> in a single block 320a. Local license server <NUM> then computes a hash of the combination of block 320a and master hash 302b to generate hash 320b. Similarly, all of the connection licenses obtained by virtual eNodeB "<NUM>" in step <NUM> are logged as transaction T<NUM> and given a block 322a, and local license server <NUM> computes a hash of the combination of block 322a and hash 320b to generate hash 322b. This process continues with each connection license acquisition by each virtual eNodeB <NUM>. Once all of the connection licenses have been distributed in step <NUM>, blockchain <NUM> of <FIG> then logs transactions in which a given virtual eNodeB obtains any number of connection licenses in a single transaction. This will be discussed further below.

<FIG> illustrates an exemplary blockchain <NUM>, in which the entire master table is copied in each block, and a given transaction is identified as a change in the appropriate entry/entries in the table, reflecting the change in ownership of one or more connection licenses.

Referring to the example of <FIG>, two different transactions showing change in ownership as shown. In transaction T<NUM>, as illustrated in block 342a, connection licenses "<NUM>" and "<NUM>" were respectively transferred from virtual eNodeB "<NUM>" and virtual eNodeB "<NUM>" to local license server "<NUM>" (entry <NUM>). Accordingly, block 342a lists local license server "<NUM>" as the owner of these connection licenses. Then in transaction T<NUM>, local license server "<NUM>" transferred these two connection licenses to virtual eNodeB "<NUM>" (entry <NUM>). As illustrated, each eNodeB-eNodeB connection license transfers takes place through a local license server <NUM>. An advantage to this approach is that, if during a connection license transaction, the destination virtual eNodeB <NUM> goes down, the connection licenses subject to the transaction are securely stored in a local license server <NUM>. A second similar transaction is illustrated in <FIG>, in which connection license "<NUM>" is transferred from virtual eNodeB "<NUM>" (block 342a) to local license server "<NUM>" (block 344a, entry <NUM>) to virtual eNodeB "<NUM>" (block 346a, entry <NUM>). The same approach may be taken with the example blockchains <NUM> of <FIG> and <FIG>, in which a given local license server <NUM> acts as an intermediary in an eNodeB-eNodeB transaction.

<FIG> illustrates an exemplary process <NUM> for securely redistributing an excess of unassigned connection licenses according to the disclosure. This situation might occur if a given virtual eNodeB <NUM>, which had previously experienced an abundance of UE <NUM> connection traffic, had many or most of those UE's subsequently disconnect. Examples of this situation might include an office building after evening rush hour, or stadium after a game.

In step <NUM>, a given virtual eNodeB <NUM> identifies an excess of unassigned connection licenses. As mentioned above, a given virtual eNodeB's agent <NUM> may maintain its allocated connection licenses in one of two states: assigned (to a UE <NUM>), or unassigned. Accordingly, agent <NUM> has ready access to information regarding whether it has a surplus of unassigned connection licenses. For example, agent <NUM> may be configured with a percentage threshold to determine whether it has an excess of unassigned connection licenses (e.g., <NUM>% unassigned may automatically imply an excess). Further to this, agent <NUM> may store historical information regarding UE connection traffic experienced by virtual eNodeB <NUM> as a function of day and time and may use this information to determine whether the virtual eNodeB <NUM> has excess connection licenses that it will not likely need within a reasonable time horizon. For example, agent <NUM> may have <NUM>% unassigned, but historical data indicates that at this day and time, a surge in demand is expected. An exemplary time horizon might be a <NUM>, <NUM>, or <NUM>-hour period in which it does not foresee an increase in demand for connections beyond the connection licenses it already has. Agent <NUM> may also perform a look-ahead function using one or more known algorithms for doing so. Further details and variations for this are described with regard to the "ACCS Client" described in aforementioned co-owned <CIT>.

The result of step <NUM> is that agent <NUM> of virtual eNodeB <NUM> determines that is has an excess of unassigned connection licenses and determines that it may return those excess connection licenses (also referred to as excess capacity) to the network.

Additionally, the virtual eNodeB <NUM> may employ mechanisms specified in 3GPP (3rd Generation Partnership Project) for determining demand, including setting a configurable threshold to send an alarm to agent module <NUM> if the demand has dropped below it (e.g., <NUM>% of configured maximum capacity, or a set number of connected UEs). This mechanism may use the standard PM-Stat files (Performance Measurement) that may be generated periodically and transmitted to the core network via a northbound interface (not shown) that is also specified by 3GPP. The PM-Stat file may be generated at different temporal granularities, e.g., every <NUM> minutes, <NUM> minutes, <NUM> minutes, or one hour, as specified in 3GPP TS <NUM>. Additionally, agent <NUM> may use the information generated in PM-Stat file for its historical usage data for performing look ahead functions and anticipating likely drops and surges in demand. It will be understood that such variations are possible and within the scope of the disclosure.

In step <NUM>, virtual eNodeB <NUM>, though its agent <NUM>, broadcasts over bus <NUM> to the local license servers <NUM> that it has excess capacity, i.e., an excess of connection licenses and/or unneeded feature licenses. This information may include the number of connection licenses, specific connection license numbers, and any features or capabilities corresponding to the licenses.

In step <NUM>, each local license server <NUM> executes instructions to verify that the broadcasting virtual eNodeB <NUM> is the owner of the licenses being offered. In doing so, each local license server <NUM> checks the digital signature of broadcasting virtual eNodeB <NUM>. Having verified the signature of the broadcasting virtual eNodeB <NUM>, each local license server <NUM> scans its blockchain <NUM> to identify the current owner of each of the connection licenses offered by the broadcasting virtual eNodeB <NUM>. This may be done on a connection license by connection license basis, by identifying the last transaction in its blockchain <NUM> in which each given connection license changed ownership. If the most recent transaction shows the broadcasting virtual eNodeB <NUM> to be the most recent recipient of a given connection license, ownership is confirmed.

However, if scanning the transaction record of blockchain <NUM> reveals that the last transaction for the given connection license indicates that a different virtual eNodeB <NUM> owns the connection license, then local license server <NUM> may terminate the transaction and gather information about the broadcasting virtual eNodeB <NUM> (including information like IP address, etc.) and issue an alert to master license server <NUM>. This may trigger an audit process, which is described further below.

Each of the local license servers <NUM> may execute step <NUM> in parallel. In a variation, the first local license server <NUM> to verify (or refute) ownership may broadcast this result to the other local license servers <NUM>, thereby potentially reducing the computational overhead of system <NUM> consumed in the verification process of step <NUM>.

Verification step <NUM> may be done in different ways. For example, the offering virtual eNodeB <NUM> may list the numbers of the connection licenses it is offering, and the local license servers may verify ownership as described above. Alternatively, the offering virtual eNodeB <NUM> may broadcast the quantity of connection licenses it is willing to give up. In this case, the local license servers <NUM> may parse through their respective blockchains <NUM> to determine how many connection licenses the offering virtual eNodeB <NUM> owns, and if the number of connection licenses being offered appears reasonable. In this case, 'reasonable' may mean that the number of connection licenses being offered is a certain percentage (e.g., less than <NUM>%) of the connection licenses owned, and no more. This applies in the case in which the offering virtual eNodeB <NUM> is intended to continue operation. If the offering virtual eNodeB <NUM> is about to be shut down, the <NUM>% reasonableness threshold may not apply, because the offering virtual eNodeB <NUM> would then be offering all of its connection licenses. It will be understood that such variations are possible and within the scope of the disclosure.

The next phase in the verification process is to determine that the transaction record has not been corrupted or hacked to show a fictitious ownership. This might occur whereby a malicious entity may have taken over the broadcasting virtual eNodeB <NUM> and seeks to disrupt the network by causing a double-spend of a set of connection licenses, whereby more than one copy of one or more connection licenses are introduced into system <NUM>.

One way to do this is verification for each local license server <NUM> to step one transaction back in its respective blockchain <NUM> from the transaction in which the broadcasting virtual eNodeB <NUM> took ownership of the connection license and obtain the hash value of the previous transaction, and then compute a new hash of the combination of the identified transaction and the previous transaction hash, and compare this to the hash value corresponding to the identified transaction.

Referring to the example blockchain <NUM> of <FIG> and <FIG>, in an example in which connection license "<NUM>" is one being offered up by broadcasting virtual eNodeB "<NUM>", the local license server <NUM> would identify block 312a/330a, corresponding to transaction TN in which virtual eNodeB "<NUM>" took ownership of connection license "<NUM>". To confirm that the block for transaction TN has not been hacked, local license server <NUM> may obtain the value for hash 310b/328b of previous transaction TN-<NUM>, combining it with the data of transaction TN 312a/330a, computing a new hash 312b/330b, and comparing new hash 312b/330b with pre-existing hash 312b/330b. If the new and preexisting hash values match, then the transaction was not altered. If the new and preexisting hash values do not match, then transaction TN block 312a/330a was altered. In this case, local license server <NUM> may terminate the transaction and issue an alert to master license server <NUM>.

This verification step would be substantially similar for blockchain <NUM> of <FIG>, in which local license server <NUM> verifies that virtual eNodeB "<NUM>" has possession of connection license "<NUM>". In this case, given that each block is a full table of connection license ownership, the local license server <NUM> can check the last block in the blockchain <NUM>. To check whether this ownership is invalid (the result of alteration of the record), local license server may go back through blockchain <NUM> to identify the first block in which virtual eNodeB "<NUM>" took possession of connection license "<NUM>" (not shown in <FIG>). Then, as with the examples for the blockchains of <FIG> and <FIG>, local license server may obtain the hash of the previous transaction to the one in which virtual eNodeB "<NUM>" took possession of connection license "<NUM>", combine it with the block in which virtual eNodeB "<NUM>" took possession of connection license "<NUM>", compute the hash of the combination, and compare this hash with the pre-existing hash. If they don't match, then the block in which virtual eNodeB "<NUM>" took possession of connection license "<NUM>" had been altered.

Another possible alteration is that a malicious player may have altered or removed a transaction in which the broadcasting virtual eNodeB <NUM> subsequently transferred the given license to another virtual eNodeB <NUM>, and now wants to represent that it still owns it. In this case, each local license server <NUM> may recompute the hashes from verified transaction 330a through to the end of block chain <NUM> and compare each to its corresponding pre-existing hash. If any subsequent transaction was altered or removed, the corresponding computed hash would not match its pre-existing counterpart hash. In this case the local license server <NUM> may terminate the transaction and issue an alert to the master license server <NUM>. This type of blockchain scan and verify may be done periodically as part of a regular audit process described further below.

With ownership of the offered connection licenses verified, process <NUM> may proceed to step <NUM>, in which one of the local license servers <NUM> designates itself as broker to the transaction for the offered connection licenses. In doing so, the broker local license server <NUM> may signal to the broadcasting virtual eNodeB <NUM> that it shall take ownership of the offered connection licenses.

Further to step <NUM>, the broadcasting virtual eNodeB <NUM> transmits the offered connection licenses to the broker local license server <NUM> over bus <NUM>.

In step <NUM>, each of the local license servers <NUM>, including broker local license server <NUM>, and master license server <NUM> append their respective blockchains <NUM> with an indication of the transaction to indicate the broker local license server <NUM> as the new owner of the offered connection licenses. Depending on the implementation of blockchain <NUM> described above (with reference to <FIG>), each local license server <NUM> may do so by appending their respective blockchains <NUM> with a plurality of blocks and corresponding hashes, one per connection license; a single block and corresponding hash, representing all the connection licenses in the transaction; or a single block with an updated copy of the master table, along with its corresponding hash, wherein the master table has been edited to show the broker local license server <NUM> as the new owner of the offered connection licenses.

Process <NUM> may be initiated and executed by a virtual eNodeB <NUM> that is in the process of being shut down or deactivated. Given that system <NUM> can accommodate software-based virtual eNodeBs <NUM>, there may be situations in which a mobile network may shut down one or more virtual eNodeBs <NUM> in response to a drop in demand. As mentioned before, an example may be an office complex after evening rush hour, or a stadium after a game. The ability of system <NUM> to dynamically redistribute connection licenses is one advantage of the present disclosure; another is the ability to enable the dynamic instantiating and de-instantiating of virtual eNodeBs <NUM>. If the given virtual eNodeB <NUM> is to be shut down, its orchestrator <NUM> may issue instructions to the remote units <NUM> to start powering down the one or more cells corresponding to this virtual eNodeB <NUM>. As the signal power of the virtual eNodeB <NUM> drops, the connected UEs <NUM> may identify alternate cells of other virtual eNodeBs <NUM> of system <NUM>. Each UE <NUM> may do so according to 3GPP-specified procedures. To facilitate this, orchestrator <NUM> may issue instructions for one or more other neighboring cells of other virtual eNodeBs <NUM> to ramp up its power, which may more assuredly trigger each UE <NUM> to jump off an onto the other virtual eNodeB <NUM> and provide coverage for these UEs <NUM>.

At the end of process <NUM>, the broker local license server <NUM> now has possession of the excess connection licenses offered by broadcasting virtual eNodeB <NUM>. Broker local license server <NUM> may subsequently redistribute some or all of the newly-acquired connection licenses to other virtual eNodeBs <NUM> in response to changes in demand for connectivity within system <NUM>.

<FIG> illustrates an exemplary process <NUM> by which a virtual eNodeB <NUM> in need of additional capacity in the form of connection licenses may obtain them through different sources within system <NUM>. Process <NUM> may be executed not only by an existing virtual eNodeB <NUM> that detects a current or pending shortage of connection licenses, it may also be executed by a newly instantiated virtual eNodeB <NUM> that has been added to the mobile network in anticipation of an increase in demand for connectivity. Examples of this might include an office complex before Monday morning rush hour, or a stadium before a major event.

In step <NUM>, a given virtual eNodeB <NUM> identifies a need for connection licenses. It may do so by performing analytics on stored data pertaining to historical demand fluctuation patterns, or it may extrapolate a detected trend increasing connectivity demand. Such look-ahead functions are discussed in co-owned <CIT>.

The anticipated shortfall in connection licenses may include factors such as types of connections (e.g. high/low data rate), and potentially a need for one or more feature licenses (e.g., for Carrier Aggregation or MIMO, etc.). Additionally, the virtual eNodeB <NUM> may employ 3GPP-specified mechanisms for determining demand, including setting a configurable threshold to send an alarm to agent module <NUM> if the demand has gone above it (e.g., <NUM>% of configured maximum capacity). This mechanism may use the standard PM-Stat files that are generated periodically and transmitted to the core network via a northbound interface (not shown) that is also specified by 3GPP. Further, agent <NUM> or orchestrator <NUM> may trigger the generation of a PM-Stat file, as mentioned above, as warranted. It will be understood that such variations are possible and within the scope of the disclosure.

In step <NUM>, virtual eNodeB <NUM> broadcasts a request for connection licenses to all of the local license servers <NUM>. The request may include the number of needed connection licenses and may include required data rates and/or one or more required eNodeB feature licenses.

In step <NUM>, each local license server <NUM> determines if it has sufficient connection licenses in its possession to be able to service the request from the requesting virtual eNodeB <NUM>. This may involve coordination among local license servers <NUM> to proportionally respond to the requesting virtual eNodeB <NUM>. If one or more of the local license servers <NUM> has sufficient available connection licenses to meet the demand of requesting virtual eNodeB <NUM>, process <NUM> may proceed to step <NUM>, in which the one or more local license servers <NUM> fulfill the demand.

In step <NUM>, if one local license server <NUM> has enough connection licenses to meet the request, it transmits the connection license information to the requesting virtual eNodeB <NUM> over bus <NUM>. If more than one local license server <NUM> are required to meet the request, one local license server <NUM> may designate itself as broker and coordinate the transfer of required connection licenses from the offering local license servers <NUM> to the requesting virtual eNodeB <NUM>. The broker local license servers <NUM> may coordinate the response whereby those local license servers <NUM> with a greater reserve of connection licenses may provide proportionally more connection licenses than those whose reserve is not as extensive. It will be understood that various approaches to this inter-server coordination are possible and within the scope of the disclosure. In the case of coordinated local license servers <NUM>, each may transit their respective connection licenses to the requesting virtual eNodeB <NUM> over bus <NUM>.

In step <NUM>, on receipt of the connection licenses from the one or more providing local license servers, the requesting virtual eNodeB <NUM> may broadcast information to the local license servers <NUM> over bus <NUM> indicating successful transition of ownership. In response, each local license server <NUM> may execute instructions to append one or more blocks to their respective blockchains <NUM> indicating change in ownership of the connection licenses, and performing the requisite hashes.

Returning to step <NUM>, if none of the local license servers <NUM> are able to service the request from requesting virtual eNodeB <NUM>, process <NUM> may proceed to step <NUM>, in which requesting virtual eNodeB <NUM> may broadcast a request over bus <NUM> to the other virtual eNodeBs <NUM> requesting a required number of connection licenses, and potentially their corresponding capabilities. In a variation, one of the local license servers <NUM> may designate itself as a broker and broadcast this message to the other virtual eNodeBs <NUM>.

In step <NUM>, if one or more of the virtual eNodeBs <NUM> responds over bus <NUM> indicating that it has available connection licenses, ("offering" virtual eNodeBs) it may respond to the requesting virtual eNodeB <NUM> (or to broker local license server <NUM>) that it has sufficient connection licenses to service the request. In a variation, more than one offering virtual eNodeBs <NUM> may coordinate in a response, in a process similar to the coordination done by the local license servers <NUM> in step <NUM>, with the broker local license server <NUM> performing the coordination. If the response is positive, process <NUM> proceeds to step <NUM>.

In step <NUM>, the one or more offering virtual eNodeBs <NUM> executes process <NUM> to transmit its available connection licenses to the designated broker local license server <NUM>.

In step <NUM>, the broker local license server <NUM> transmits the connection licenses received from the offering virtual eNodeBs <NUM> to the requesting virtual eNodeB <NUM>.

In step <NUM>, the requesting virtual eNodeB <NUM>, having received the connection licenses from broker local license server <NUM>, broadcasts information to the local license servers <NUM> over bus <NUM> indicating the change in ownership of the connection licenses. Each local license server <NUM> and the master license server <NUM> may update their respective blockchains <NUM> accordingly as described above.

Returning to step <NUM>, if none of the virtual eNodeBs <NUM> have available connection licenses to respond to requesting virtual eNodeB <NUM>, then process <NUM> may proceed to step <NUM>, in which broker local license server <NUM> may transmit a message to master license server <NUM> indicating that more connection licenses are needed.

In step <NUM>, master license server <NUM> may either allocate and distribute additional connection licenses to the local license servers <NUM> as done in step <NUM> and <NUM>. Alternatively, if master license server <NUM> does not have any additional pooled connection licenses, it may contact license provider <NUM> to request more connection licenses.

Variations to the above system and processes are possible. For example, master license server <NUM> may optionally not have a blockchain implementation <NUM>, in which case only the local license servers <NUM> coupled to bus <NUM> identify and log transactions in their respective blockchains <NUM> and synchronize among each other.

System <NUM> may offer a network operator the ability to flexibly add capability to its network if net network traffic increases to where various virtual eNodeBs <NUM> experience a simultaneous shortage of connection licenses. In this case, master license server <NUM> may notify license provider <NUM> to request and/or purchase additional connection licenses. The request may include further eNodeB capabilities encapsulated in feature licenses and/or capabilities tied to each connection license, such as data rate, etc. Once the master license server <NUM> has received the additional connection licenses, it may distribute them to the local license servers <NUM> according to step <NUM> in process <NUM>, after which each local license server <NUM> may further allocate and distribute the new connection licenses to virtual eNodeBs <NUM> according to step <NUM>. One distinction is that the master license server <NUM> may append its master table with the newly acquired connection licenses, whereas the local license servers might not append their respective master tables, but instead update their respective blockchains <NUM> once each virtual eNodeB <NUM> reports its successful acquisition of its new connection licenses. If the blockchain <NUM> implementation of <FIG> is deployed, wherein each block in the blockchain <NUM> is an updated copy of the original master table, then the latest block master table may be appended with the new connection licenses along with information identifying their new owners.

In an exemplary variation of system <NUM>, each local license server <NUM> may maintain a table of transactions, listing each connection license and its current owner. The table may also include a transaction number corresponding to the block in its blockchain <NUM> in which the owner (local license server <NUM> or virtual eNodeB <NUM>) took ownership of the given connection license. This variation may be implemented in conjunction with the blockchains illustrated in <FIG> and <FIG>. It would not be necessary for the implementation of <FIG> because the latest block in that blockchain <NUM> is an up-to-date list of each connection license and its current owner. In this example, each local license server <NUM> may update its table with each transaction that it appends to its blockchain <NUM>. Further, each local license server <NUM> may periodically confirm its table by comparing it to various blocks within its blockchain and confirming that the entry is correct, using a process substantially similar to the verification of ownership step <NUM> of process <NUM>. It will be understood that such variations are possible and within the scope of the disclosure.

Each of the transmissions or broadcasts described above may include a digital signature of the sending entity (e.g., local license server <NUM>, virtual eNodeB <NUM>, etc.), enabling the recipient to confirm that the sender is recognized and trusted. The use of PKI and digital signatures may prevent a malicious entity from, for example, introducing a new virtual eNodeB <NUM> or local license server <NUM> into system <NUM> with the intention of executing a denial of service attack by introducing false connection licenses and/or draining system <NUM> of connection licenses by attempting to perform process <NUM> using its intruding virtual eNodeB. However, the use of PKI and digital signatures might not protect system <NUM> from two other types of malicious attacks: copying a trusted virtual eNodeB <NUM>, including its PKI information; and hacking into and taking control of a trusted virtual eNodeB <NUM>.

In the former case in which a malicious entity makes a copy of an existing virtual eNodeB <NUM>, an intruder might be identified because even though the copied virtual eNodeB <NUM> may be identical to its original, its IP address will be different. In this case, bus master <NUM> may maintain a list of registered IP addresses (compiled in step <NUM> above) and may use this to confirm the identity of each of the trusted virtual eNodeBs <NUM> and local license servers <NUM>. This may enable detection of the copied virtual eNodeB <NUM> and prevent it from harming the system <NUM>. The same would be true if someone copied a local license server <NUM> for the purposes of disrupting the network of system <NUM>, given that the bus master <NUM> may maintain a list of the IP addresses of the local license servers <NUM> as well.

In the latter case, in which an entity hacks into and gains access to a virtual eNodeB <NUM>, this may be identified and caught by a periodic audit process of the virtual eNodeBs <NUM> (described below). A hacker might infiltrate an existing virtual eNodeB <NUM> to either disable or diminish the capability of the virtual eNodeB <NUM>, and/or to inflict harm on the broader network of system <NUM>. In the former case, in which the intruder seeks to disable or harm the particular virtual eNodeB <NUM>, the intruder might alter the connection license information in agent <NUM>, e.g., eliminate the capabilities of the connection licenses it has (e.g., make them all low data rate, or switch off licensed eNodeB features like Carrier Aggregation, CBRS, or MIMO); or the hacker might try to offload an inordinate number of connection licenses to disable a very active virtual eNodeB. In the latter case, the intruder may otherwise (or additionally) use its malicious control of a given virtual eNodeB <NUM> to harm the network of system <NUM>. For example, a hacker might request an inordinate number of connection licenses for itself, thereby denying them to the rest of system <NUM> (denial of service); or the hacker might try to release duplicate connection licenses into the network of system <NUM>.

A periodic audit procedure may help identify anomalies in system <NUM>, including those that might be due to an attack in which an intruder has taken control of a virtual eNodeB <NUM>.

<FIG> illustrates an exemplary process <NUM> for periodically auditing the virtual eNodeBs <NUM> according to the disclosure. Process <NUM> may be performed daily, weekly, and/or on an as-needed basis. Audit process <NUM> may preferably be performed during hours when network traffic is expected to be at its lowest, e.g., at <NUM>:00am.

In step <NUM>, each virtual eNodeB <NUM> broadcasts an audit report on bus <NUM> to the local license servers <NUM>. The audit report may include the number of connection licenses currently in possession of the broadcasting virtual eNodeB <NUM> and may further include the number of assigned (or unassigned) connection licenses among those currently in possession, along with their corresponding data rates (if applicable). The audit report may also include the numbers of each of its connection licenses. The audit report may further include the feature licenses in possession of the broadcasting virtual eNodeB <NUM>, which may include licensed MIMO, Carrier Aggregation, EIRP, and CBRS capabilities.

In step <NUM>, each local license server <NUM> reviews its respective blockchain <NUM> to determine the number of connection licenses the broadcasting virtual eNodeB <NUM> should have, based on recorded transactions. Depending on the specific blockchain implementation (e.g., <FIG>/B/C), this may involve either traversing the blockchain <NUM> or retrieving the information from the last block (<FIG>). Each local license server <NUM> may identify and store in temporary memory the ID number of each connection license determined to be in possession of the broadcasting virtual eNodeB <NUM>. This may include the transaction number. Each local license server <NUM> may perform this step to its completion. Otherwise, the first local license server <NUM> to complete the process may broadcast a notice to the other local license servers <NUM> indicating that they can stop. In this case, the local license server <NUM> that completed step <NUM> first may take control of further actions of process <NUM> regarding the broadcasting virtual eNodeB <NUM> as the auditing local license server <NUM>.

The local license servers <NUM> perform step <NUM> for each of the virtual eNodeBs <NUM>. Accordingly, different local license servers <NUM> will become the auditing local license server <NUM> for different virtual eNodeBs <NUM>.

In step <NUM>, the auditing local license server <NUM> determines if the number of owned connection licenses reported by broadcasting virtual eNodeB <NUM> matches the number determined by auditing local license server <NUM> in step <NUM>. If the numbers match, then process <NUM> proceeds to step <NUM>, in which auditing local license server <NUM> determines the number of assigned (or unassigned) connection licenses within the owned connection licenses. This is done to identify a situation in which a compromised virtual eNodeB <NUM> has been successfully taken over and has been requesting and receiving an inordinately large number of connection licenses from system <NUM>. A compromised virtual eNodeB <NUM> may repeatedly ask for connection licenses according to process <NUM>, thereby performing a denial of service attack by "draining" system <NUM> of connection licenses and thus hindering performance of the network of system <NUM>.

In step <NUM>, auditing local license server <NUM> may compare the ratio of unassigned to owned connection licenses. If the ratio is above a certain threshold (e.g., <NUM>%), then it may indicate that the broadcasting virtual eNodeB <NUM> may be "hoarding" connection licenses as part of a denial of service attack. In this case, the broadcasting virtual eNodeB <NUM> may be considered compromised. If the ratio is below this threshold, then the auditing license server <NUM> may terminate process <NUM>. Otherwise, process <NUM> proceeds to step <NUM>, described below.

Returning to step <NUM>, if the number of owned connection licenses reported by broadcasting virtual eNodeB <NUM> does not match the number determined by auditing local license server <NUM> in step <NUM>, then process <NUM> proceeds to step <NUM>. In this case, the broadcasting virtual eNodeB <NUM> is considered compromised.

In step <NUM>, local orchestrator module <NUM> corresponding to the compromised virtual eNodeB <NUM> instantiates a replacement virtual virtual eNodeB <NUM>. In doing so, the local orchestrator module <NUM> may employ container technology to instantiate the replacement virtual eNodeB <NUM>, which may include a plurality of (currently inactive) cells corresponding to the cells of the compromised virtual eNodeB <NUM>.

In step <NUM>, the local orchestrator module <NUM> may lock the cells of compromised virtual eNodeB <NUM>. This may involve the local orchestrator module <NUM> issuing instructions to the radio remote units <NUM> coupled to the compromised virtual eNodeB <NUM> to begin powering down. As each UE <NUM> connected to the compromised virtual eNodeB <NUM> detects a drop in signal power, it will identify another cell with a higher detected power level, whereby the other cell may be coupled to a non-compromised virtual eNodeB <NUM>. The connected UEs <NUM> may then issue instructions to connect to a stronger cell of the non-compromised virtual eNodeB <NUM> according to procedures defined in the 3GPP specification. Further to this, orchestrator module <NUM> may issue instructions to a neighboring virtual eNodeB <NUM> (or to the remotes <NUM> coupled to the neighboring virtual eNodeB <NUM>) to increase its power. The increased power in the neighboring virtual eNodeB <NUM>, once recognized by the UEs connected to the compromised virtual eNodeB <NUM>, may more assuredly cause the UEs connected to the virtual compromised eNodeB <NUM> to hand over to the neighboring virtual eNodeB <NUM>. Further to step <NUM>, orchestrator module <NUM> may issue instructions to the operating system of compute environment <NUM> to de-instantiate the container of the compromised virtual eNodeB <NUM>.

The result of step <NUM> is that each of the UEs <NUM> formerly connected to compromised virtual eNodeB <NUM> are now connected to one or more non-compromised virtual eNodeBs <NUM>.

In step <NUM>, local orchestrator module <NUM> activates the replacement virtual eNodeB <NUM>. It may do so by coupling each cell within the replacement virtual eNodeB <NUM> to the remote units <NUM> by configuring the fronthaul interface <NUM> to allocate CPRI slots for the cells of the replacement virtual eNodeB <NUM>, which may be the same slots previously used by the now locked compromised virtual eNodeB <NUM>. Orchestrator module <NUM> may issue commands to the remote units <NUM> coupled to replacement virtual eNodeB <NUM> to power back up to its original (and perhaps licensed) power level.

In step <NUM>, auditing local license server <NUM> transmits the connection licenses properly owned - as identified in step <NUM> - to the replacement virtual eNodeB <NUM> via agent <NUM>. At this stage, the UEs <NUM> formerly connected to compromised virtual eNodeB <NUM> may connect to replacement virtual eNodeB <NUM>. Once the replacement virtual eNodeB <NUM> has taken possession of the connection licenses, it may broadcast this information to the local license servers <NUM>, each of which may update their blockchains <NUM> accordingly.

Each of the local license servers <NUM> may have the appropriate software modules to support one or more consensus mechanisms for aligning their respective blockchains <NUM> to each other. In an example, at each audit interval, each local license server <NUM> may verify its blockchain <NUM> by recalculating each hash from the genesis block to the most recent transaction. The first local license server <NUM> to complete this calculation may broadcast a message to the other local license servers <NUM> indicating that it has finished. The remaining local license servers <NUM> may then verify the result of the first one competed. If they arrive at a consensus (e.g., ><NUM>% in agreement, or a much higher percentage threshold in case of a lower number of local license servers <NUM>) then the blockchain <NUM> of the first completed local license server <NUM> may be agreed upon as correct. At this point, all of the local license servers <NUM> may replace its blockchain <NUM> with the blockchain <NUM> of the verified first completed local license server <NUM>. For any local license server <NUM> whose blockchain calculation doesn't match that of the majority (outlier local license server <NUM>), Either one of the other local license servers <NUM> or the master license server <NUM> may verify the identity of the outlier local license server <NUM>. If the identity is verified, then the master license server <NUM> may send a copy of the verified blockchain <NUM> to the outlier local license server <NUM> as a replacement. Alternatively, master license server <NUM> may execute instructions to revoke any licenses currently owned by the outlier local license server <NUM> and shut it down (or otherwise lock it out of further processing). It will be understood that such variations are possible and within the scope of the disclosure.

Variations to connection license transactions are possible and within the scope of the disclosure. For example, instead of having all eNodeB-eNodeB transactions going through a local license server <NUM>, whereby the local license server becomes the temporary owner of the connection license that is subject to the transaction, the transmitting virtual eNodeB <NUM> may send the connection license directly to the receiving virtual eNodeB <NUM>. In this case, the transmitting virtual eNodeB <NUM> may broadcast to the local license servers <NUM> that it has transferred ownership of the connection license to the receiving virtual eNodeB <NUM>, and the receiving virtual eNodeB <NUM> may broadcast to the local license servers <NUM> that it has assumed ownership of the connection license from the transmitting virtual eNodeB <NUM>.

In a variation, once a virtual eNodeB <NUM> has taken possession of a connection license, its agent <NUM> may lock that connection for a predetermined period of time, which may be referred to as a locking duration. An example locking duration may be <NUM> hour and may be shorter or longer. The purpose of the locking duration is to prevent the traffic on bus <NUM> from becoming too "chatty", in which highly dynamic fluctuations in traffic demand may cause system <NUM> to become overloaded with excessive transactions on bus <NUM>. Given a specific locking duration, each agent <NUM> may compensate by using a look ahead function or a configured overhead margin to make sure that it will have enough connection licenses given a dampened transaction response time.

Claim 1:
A method for initializing a secure wireless telecommunications network, comprising the following steps:
instantiating a plurality of local license servers (<NUM>);
exchanging a first Public Key Infrastructure, PKI, data between each of said plurality of local license servers (<NUM>) and a master license server (<NUM>) to establish secure communications between said plurality of local license servers (<NUM>);
exchanging a second PKI data between each of said plurality of local license servers (<NUM>) and a bus master (<NUM>) to establish secure communications between each of said local license servers (<NUM>) and said bus master (<NUM>);
instantiating a plurality of virtual wireless base stations (<NUM>);
exchanging a third PKI data between each of said plurality of virtual wireless base stations (<NUM>) and said bus master (<NUM>); and storing at said bus master (<NUM>) an IP address corresponding to each of said virtual wireless base stations (<NUM>);
using said IP addresses for confirming the identity of the virtual wireless base stations (<NUM>) by said bus master (<NUM>);
obtaining a plurality of connection licenses at said master license server (<NUM>);
allocating said plurality of connection licenses amongst said plurality of local license servers (<NUM>), wherein each of the local license servers (<NUM>) has a blockchain implementation (<NUM>);
transmitting information relating to said plurality of allocated connection licenses to each of said plurality of local license servers (<NUM>);
distributing said plurality of allocated connection licenses to said plurality of virtual wireless base stations (<NUM>), wherein said distributing includes generating a plurality of transactions; and
appending an indication of each of said plurality of transactions to each blockchain implementation (<NUM>).