Technical Field of the Invention This disclosure relates to an apparatus and method for storing subscriber information for multiple communication networks, and in particular to storing subscriber information for multiple communication networks to enable performance information to be determined. Background of the Invention

For several future Internet of Things (loT) applications that transcend geographical boundaries, connectivity services cannot be offered by a single Mobile Network Operator (MNO). Instead, there will be multiple network operators providing connectivity services across geographical boundaries (e.g. across country borders). Atypical example of such application is autonomous vehicles that are communicating with cloud services. In this example, a vehicle may move between countries and coverage of a single operator. Roaming will allow the vehicle to maintain connectivity, as it is possible for the MNO offering the connectivity service to the vehicle owner (in this case vehicle owner can be the manufacturer or user of the vehicle). On the other hand, monitoring the quality of the connection is challenging as vehicles (also known as ‘mobile clients’ or User Equipment - UE), may roam across different network operators.

The Third Generation Partnership Project (3GPP) has introduced exposure services in form of network nodes that securely expose capabilities of the mobile network to third parties. For Long Term Evolution (LTE) networks, the node is known as a Service Capability Exposure Function (SCEF), whereas for 5 ^th Generation (5G) or New Radio (NR), the node is known as a Network Exposure Function (NEF). These functions are designed to interact with applications on one side (the so-called “northbound” interface), to which they expose the network capabilities, and with network nodes on the other side (the so-called “southbound” interface), from which they obtain information. In 3GPP TR 23.708 v13.0.0 (2015-06), “3GPP Technical Specification Group Services and System

Aspects; Architecture enhancements for service capability exposure” (Release 13), and 3GPP TS 23.222 v16.5.0 (2019-09), “3GPP Technical Specification Group Services and System Aspects; Functional architecture and information flows to support Common API Framework for 3GPP Northbound APIs; Stage 2” (Release 16), the concept of a “trust domain” is introduced for SCEF and NEF nodes respectively. The trust domain covers entities that are protected by adequate network domain security, and the entities and interfaces within the trust domain may all be within one operator's control, or some may be controlled by a trusted business partner which has a trust relationship with the operator e.g. another operator or a 3rd party. Trust domains can include other operators, meaning that operators can expose capabilities to third parties that involve other operators.

Fig. 1a corresponds to Figure 6.1.1.2-1 of TR 22 23.708 v13.0.0 and shows a Service Capability Exposure architecture. Fig. 1b corresponds to Figure 6.2.0-1 of TS 23.222 v16.5.0 and shows a functional model for the Common Application Program Interface (API) Framework (CAPIF) that includes a NEF, and in the case of 5G, 3GPP suggests the use of CAPIF for northbound API for Unified Data Management (UDM).

In both cases, when it comes to 3GPP NEF and SCEF nodes, it is possible for the trust domain to involve a “business partner”, the capabilities of which can be exposed to a third party via the exposure function. In this case the “third party” node is an Application Server (AS) or Application Function (AF) in 3GPP terms. However, in conventional approaches, MNOs need to engage manually in agreements with other MNOs in order to establish this trust domain. This is not only time consuming from a business perspective, but also from a technical perspective, as capability exposure systems of multiple MNOs need to be interconnected. Even if interconnectedness is achieved, the issue of accurate Key Performance Indicator (KPI) reporting from one or more MNOs still remains. That is, it is difficult for a MNO to determine KPIs for the subscribers to their network when the subscribers are being served by different communication networks.

Summary of the Invention

Certain aspects of the present disclosure and their embodiments may provide solutions to the above or other challenges. In particular apparatus and methods are provided that store subscriber information for multiple communication networks to enable performance information to be more easily determined.

According to a first aspect, there is provided a method of operating a control node. The method comprises storing a first distributed ledger that comprises subscriber information, wherein the subscriber information comprises information on subscribers connected to a first communication network that is operated by a first network operator and information on subscribers connected to a second communication network that is operated by a second network operator. The method also comprises receiving, from a third party node, a request for a first performance indicator, wherein the request identifies one or more subscribers that the first performance indicator is to relate to. The method also comprises identifying the respective communication networks that the one or more identified subscribers are connected to using the subscriber information stored in the first distributed ledger.

According to a second aspect, there is provided a method of operating a network node in a first communication network that is operated by a first network operator. The method comprises storing a first distributed ledgerthat comprises subscriber information, wherein the subscriber information comprises information on subscribers connected to the first communication network and information on subscribers connected to a second communication network that is operated by a second network operator. The method also comprises storing, in the first distributed ledger or in a second distributed ledger, trust information relating to a reliability of a value of a first performance indicator for one or both of the first communication network and the second communication network.

According to a third aspect, there is provided a method of operating a third party node. The method comprises sending trust information to a control node, wherein the trust information relates to a reliability of a value of a first performance indicator for one or both of a first communication network operated by a first network operator and a second communication network operated by a second network operator.

According to a fourth aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method according to the first aspect, the second aspect, the third aspect or any embodiments thereof.

According to a fifth aspect, there is provided a control node. The control node is configured to store a first distributed ledger that comprises subscriber information, wherein the subscriber information comprises information on subscribers connected to a first communication network that is operated by a first network operator and information on subscribers connected to a second communication network that is operated by a second network operator. The control node is also configured to receive, from a third party node, a request for a first performance indicator, wherein the request identifies one or more subscribers that the first performance indicator is to relate to. The control node is also configured to identify the respective communication networks that the one or more identified subscribers are connected to using the subscriber information stored in the first distributed ledger.

According to a sixth aspect, there is provided a network node for use in a first communication network that is operated by a first network operator. The network node is configured to: store a first distributed ledger that comprises subscriber information, wherein the subscriber information comprises information on subscribers connected to the first communication network and information on subscribers connected to a second communication network that is operated by a second network operator. The network node is also configured to store, in the first distributed ledger or in a second distributed ledger, trust information relating to a reliability of a value of a first performance indicator for one or both of the first communication network and the second communication network.

According to a seventh aspect, there is provided a third party node. The third party node is configured to send trust information to a control node, wherein the trust information relates to a reliability of a value of a first performance indicator for one or both of a first communication network operated by a first network operator and a second communication network operated by a second network operator.

According to an eighth aspect, there is provided a control node. The control node comprises a processor and a memory. The memory contains instructions executable by said processor whereby said control node is operative to store a first distributed ledger that comprises subscriber information, wherein the subscriber information comprises information on subscribers connected to a first communication network that is operated by a first network operator and information on subscribers connected to a second communication network that is operated by a second network operator. The control node is also operative to receive, from a third party node, a request for a first performance indicator, wherein the request identifies one or more subscribers that the first performance indicator is to relate to. The control node is also operative to identify the respective communication networks that the one or more identified subscribers are connected to using the subscriber information stored in the first distributed ledger.

According to a ninth aspect, there is provided a network node for use in a first communication network that is operated by a first network operator. The network node comprises a processor and a memory. The memory contains instructions executable by said processor whereby said network node is operative to store a first distributed ledger that comprises subscriber information, wherein the subscriber information comprises information on subscribers connected to the first communication network and information on subscribers connected to a second communication network that is operated by a second network operator. The network node is also operative to store, in the first distributed ledger or in a second distributed ledger, trust information relating to a reliability of a value of a first performance indicator for one or both of the first communication network and the second communication network. According to a tenth aspect, there is provided a third party node comprising a processor and a memory. The memory contains instructions executable by said processor whereby said third party node is operative to send trust information to a control node, wherein the trust information relates to a reliability of a value of a first performance indicator for one or both of a first communication network operated by a first network operator and a second communication network operated by a second network operator.

According to an eleventh aspect, there is provided a system comprising a control node according to the fifth aspect, the eighth aspect, or any embodiment thereof; and a network node in a first communication network that is operated by a first network operator, wherein the network node is according to the sixth aspect, the ninth aspect, or any embodiment thereof.

Brief Description of the Drawings

Various embodiments are described herein with reference to the following drawings, in which:

Fig. 1a shows a Service Capability Exposure architecture;

Fig. 1b shows a functional model for the CAPIF;

Fig. 2 is a block diagram illustrating various components of an exemplary system in which the techniques described herein can be implemented;

Fig. 3 is a block diagram of a control node according to various embodiments;

Fig. 4 is a block diagram of a network node according to various embodiments;

Fig. 5 is a block diagram of a third party node according to various embodiments;

Fig. 6 is a schematic block diagram illustrating a virtualisation environment in which functions implemented by some embodiments may be virtualised;

Fig. 7 is an illustration of an exemplary distributed ledger according to various embodiments;

Fig. 8 is a signalling diagram illustrating exemplary embodiments for subscription and asynchronous notification of KPIs;

Fig. 9 is a signalling diagram illustrating exemplary embodiments for updating exposure endpoints for subscribers;

Fig. 10 is a signalling diagram illustrating exemplary embodiments for unsubscribing from notifications of KPIs;

Fig. 11 is a signalling diagram illustrating exemplary embodiments of KPI report update functionality;

Fig. 12 is a flow chart illustrating an exemplary method of operating a control node according to general embodiments; Fig. 13 is a flow chart illustrating an exemplary method of operating a network node according to general embodiments; and

Fig. 14 is a flow chart illustrating an exemplary method of operating a third party node according to general embodiments.

Detailed Description of the Preferred Embodiments

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

Embodiments of this disclosure provide techniques for automating reporting of KPIs for a group of subscribers being served by multiple MNOs; thus reducing the business and technical debt required for the task of cross-MNO KPI monitoring. Particular embodiments provide a distributed ledger for storing information on subscribers connected to a first communication network operated by a first network operator or connected to a second communication network operated by a second network operator. A request can be received from a third party node for a performance indicator (KPI), with the request identifying one or more subscribers that the first performance indicator is to relate to. The subscriber information stored in the distributed ledger is used to identify the respective communication networks that the one or more identified subscribers are connected to. Certain embodiments provide that performance information relating to the first performance indicator is requested for the identified subscribers in the respective identified communication networks, and the first performance indicator is determined from the received performance information.

In some embodiments, techniques are provided that can filter out unreliable KPI reporting and allow for establishment of MNO trust domains, by means of verifying KPI reports from one MNO against similar KPI reports from other MNOs.

Embodiments of this disclosure can provide one or more of the following advantages. For example, reporting of KPIs from a centralised location can be enabled without the need to query each administrative domain (i.e. each MNO) separately. As another example, the simplified setup allows for quick bootstrapping of solutions, and can work with existing service exposure nodes, such as SCEF and NEF, without changes in the 3GPP standards, and does not need proprietary interfaces/implementation for cross-MNO communication. Another advantage is that residual audit trails of KPI reporting is provided due to immutability of the distributed ledger, can lead to identification of KPI misreporting. Another advantage is that this approach crowdsources the establishment of trust domains for multi-operator KPI reporting.

Fig. 2 is a block diagram illustrating various components of an exemplary system in which the techniques described herein can be implemented. Although Fig. 2 shows a system in which the techniques are applied to mobile communication networks, it will be appreciated that the techniques described herein can be applied to other types of communication network, such as wired communication networks, e.g. based on IEEE 802.3x (Ethernet) or Fiber Distributed Data Interface (FDDI). Fig. 2 shows three mobile communication networks, a first mobile communication network 201 that is operated by a first mobile network operator (‘MN01’), a second mobile communication network 203 that is operated by a second (different) mobile network operator (‘MN02’), and a third mobile communication network 205 that is operated by another mobile network operator (‘MNOx’). As used herein, the terms ‘mobile communication network’ and ‘mobile network operator (MNO)’ are used interchangeably (i.e. a MNO operates a respective mobile communication network), but it will be appreciated that in some scenarios, a single MNO may operate multiple distinct mobile communication networks.

Each of the mobile communication networks 201 , 203, 205 has an endpoint for securely exposing the capabilities of the respective network to third parties. These endpoints provide the northbound interface from the respective network, via which monitoring data can be provided. In this exemplary embodiment, the first mobile communication network 201 is a 4 ^th Generation (4G) network operating according to the LTE standards, and has an endpoint for exposing the capabilities of the first mobile communication network 201 in the form of a SCEF 207. Also in this exemplary embodiment, the second mobile communication network 203 is a 5G network operating according to the NR standards, and has an endpoint for exposing the capabilities of the second mobile communication network 203 in the form of a NEF 209. It will be appreciated that in alternative implementations, the first mobile communication network 201 and the second mobile communication network 203 can be any combination of 4G, 5G or subsequent generation networks (including being networks of the same type).

Each of the mobile communication networks 201 , 203, 205 has one or more nodes 211 , 213 for storing information relating to the subscribers to their network. In the case of the first mobile communication network 201 , as the network is a 4G/LTE network, the node 211 is a Home Subscriber Server (HSS) or a Home Location Register (HLR). In the case of the second mobile communication network 203, as the network is a 5G/NR network, the node 213 is a UDM node. A control node 215 is also provided that can operate according to some of the techniques described herein. The control node 215 is able to interface with each of the communication networks 201 , 203, 205, via the respective endpoint, i.e. via the SCEF 207 in the case of the first mobile communication network 201 and via the NEF 209 in the case of the second mobile communication network 203. The control node 215 may be external to each of the mobile communication networks, as shown in Fig. 2, or, in alternative implementations, it can be part of one of the mobile communication networks. The control node 215 can also communicate with one or more third party nodes 217. In accordance with embodiments herein, the third party node 217 can request the control node 215 provide a performance indicator for a set of subscribers to the mobile communication networks 201 , 203, 205, and the control node 215 can provide the performance indicator to the third party node 217. The control node 215 and third party node 217 may also undertake authorisation and/or authentication procedures.

In accordance with the techniques described herein, a distributed ledger 221 is provided for storing information on subscribers connected to any of the mobile communication networks. Thus, the distributed ledger 221 can store information on subscribers connected to the first mobile communication network 201 and subscribers connected to the second mobile communication network 203. In Fig. 2, each of the control node 215, the HSS/HLR 211 and the UDM 213 store a respective copy of the distributed ledger 221. The respective copies of the distributed ledger 221 stored by the control node 215, the HSS/HLR 211 and the UDM 213 are identical (i.e. they comprise the same information), and the synchronisation between the content of the respective copies is maintained using distributed ledger protocols/architecture known to those skilled in the art. In some embodiments, and as illustrated in Fig. 2, the distributed ledger 221 is in the form of, or comprises, one or more blockchains. The use of distributed ledger 221 means that no individual MNO or mobile communication network is responsible for subscriber data, but instead it is delegated to the MNO/mobile communication network collective.

The distributed ledger 221 is a data structure that abides to the principle of replicability; i.e. it is shared and synchronised across multiple entities - in the present case the control node 215 and all mobile communication networks/MNOs have an exact copy of the data stored in the distributed ledger 221. In addition, distributed ledgers are immutable - meaning that data cannot be removed from the ledger. This allows for the creation of “audit trails”, meaning that it is possible to trace actions on the distributed ledger 221 back in time to the point of origin. A distributed ledger structure is therefore well suited for performance indicator reporting purposes, as it offers transparency, and potential accountability/liability, of action of every MNO to all other MNOs.

Fig. 3 is a block diagram of a control node 301 according to various embodiments that can be used to implement the techniques described herein. It will be appreciated that the control node 301 may comprise one or more virtual machines running different software and/or processes. The control node 301 may therefore comprise one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes.

The processing circuitry 302 controls the operation of the control node 301 and can implement the methods described herein in relation to the control node. The processing circuitry 302 can comprise one or more processors, processing units, multicore processors or modules that are configured or programmed to control the control node 301 in the manner described herein. In particular implementations, the processing circuitry 302 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the control node.

In some embodiments, the control node 301 may optionally comprise a communications interface 303. The communications interface 303 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 303 can be configured to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar. The processing circuitry 302 may be configured to control the communications interface

303 of the control node 301 to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar.

Optionally, the control node 301 may comprise a memory 304. In some embodiments, the memory 304 can be configured to store program code that can be executed by the processing circuitry 302 to perform the method described herein in relation to the control node 301. Alternatively or in addition, the memory 304 can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 302 may be configured to control the memory

304 to store any requests, resources, information, data, signals, or similar that are described herein.

Fig. 4 is a block diagram of a network node 401 according to various embodiments that can be used to implement the techniques described herein. It will be appreciated that the network node 401 may comprise one or more virtual machines running different software and/or processes. The network node 401 may therefore comprise one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes.

The processing circuitry 402 controls the operation of the network node 401 and can implement the methods described herein in relation to the network node. The processing circuitry 402 can comprise one or more processors, processing units, multicore processors or modules that are configured or programmed to control the network node 401 in the manner described herein. In particular implementations, the processing circuitry 402 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the network node.

In some embodiments, the network node 401 may optionally comprise a communications interface 403. The communications interface 403 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 403 can be configured to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar. The processing circuitry 402 may be configured to control the communications interface

403 of the network node 401 to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar.

Optionally, the network node 401 may comprise a memory 404. In some embodiments, the memory 404 can be configured to store program code that can be executed by the processing circuitry 402 to perform the method described herein in relation to the network node 401. Alternatively or in addition, the memory 404 can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 402 may be configured to control the memory

404 to store any requests, resources, information, data, signals, or similar that are described herein.

Fig. 5 is a block diagram of a third party node 501 according to various embodiments that can be used to implement the techniques described herein. It will be appreciated that the third party node 501 may comprise one or more virtual machines running different software and/or processes. The third party node 501 may therefore comprise one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes.

The processing circuitry 502 controls the operation of the third party node 501 and can implement the methods described herein in relation to the network node. The processing circuitry 502 can comprise one or more processors, processing units, multicore processors or modules that are configured or programmed to control the third party node 501 in the manner described herein. In particular implementations, the processing circuitry 502 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the third party node.

In some embodiments, the third party node 501 may optionally comprise a communications interface 503. The communications interface 503 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 503 can be configured to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar. The processing circuitry 502 may be configured to control the communications interface

503 of the third party node 501 to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar.

Optionally, the third party node 501 may comprise a memory 504. In some embodiments, the memory 504 can be configured to store program code that can be executed by the processing circuitry 502 to perform the method described herein in relation to the third party node 501. Alternatively or in addition, the memory 504 can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 502 may be configured to control the memory

504 to store any requests, resources, information, data, signals, or similar that are described herein.

Fig. 6 is a schematic block diagram illustrating a virtualisation environment 600 in which functions implemented by some embodiments may be virtualised, such as functions of any of the control node 215/301 , the network node 401 such as an HSS/HLR 211 or UDM 213, and/or the third party node 217/501. In the present context, virtualising means creating virtual versions of apparatuses or devices which may include virtualising hardware platforms, storage devices and networking resources. As used herein, virtualisation can be applied to a control node, a network node and a third party node, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines or containers executing on one or more physical processing nodes in one or more computer networks).

In some embodiments, some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments 600 hosted by one or more hardware nodes 630. The functions of any of the control node 301 , the network node 401 such as an HSS/HLR 211 or UDM 213, and/or the third party node 501 as described herein, may be implemented by one or more applications 620 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operative to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein. Applications 620 are run in virtualisation environment 600 which provides hardware 630 comprising processing circuitry 660 and memory 690. Memory 690 contains instructions 695 executable by processing circuitry 660 whereby application 620 is operative to provide one or more of the features, benefits, and/or functions disclosed herein.

Virtualisation environment 600, comprises general-purpose or special-purpose network hardware devices 630 comprising a set of one or more processors or processing circuitry 660, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or special purpose processors. Each hardware device may comprise memory 690-1 which may be non-persistent memory for temporarily storing instructions 695 or software executed by processing circuitry 660.

Each hardware device may comprise one or more network interface controllers (NICs) 670, also known as network interface cards, which include physical network interface 680. Each hardware device may also include non-transitory, persistent, machine-readable storage media 690-2 having stored therein software 695 and/or instructions executable by processing circuitry 660. Software 695 may include any type of software including software for instantiating one or more virtualisation layers 650 (also referred to as hypervisors), software to execute virtual machines 640 as well as software allowing it to execute functions, features and/or benefits described in relation with some embodiments described herein.

Virtual machines 640, comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualisation layer 650 or hypervisor. Different embodiments of the instance of virtual appliance 620 may be implemented on one or more of virtual machines 640, and the implementations may be made in different ways.

During operation, processing circuitry 660 executes software 695 to instantiate the hypervisor or virtualisation layer 650, which may sometimes be referred to as a virtual machine monitor (VMM). Virtualisation layer 650 may present a virtual operating platform that appears like networking hardware to virtual machine 640. As shown in Figure 6, hardware 630 may be a standalone network node with generic or specific components. Hardware 630 may be part of a larger cluster of hardware (e.g. such as in a data centre or customer premise equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) 6100, which, among others, oversees lifecycle management of applications 620.

Virtualisation of the hardware is in some contexts referred to as network function virtualisation (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

In the context of NFV, virtual machine 640 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non- virtualised machine. Each of virtual machines 640, and that part of hardware 630 that executes that virtual machine, be it hardware dedicated to that virtual machine and/or hardware shared by that virtual machine with others of the virtual machines 640, forms a separate virtual network elements (VNE).

Still in the context of NFV, Virtual Network Function (VNF) is responsible for handling specific network functions that run in one or more virtual machines 640 on top of hardware networking infrastructure 630 and corresponds to application 620 in Fig. 6.

Thus, in the context of the techniques described herein, and with reference again to Fig. 2, there are three main types of entities that can provide the described performance indicator reporting. A control node 215/301 , a network node 211/213/401 such as a HSS/HLR node 211 or UDM 213, and a third party node 217/501.

The third party node 217 can be a subscriber to a network, for example an enterprise with many mobile subscriptions or a private individual, that may request the monitoring of one or more KPIs for their subscriber(s)/UEs. This can be done via a control node-third party (CN-TP) interface between the third party node 217 and the control node 215. This is a publish-subscribe type of interface, where the third party node 217 subscribes to one or more events, such as monitoring events defined by 3GPP standards, and receives an asynchronous notification when these events happen. In the context of the techniques described herein, these events are KPIs, or information relating to KPIs.

The request for subscribing to one or more events (KPIs) contains identifiers for one or more subscriptions that the event relates to. In some embodiments, the identifiers are International Mobile Subscriber Identifiers (IMSIs), but other types of identifiers can be used, in particular in different types of communication network. These identifiers are used by for control node 215 to determine which wireless device(s)/mobile device(s)/UE(s) that they need to offer monitoring information on. The KPI may be a single event, or a combination of events, provided by a “monitoring” functionality of the relevant endpoint 207, 209 (exposure function). For example the monitoring functionality can relate to any of loss of connectivity, reachability, location, communication failure, roaming status, etc. In some embodiments, information about which event(s) to receive notifications for can also be included in the request. The response may be asynchronous (i.e. the response occurs some time later when information is available, and not just as a reaction to receiving the request) and contains information about the event(s) that have been triggered.

The control node 215 acts as a mediator between the third party node 217 and the exposure functions 207, 209 of the mobile communication networks 201 , 203. One optional function of the control node 215 is to authenticate the third party node 217 to enable access to information provided by the exposure functions 207, 209. Another function of the control node 215 is to subscribe to events on behalf of the third party node 217 and notify the third party node 217 when data is available for the event that the third party node 217 requested. In this way, the third party node 217 (or the subscriber/owner of the third party node 217) does not need to interface with mobile communication networks 201 , 203 or MNOs directly, nor does it need to be aware to which MNO its subscribers/UEs are connected or attached to.

The control node 215 is a logical entity, which means that it can be a single point of contact and either reside within one of the mobile communication networks 201 , 203 of one of the MNOs, or be cloud service that is hosted in an external data centre. In some embodiments, the distributed ledger 221 stores access information, such as the Uniform Resource Identifier (URI)-based address, port, etc., for the endpoint/exposure function 207, 209 of each MNO/mobile communication network, as well as subscriber information. The single point of contact arrangement is shown in Fig. 2, and this configuration is more likely to be the case for local deployments, and can involve both MNOs and Mobile Virtual Network Operators (MVNOs).

In an alternative approach, the control node 215 can be distributed across multiple MNOs 201, 203, meaning that every MNO 201 , 203 has their own copy of the control node 215. In this configuration the request/response workload and throughput are distributed across multiple MNOs 201 , 203. This approach is more likely for global deployments.

Finally, the MNOs 201 , 203 participate in the techniques described herein via their endpoint node (exposure function node) 207, 209, and mobile subscriber database (HSS/HLR 211 in LTE and UDM 213 in 5G). Typically, these databases are restricted to the domain of the MNO 201 , 203 that owns them. A key difference is that in the present disclosure, part of the information typically stored in a subscriber database is also stored in distributed ledger 221 , meaning that subscriber information is accessible by every MNO that has access to the distributed ledger 221.

An exemplary distributed ledger 700 comprising several blockchains (or sub- blockchains) according to various embodiments is shown in Fig. 7. Specific implementations of the distributed ledger 700 may include any or all of the illustrated layers, and/or any of the illustrated blockchains/sub-blockchains. Likewise, specific implementations of the distributed ledger 700 may include any or all of the types of information shown within each block of the blockchains/sub-blockchains.

Thus, the distributed ledger 700 shown in Fig. 7 comprises three layers, a first layer 701 that stores information about the MNOs/mobile communication networks that are participating in the distributed ledger 700, a second layer 702 that stores information about the subscribers connected to each of the mobile communication networks 201 , 203, 205, and a third layer 703 that can store information relating to the reporting of performance indicators. Each layer includes or comprises one or more blockchains. The third layer 703, in particular, is optional, and in certain embodiments is not present. The first layer 701 is also referred to herein as the “MNO General Information layer” or the “MNO information layer” or “Layer 1 ”. The second layer 702 is also referred to herein as the “ I M S I Activation and Deactivation layer” or the “subscriber information layer” or “Layer 2”. The third layer 703 is also referred to herein as the “KPI Reporting layer” or “Layer 3”.

The first layer 701 (MNO General Information layer) can contain general information about the network operators. In some embodiments, the first layer 701 is a blockchain and the information for each network operator/communication network can be stored in a respective block of the Layer 1 blockchain 701. The Layer 1 blockchain 701 is also referred to herein as a “network information blockchain”. The information for each network operator/communication network can be provided by the respective network operator/communication network. In the example of Fig. 7, a first block 711 stores first network information, which is information for a first MNO/first mobile communication network, and a second block 712 stores second network information, which is the information for a second MNO/second mobile communication network. Information for further MNOs/mobile communication networks will be stored in respective further blocks of the Layer 1 blockchain 701. Each block includes one or more data fields for storing particular information about the respective MNO/mobile communication network. The second block 712, and subsequent blocks, each contain a data field 713 that is a hash of the previous block in the Layer 1 blockchain 701 (thereby creating the blockchain).

Each block 711 , 712 in the first layer 701 comprises information about the respective network operator/communication network. This information can comprise any of: a network identifier, for example a 3GPP unique Home Network Identifier (HNI); information for an endpoint of the network, for example the service exposure endpoint (which can be a combination of an IP address, a port, and protocol to interface with SCEF/NEF node of the respective MNO); and a range of subscriber identities the operator/network is responsible for, such as an IMSI Range which is a range of IMSIs. There may also be a “type” data field, which denotes the type of the entry for the respective operator: if it is the first entry of the operator in the blockchain 701 then the type is set to “new”, if it is a subsequent update (of any or a combination of service exposure endpoint and IMSI range(s)) then the type can be set to “update”. Each block 711 , 712 can also include a header field that is used to store information that can identify the block.

In the exemplary embodiment shown in Fig. 7, each block 711, 712 in the first layer 701 can also comprise one or more data fields 714, 715 that provide a ‘pointer’ to the relevant information for the respective network stored in the second layer 702 (IMSI Activation and Deactivation layer) and/or the third layer 703 (KPI Reporting). That is the information in data fields 714, 715 can indicate which block or blockchain in the second layer 702 or the third layer 703 includes the information for the respective mobile communication network. Data field 714 provides a pointer to the relevant KPI reporting information for the respective mobile communication network in the third layer 703 and data field 715 provides a pointer to the relevant subscriber information for the respective mobile communication network in the second layer 702.

The second layer 702 (IMSI Attach/Detach layer) stores information about the subscribers connected to each of the mobile communication networks 201 , 203, 205. In particular, the second layer 702 stores information about any subscribers connected (or attached) to a particular mobile communication network, and may also store information about subscribers that have disconnected (or detached) from the particular mobile communication network. It will be appreciated that due to the possibility of roaming between networks, the subscribers attached to a particular mobile communication network may include subscribers of other network operators. In other words, the subscribers connected to a particular mobile communication network may include subscribers with identities not in the IMSI range of that mobile communication network. The subscriber information for each network operator/communication network can be provided by the respective network operator/communication network.

In this exemplary embodiment the second layer 702 comprises a respective Layer 2 blockchain or sub-blockchain for each of the MNOs that has a respective block in the first layer 701. Thus, the second layer 702 comprises a first Layer 2 blockchain 721 that includes the information for subscribers connected to the first mobile communication network 201 , and a second Layer 2 blockchain 722 that includes the information for subscribers connected to the second mobile communication network 203. The subscriber information contained in each block of the Layer 2 blockchains 721 , 722 can be in the form of a list of subscriber identifiers that are connected to and/or disconnected from the respective network.

The first Layer 2 blockchain 721 comprises at least a first block 723. In embodiments where the first block 711 in the first layer 701 includes a pointer in data field 715, the pointer can indicate or ‘point to’ the first block 723 in the first Layer 2 blockchain 721. The first block 723 in the first Layer 2 blockchain 721 can include a first list of subscriber identifiers for subscribers connected to the first mobile communication network 201. If the subscriber information for the first mobile communication network 201 is to be updated, a further block is added to the first Layer 2 blockchain 721 containing the updated information. This updated information can be in the form of an updated list of connected and/or disconnected subscribers for the first mobile communication network 201. Thus, in the illustrated example there is also a second block 724 in the first Layer 2 blockchain 721. The second block 724, and subsequent blocks, each contain a data field 725 that is a hash of the previous block in the first Layer 2 blockchain 721 (thereby creating the blockchain). Each block includes a data field 726 with a list (or updated list) of subscribers that are connected (attached) to the first mobile communication network 201. Each block may include a list (or updated list) of subscribers that are disconnected (detached) from the first mobile communication network 201. This list may be stored in the same or a different data field 726 to the list of connected subscribers. In some embodiments, the list of connected subscribers stored in each block 723, 724 can include all subscribers that are connected to the first mobile communication network 201. This embodiment can improve the speed with which a status of a particular subscriber can be determined in subsequent steps of the techniques described herein as only the latest block of the blockchain needs to be queried. However, this can result in each block being quite large in terms of data size. Therefore in alternative embodiments, to reduce the size of the list stored in each block 723, 724, each block 723, 724 may only store information on subscribers that have connected to the first mobile communication network 201 since the previous block and/or disconnected from the first mobile communication network 201 since the previous block.

Each block 723, 724 can include a header field that is used to store information that can identify the block. Each block 723, 724 can include a timestamp field that is used to store a timestamp for that particular block. The timestamp is typically the time (e.g. date and time) that the respective block was added to the first Layer 2 blockchain 721.

As noted, the second Layer 2 blockchain 722 includes the information for subscribers connected to (and disconnected from) the second mobile communication network 203. The second Layer 2 blockchain 722 has a similar structure to the first Layer 2 blockchain 721 , and thus includes a first block 723, a second block 724, etc. The first block 723 in the second Layer 2 blockchain 722 can include a second list of subscriber identifiers for subscribers connected to the second mobile communication network 203. Thus the various embodiments described above for the blocks in the first Layer 2 blockchain 721 can also apply to the second Layer 2 blockchain 722. In embodiments where the second block 712 in the first layer 701 includes a pointer in data field 715, the pointer can indicate or ‘point to’ the first block 723 in the second Layer 2 blockchain 722.

The third layer 703 (KPI Reporting layer) stores information relating to the reporting of performance indicators about the subscribers connected to each of the mobile communication networks 201 , 203, 205. As noted, the third layer 703, and the information stored therein, is optional. The information stored in the third layer 703 can help to establish a trust domain across the MNOs participating in the distributed ledger 700, and thus the information stored in the third layer 703 can also be referred to herein as ‘trust information’. In some embodiments, the performance information can relate to a reliability of a value of a performance indicator provided by the first communication network 201 and/or the second communication network 203. In some embodiments, the performance information stored in the third layer 703 can be received from the third party node 217.

In this exemplary embodiment the third layer 703 comprises a respective Layer 3 blockchain or sub-blockchain for each of the MNOs that has a respective block in the first layer 701. Each Layer 3 blockchain can be referred to as a “trust information blockchain”. Thus, the third layer 703 comprises a first Layer 3 blockchain 731 that includes the performance indicator information for subscribers connected to the first mobile communication network 201 , and a second Layer 3 blockchain 732 that includes the performance indicator information for subscribers connected to the second mobile communication network 203. The first Layer 3 blockchain 731 comprises at least a first block 733. In embodiments where the first block 711 in the first layer 701 includes a pointer in data field 714, the pointer can indicate or ‘point to’ the first block 733 in the first Layer 3 blockchain 731. Any time that the performance information for the first mobile communication network 201 is to be updated, a further block is added to the first Layer 3 blockchain 731 containing the updated performance information. Thus, in the illustrated example there is also a second block 734 in the first Layer 3 blockchain 731. The second block 734, and subsequent blocks, each contain a data field 735 that is a hash of the previous block in the first Layer 3 blockchain 731 (thereby creating the blockchain). Each block includes a data field 736 with performance information (e.g. a KPI report) for the first mobile communication network 201.

Each block 733, 734 can include a header field that is used to store information that can identify the block. Each block 733, 734 can include a timestamp field that is used to store a timestamp for that particular block. The timestamp is typically the time (e.g. date and time) that the respective block was added to the first Layer 3 blockchain

731.

As noted, the second Layer 3 blockchain 732 includes the performance information for the second mobile communication network 203. The second Layer 3 blockchain 732 has a similar structure to the first Layer 3 blockchain 731 , and thus includes a first block 733, a second block 734, etc. Thus the various embodiments described above for the blocks in the first Layer 3 blockchain 731 can also apply to the second Layer 3 blockchain

732. In embodiments where the second block 712 in the first layer 701 includes a pointer in data field 714, the pointer can indicate or ‘point to’ the first block 733 in the second Layer 3 blockchain 732.

As noted above, the data structure of the distributed ledger 700 shown in Fig. 7 is merely exemplary, and it will be appreciated by those skilled in the art that the described information can be stored in a number of different ways in distributed ledger 700. Determining the data structure to use in particular implementation may be a trade-off between the data size of individual blocks and the speed with which required information can be retrieved from the distributed ledger 700. For example, to minimise the data size of individual blocks, each block may only include information that has changed since the previous block or an earlier block. As noted above, this can be applied to the subscriber information, and each block may only include information for subscribers for which their connection status has changed. However, the trade-off with minimising the data size of blocks is that it may be necessary to examiner multiple blocks in a blockchain to find the relevant information. On the other hand, if each block includes all available information, including information that has not been updated from a previous block, block sizes may become quite large, but it may only be required to examine the most recent block in the blockchain to find the relevant information.

In some alternative embodiments, one or more layers of the multi-layer structure shown in Fig. 7 can be omitted, or the information contained in the different layers combined into a single layer. In some alternative embodiments, each layer may comprise a single blockchain with each block including the information (updated or complete, depending on the implementation) relating to all of the MNOs/mobile communication networks. In some alternative embodiments, the distributed ledger 700 does not use blockchains to store the information, and an alternative data structure can be used. For example the distributed ledger can be in the form of one or more distributed hash tables (DHTs).

In some embodiments, the control node 215 (and in some embodiments only the control node 215) is responsible for adding new blocks to the various blockchains in the distributed ledger 700. As noted, the mobile communication networks 201 , 203 each store a local copy of the distributed ledger 700, and the distributed ledger architecture ensures that the local copies of the distributed ledger 700 in the first mobile communication network 201 and the second mobile communication network 203 are kept aligned or synchronised as new blocks are added by the control node 215. For example the control node 215 can receive updated subscriber information from the first mobile communication network 201 , and add a new block to the first Layer 2 blockchain 721 that includes the updated subscriber information. The local copies of the distributed ledger 700 will then be updated to include a copy of the new block.

In further alternative embodiments for the data structure, the Layer 1 information, the Layer 2 information and/or the Layer 3 information can be stored in separate distributed ledgers. For example, the Layer 2 information can be stored in a first distributed ledger, the Layer 1 information can be stored in the first distributed ledger or a second distributed ledger, and the Layer 3 information can be stored in the first distributed ledger, in the second distributed ledger or in a third distributed ledger.

The signalling diagrams in Figs. 8-11 illustrate various interactions between the MNOs/communication networks, the control node and the distributed ledger in accordance with various exemplary embodiments.

In particular, Fig. 8 is a signalling diagram illustrating exemplary embodiments for subscription and asynchronous notification of KPIs. Fig. 8 shows the signalling between third party node 801 , an endpoint 802 (e.g. a SCEF or NEF) for the first mobile communication network (referred to as ‘first endpoint 802’), an endpoint 803 (e.g. a SCEF or NEF) for the second mobile communication network (referred to as ‘second endpoint 803’), the control node 804 and the distributed ledger 805.

In step 811 the third party node 801 sends a subscription request to the control node 804. The subscription request can include a list of subscribers (e.g. a list of IMSIs) that the subscription request relates to, and/or an indication of a performance indicator (e.g. one or more KPIs) that the third party node 801 would like to receive for those subscribers.

If necessary, in step 812 the control node 804 maps the requested performance indicator (KPI) to one or more monitoring events relevant to the first mobile communication network and the second mobile communication network.

In process 813, the control node 804 queries the distributed ledger 805 to identify the mobile communication network that each of the listed subscribers is connected to. In more detail, for all subscriber identities (IMSIs) in the subscription request, the control node 804 queries (step 814) the distributed ledger 805 to determine (and subsequently receive) the identity (e.g. HNI) of the mobile communication network that the subscriber was last active/connected to. In addition, for all subscriber identities (IMSIs) in the subscription request, the control node 804 queries (step 815) the distributed ledger 805 to determine (and subsequently receive) the identity and/or information for the endpoint of the mobile communication network that the subscriber was last active/connected to. The information for the endpoint can comprise any of an IP address, a port, and protocol to interface with SCEF/NEF node.

Thus, with reference to the exemplary distributed ledger structure in Fig. 7, in steps 814 and 815, the control node 804 queries the blockchain(s) 721 , 722 in the second layer 702 to determine which mobile communication network the subscriber is connected to or was last connected to, and then retrieves the information about the mobile communication network (step 814) and endpoint information (step 815) from the relevant block 711 , 712 in the first layer 701 (e.g. from the MNO ID data field and the Service Exposure Endpoint data field.

In steps 816 and 817 the control node 804 then subscribes to the monitoring events determined in step 812 in the relevant mobile communication network for the subscribers identified in the subscription request (step 811). That is, for the subscribers identified in the request that are determined in step 813 to be connected to the first mobile communication network, the control node 804 subscribes to monitoring events for those subscribers in that network via the first endpoint 802 (step 816). For the subscribers identified in the request that are determined in process 813 to be connected to the second mobile communication network, the control node 804 subscribes to monitoring events for those subscribers in that network via the second endpoint 803 (step 817).

In step 818 the control node 804 then sends an acknowledgement to the third party node 801 indicating that it has set up the required subscriptions indicated in the request in step 811.

In process 819, the control node 804 receives updates from the mobile communication networks when the requested monitoring event information is available. Thus, in step 820, the control node 804 may receive an update from the first mobile communication network via the first endpoint 802, with the update including an indication of the monitoring event type and the subscriber(s) (IMSI(s)) that the monitoring event relates to. In step 821 , if step 812 was performed, the control node 804 may map the received monitoring event to the requested KPI(s), and send the KPI(s), along with the relevant subscriber identities, to the third party node 801 in step 821. The signal in step 821 can be sent using the CN-TP interface. If step 812 was not required, the control node 804 can just send the received monitoring event information, along with the relevant subscriber identities, to the third party node 801 in step 821. Steps 822 and 823 correspond to steps 820 and 821 respectively for the second mobile communication network.

Thus, the method shown in Fig. 8 enables a third party node 801 to subscribe to updates for a particular set of subscribers, and for the control node 804 to obtain that information and provide it to the third party node 801.

Fig. 9 is a signalling diagram illustrating exemplary embodiments for updating exposure endpoints for subscribers. Fig. 9 shows the signalling between control node 901 , an endpoint 902 (e.g. a SCEF or NEF) for a second mobile communication network (referred to as ‘first endpoint 902’), the distributed ledger 903 and the first mobile communication network 904.

Process 911 assumes that the method shown in Fig. 8 has been performed and that there is a list of subscriber identities (IMSIs) for which performance indicators have been requested.

In step 912, there is an update to the subscribers connected to the first mobile communication network 904, and this information is added to the distributed ledger 903. It should be noted that although Fig. 9 shows signalling between the first mobile communication network 904 and the distributed ledger 903, this information will be added to the distributed ledger 903 by the control node 901. Step 912 may occur any time that there is a change to a connection status of a subscriber in the first mobile communication network 904, but alternatively an update can occur periodically and/or once a sufficient number of changes have occurred.

In step 913, which can be performed periodically for each subscriber or all subscribers, the control node 901 checks the network identity (e.g. HNI) for any subscribers identified in a third party node’s KPI subscription request by querying the distributed ledger 903. Likewise, in step 914 the control node 901 checks the endpoint information for any subscribers identified in the third party node’s KPI subscription request by querying the distributed ledger 903. Steps 913 and 914 are performed in a similar way to steps 814 and 815 of Fig. 8.

In the event that steps 913 and 914 indicate that the connection status of a subscriber for which a monitoring event was established in steps 816 or 817 of Fig. 8 has changed (e.g. the subscriber is connected to a different mobile communication network), process 915 is performed to update the monitoring event subscriptions.

In process 915 if the information for a first subscriber has been updated to indicate that the first endpoint 902 is the new relevant endpoint for the first subscriber, then in step 916 the control node 901 sends a subscription request to the first endpoint 902 to subscribe to monitoring events for the first subscriber. In step 917 the first endpoint 902 acknowledges the request. Steps 916 and 917 are similar to steps 816, 817 and 818 in Fig. 8. In step 918 the control node 901 can receive notifications/updates from the first endpoint 902 and send notifications/updates to the third party node as described above with reference to steps 820 and 821 (step 919).

Also in process 915, if the information for a first subscriber has not been updated, then the control node 901 can continue to receive notifications/updates from the relevant endpoint and send notifications/updates to the third party node as described above with reference to steps 820 and 821.

Fig. 10 is a signalling diagram illustrating exemplary embodiments for unsubscribing from notifications of KPIs. In particular, Fig. 10 shows a process that enables the third party node to unsubscribe from previously-requested performance indicators for specific subscribers.

Fig. 10 shows the signalling between third party node 1001 , control node 1002, an endpoint 1003 (e.g. a SCEF or NEF) for a first mobile communication network (referred to as ‘first endpoint 1003’), and the distributed ledger 1004.

In step 1011 the third party node 1001 sends an unsubscribe request to the control node 1002. The unsubscribe request can include a list of subscribers (e.g. a list of IMSIs) that the unsubscribe request relates to, and/or an indication of a performance indicator (e.g. one or more KPIs) that the third party node 1001 no longer wishes to receive for those subscribers.

If necessary, in step 1012 the control node 1002 maps the performance indicator (KPI(s)) to one or more monitoring events relevant to the first mobile communication network and the second mobile communication network.

In process 1013, the control node 1002 queries the distributed ledger 1004 to identify the mobile communication network that each of the listed subscribers is connected to. In more detail, for all subscriber identities (IMSIs) in the subscription request, the control node 1002 queries (step 1014) the distributed ledger 1004 to determine (and subsequently receive) the identity (e.g. HNI) of the mobile communication network that the subscriber was last active/connected to. In addition, for all subscriber identities (IMSIs) in the subscription request, the control node 1002 queries (step 1015) the distributed ledger 1005 to determine (and subsequently receive) the identity and/or information for the endpoint of the mobile communication network that the subscriber was last active/connected to. The information for the endpoint can comprise any of an IP address, a port, and protocol to interface with SCEF/NEF node. It will be appreciated that process 1013 and steps 1014 and 1015 are similar to process 813 and steps 814 and 815 described above.

In steps 1016 and 1017 the control node 1002 then unsubscribes from the monitoring events determined in step 1012 in the relevant mobile communication network for the subscribers identified in the unsubscribe request (step 1011). That is, for the subscribers identified in the request that are determined in step 1013 to be connected to the first mobile communication network, the control node 1002 unsubscribes from monitoring events for those subscribers in that network via the first endpoint 1003 (step 1016). In step 1017, the first endpoint 1003 sends an acknowledgement to the control node 1002 confirming that the unsubscribe request has been implemented.

In step 1018 the control node 1002 then sends an acknowledgement to the third party node 1001 indicating that it has unsubscribed for the relevant subscribers indicated in the unsubscribe request received in step 1011.

The following part of the description provides more detailed examples of KPIs and how they can be reported. From the perspective of the customer (e.g. the third party node), a KPI can be defined in high-level or domain specific terms, for example “network retainability” (n _ret ) or “network accessibility” (n _aCc ). These high level KPIs can be quantitative or qualitative and take into account one or more network level KPIs - i.e. metrics that can be measured directly by the MNO, using network probes such as counters. For example, assuming that n _ret is qualitative and n _aCc is quantitative, the formulas below show how they could relate to network level KPIs: UEID- _t ERABAbnormalRelea.se UEID å UEID=N ERABRelease UEID

> 0.8

N

UEID=I ERABAbnormalRelease å _UEiD

UEID=N ERABRelease UEID 0.2 < £ 0.8

N UEID=I ERABAbnormalRelease _UEID å UEID=N ERABRelease UEID £ 0.2

N

UEID=1 _ RRCConnectionSuccess _UEID U å _E ID=I ERABSetupSuccess

UEID- ^N _UE[D RRCConnectionAttempt _{UEID |} UEiD=Nf7p _{ABSetupAttemptuEiD} n N N acc — 3

These exemplary KPIs are discussed by F. Krasniqi, A. Maraj and E. Blaka in “Performance analysis of mobile 4G/LTE networks”, South-Eastern European Design Automation, Computer Engineering, Computer Networks and Society Media Conference (SEEDA_CECNSM), Kastoria, 2018, pp. 1-5. The network accessibility (n _aCc ) shows how accessible is the connectivity service to the customer. It is based on the Radio Resource Control (RRC) protocol call setup success rate (CSSR), which evaluates how many connections where established as a fraction of the total number of connection attempts. Additionally, E-UTRAN Radio Access Bearer (ERAB) setup success measures how many data bearers were allocated correctly as a ratio of the total number of attempts. The average score for all UEs belonging to the customer/third-party is taken into account. The network-level KPIs “RRCConnectionSuccess" ,

“ RRCConnection Attempt , “ERABSetupSuccess" and “ERABSetupAttempf are used to determine the network accessibility (n _acc ). In the above formula, the ratio “RRCConnectionSuccess” to “RRCConnectionAttempt” provides the RRC Call Setup Success Rate (RRC CSSR), which represents the call success rate in a cell or cluster, while the ratio “ERABSetupSuccess” to “ERABSetupAttempt” provides the ERAB Setup Success rate, which represents the setup success rate for all services in the cell or group of cells.

Similarly, the network retainability (n _ret ) measures the capability of the network to ensure services are up and running without interruption. This can use the network-level KPIs “ERABnormalRelease" and “ERABRelease”. In the above formula, the ratio “ERABnormalRelease” to “ERABRelease” provides a Call Drop Rate (CDR) which represents the capability of the system to provide services without interruption.

As noted above with reference to the process illustrated in Fig. 9, it is possible for an MNO (via the control node) to update their connected/disconnected blockchain (e.g. the blockchains 721 and 722 in the second layer 702 of the distributed ledger 700 shown in Fig. 7) as wireless devices (with IMSIs), connect/attach and disconnect/detach from the network. In this case, another principle of distributed ledger techniques - that of “consensus” - can be applied before a new update is issued (i.e. before a new block is added). This means that every MNO and the control node need to verify the new update from an MNO before it is added to the relevant blockchain. This guarantees the security of the approach by preventing, e.g., “rogue” initiatives from MNOs declaring subscribers connected or disconnected to their network, while these subscribers are, for example, connected to another network. For this particular example, a first MNO to declare an IMSI attach event, all other MNOs need to agree that the particular IMSI is not already attached to one of their respective networks.

As noted above, the third layer 703 in the distributed ledger 700 can be used to form a trust domain among the MNOs. Automatic formation of trust domains allows for reporting of KPIs to third parties only for reliable MNOs. Additionally, it not only accelerates the time-to-market of connectivity services, as it negates the need for MNOs to manually negotiate between themselves, but also opens up opportunities for new collaborations and therefore new revenue channels. The distributed ledger is important for this mechanism to work and the signalling diagram in Fig. 11 illustrates exemplary embodiments of KPI report update functionality.

Fig. 11 shows the signalling between third party node 1101 , an endpoint 1102 (e.g. a SCEF or NEF) for the first mobile communication network (referred to as ‘first endpoint 1102’), an endpoint 1103 (e.g. a SCEF or NEF) for the second mobile communication network (referred to as ‘second endpoint 1103’), the control node 1104 and the distributed ledger 1105.

At step 1111 , it is assumed that the third party node 1101 has subscribed to reports of one or more KPIs in respect of one or more subscribers as shown in Fig. 8.

In step 1112, the control node 1104 receives an update from the first mobile communication network via the first endpoint 1102 relating to a previously-requested monitoring event. Thus, in step 1112, the control node 1104 may receive an update including an indication of the monitoring event type, the subscriber(s) (IMSI(s)) that the monitoring event relates to, and updated content for the monitoring event. In step 1113, the control node 1104 receives an update from the second mobile communication network via the second endpoint 1103 relating to a previously-requested monitoring event. Thus, in step 1113, the control node 1104 may receive an update including an indication of the monitoring event type, the subscriber(s) (IMSI(s)) that the monitoring event relates to, and updated content for the monitoring event. If necessary, in step 1114, the control node 1104 may map the received monitoring event/updated content to the previously-requested KPI(s), and send the KPI(s) and updated content, along with the relevant subscriber identities, to the third party node 1101 in step 1115.

In step 1116, the updated content is verified by the third party node 1101. In one embodiment, the third party node 1101 can do their own test on the updated content, for example, by detecting which of their subscribers/wireless devices lost connectivity from an application-level protocol, and comparing that to the reported KPIs. In another embodiment, customers (the third party node 1101) can also perform a correlation of KPIs within a KPI update and between KPIs reported from different MNOs. If, for example, it is observed that a number of MNOs in a certain area report KPIs within a certain range of values, while another MNO reports outlier KPIs (e.g. out of that range), while the service experience from a customer perspective is uniform among all MNOs, then this may indicate misreporting on behalf of the aforementioned MNO.

Once the updated content is verified in step 1116, verification results can be sent to the control node 1104 (step 1117). For example, step 1117 can comprise sending a trust index to the control node 1105, which adds it to the distributed ledger 1105 as “KPI report” (step 1118). This KPI report can be added to the blockchain(s) in the third layer 703 of the distributed ledger 1105. It should be noted that in order for the KPI report to be added, there has to be a consensus from all other entities involved with the distributed ledger 1105, in addition to the MNO which has misreported the KPI. In this way, the distributed ledger 1105 can function as a warning to the relevant MNO that there may be issues regarding their KPI reporting infrastructure, especially if repeated notifications are not verified from the third party node 1101. In an alternative embodiment, it is also possible, if repeated notifications are unverified, that the control node 1104 ceases reporting KPIs originating from one MNO, or for certain IMSIs, for a duration of time.

Finally, there may also be the issue of a third party node 1101 producing an incorrect verification of the KPI data provided by the MNO. For example a “malicious” third party node 1101 may always report that updated content from an MNO has been misreported, resulting in a very low trust index for that MNO. Therefore, the control node 1104 may also verify whether the trust index has been calculated correctly by the third party node 1101 prior to adding it to the distributed ledger 1105. This verification can comprise comparing the trust index with trust indices for the same MNO from other third party nodes, on the same reporting timeframe. If the verification is found to be incorrect, then a notification can be sent to the third party node 1101 by the control node 1104 that it will not be added into the distributed ledger 1105. The techniques presented herein will now be described in more detail with reference to the flow charts in Figs. 12, 13 and 14, which are flow charts illustrating exemplary methods of operating a control node, a network node (e.g. an HSS/HLR or UDM) and a third party node respectively according to certain embodiments. These methods can be performed by control node, the network node and the third party node shown in Figs. 3, 4 and 5 respectively.

Thus, Fig. 12 shows an exemplary method of operating a control node according to general embodiments. Step 1201 comprises the control node 215 storing a first distributed ledger 221. The first distributed ledger 221 comprises subscriber information. The subscriber information is information on subscribers connected to a first communication network 201 that is operated by a first network operator and information on subscribers connected to a second communication network 203 that is operated by a second network operator. One or both of the first communication network 201 and the second communication network 203 may be a wireless communication network.

In step 1202, a request for a first performance indicator is received from a third party node 217. The received request identifies one or more subscribers that the first performance indicator is to relate to. The first performance indicator may be a KPI.

In step 1203, the subscriber information stored in the first distributed ledger 221 is used to identify the respective communication networks that the one or more identified subscribers are connected to.

In some embodiments, the method further comprises the control node 215 requesting performance information relating to the first performance indicator for the one or more identified subscribers in the respective identified communication networks. This step may comprise subscribing to an event relating to the first performance indicator for the one or more identified subscribers in the respective identified communication networks.

In some embodiments, the control node 215 may query the first distributed ledger 221 over time to obtain further subscriber information relating to the one or more subscribers that the first performance indicator is to relate to. For any subscriber for which the subscriber information has changed, the control node 215 can update the subscription to the event.

In some embodiments, the control node 215 may determine the performance information to be requested based on the first performance indicator. In particular, in this step the control node 215 may map the first performance indicator/KPI to an event or monitoring event provided by the respective communication network. In some embodiments, the method can further comprise receiving the requested performance information from the respective identified communication networks. The control node 215 may then determine the first performance indicator from the received performance information. The method can further comprise the control node 215 sending the determined first performance indicator to the third party node 217.

In some embodiments, step 1203 comprises receiving an address for an endpoint of the communication network that a respective identified subscriber is connected to. This address may be a URI-based address, port, for the endpoint/exposure function 207, 209 for the relevant communication networks 201 , 203.

In some embodiments, the method can further comprise receiving updated subscriber information from one or both of the first network operator/first communication network 201 and the second network operator/second communication network 203 relating to subscribers connected to, and/or disconnected from, the respective one of the first communication network 201 and the second communication network 203. The control node 215 can store this updated subscriber information in the first distributed ledger 221.

In some embodiments, the first distributed ledger 221 comprises a first list of subscriber identifiers for subscribers connected to the first communication network 201 and a second list of subscriber identifiers for subscribers connected to the second communication network 203. In these embodiments, the first list may further comprise subscriber identifiers for subscribers that have disconnected from the first communication network 201 and the second list further comprises subscriber identifiers for subscribers that have disconnected from the second communication network 203. In these embodiments, a respective timestamp may be associated with the first list and the second list. These timestamps may indicate the time at which these lists were added to the first distributed ledger 221. In some embodiments, the first list is stored in the first distributed ledger 221 as a respective block 723 of a first blockchain 721 for the first communication network 201 , and the second list is stored in the first distributed ledger 221 as a respective block 221 of a second blockchain 722 for the second communication network 203.

In embodiments where updated subscriber information is received, the updated subscriber information can be in the form of an updated first list and/or an updated second list. The updated first list is stored in the first distributed ledger 221 as a further block 724 of the first blockchain 721, and the second updated list is stored in the first distributed ledger 221 as a further block 724 of the second blockchain 722. In some embodiments, the method further comprises storing first network information comprising information on the first communication network 201 and/or on the first network operator, and storing second network information comprising information on the second communication network 203 and/or on the second network operator. The first network information and the second network information may be stored in the first distributed ledger 221 or in a second distributed ledger. The first network information may be stored in the first distributed ledger 221 or in the second distributed ledger as a block 711 of a network information blockchain 701 , and the second network information may be stored in the first distributed ledger 221 or in the second distributed ledger as a further block 712 of the network information blockchain 701.

In some embodiments, the method further comprises receiving trust information from the third party node 217. The trust information relates to a reliability of a value of the first performance indicator for one or both of the first communication network 201 and the second communication network 203. The control node 215 can store the received trust information in the first distributed ledger 221 , in the second distributed ledger (if present), or in a third distributed ledger. The trust information may be stored as a block in a trust information blockchain 731 in the first distributed ledger 221 or in the second or third distributed ledger.

In some embodiments, the first communication network 201 has one of a NEF and a SCEF, and the second communication network has one of a NEF and a SCEF, and the subscriber information for the subscribers connected to the first communication network 201 is obtained via the one of the NEF and the SCEF of the first communication network 201 , and the subscriber information for the subscribers connected to the second communication network 203 is obtained via the one of the NEF and the SCEF of the second communication network 203.

Fig. 13 shows an exemplary method of operating a network node according to general embodiments. The network node is a node in the first communication network 201 , which is operated by the first network operator. The network node is responsible for storing the distributed ledger 221. In some embodiments, the network node is an HSS/HLR 211 , or a UDM 213.

In step 1301 , the network node 211, 213 stores a first distributed ledger 221 that comprises subscriber information. The subscriber information can be as described above with respect to step 1201. Moreover, the first distributed ledger 221 may include further information/blocks as described above with reference to Fig. 12.

In step 1303, the network node 211 , 213 also store, in the first distributed ledger 221 , or in a second distributed ledger, trust information relating to a reliability of a value of a first performance indicator for one or both of the first communication network 201 and the second communication network 203. The trust information may be stored as a block in a trust information blockchain 731 in the first distributed ledger 221 or in a second distributed ledger. In some embodiments, this trust information may have originated from a third party node 217.

Fig. 14 shows an exemplary method of operating a third party node 217 according to general embodiments. The third party node 1101 may be an Application Server (AS) or an Application Function (AF). In step 1401 , the third party node 217 sends trust information to a control node 215. The trust information relates to a reliability of a value of a first performance indicator for one or both of a first communication network 201 operated by a first network operator and a second communication network 203 operated by a second network operator.

In some embodiments, the method can further comprise sending to the control node 215 a request for the first performance indicator. The first performance indicator may be a KPI. The request can identify one or more subscribers that the first performance indicator is to relate to. The method may then further comprise receiving the requested first performance indicator from the control node 215.

As described herein, an apparatus, device, virtual apparatus or virtual device can be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of a device or apparatus, instead of being hardware implemented, be implemented as a software module such as a computer program or a computer program product comprising executable software code portions for execution or being run on a processor. Furthermore, functionality of a device or apparatus can be implemented by any combination of hardware and software. A device or apparatus can also be regarded as an assembly of multiple devices and/or apparatuses, whether functionally in cooperation with or independently of each other. Moreover, devices and apparatuses can be implemented in a distributed fashion throughout a system, so long as the functionality of the device or apparatus is preserved. Such and similar principles are considered as known to a skilled person.

The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.