Technical Field The present disclosure relates to analysing the performance of satellite terminals in a satellite communications system in order to make upgrades or corrections to the system.

Background Some regions of the world such as rural, developing or isolated areas often have limited communication infrastructure, to the extent that it may not be feasible to provide highspeed broadband internet access through traditional, ground-based means such as a wired network or even ground-based cell towers or the like. Providing an internet link via satellite enables such regions to obtain modern standards of internet access without the need to build a large amount of new infrastructure on the ground. Furthermore, satellite-based internet access can even be used as an alternative to ground-based means in regions that do have a developed communication infrastructure, or as backup to such infrastructure in case a ground-based link fails. To provide internet access via satellite, the satellite provides a satellite link between a gateway earth station and each of a plurality of client systems, and the gateway connects to an internet, i.e. a wide area internetwork such as that commonly referred to as the Internet (capital I). The link comprises a forward link for sending data from the internet to the client system, and a reverse link for receiving data from the satellite terminal directed to the internet. Thus each of the client systems is able to gain access to the internet via the satellite link with the gateway, and via the connection between gateway and internet. Each client system could be anything from an individual domestic system in the home, to a local network serving a whole office, school, hospital, village, community or the like. Whatever form it takes, the client system comprises a satellite terminal, which comprises a satellite modem and a satellite antenna (typically comprising a dish). The satellite antenna forms the physical link with the satellite whilst the modem performs the necessary modulation and demodulation to send and receive data, respectively, via the link and satellite. One example of a satellite terminal commonly used in the home and in businesses is a VSAT (Very Small Aperture Terminal).

In a typical model an operator of the satellite system, or at least the gateway service, acts as an upstream internet service provider who sells bandwidth to a plurality of downstream internet service providers, who may be referred to as partners or customers of the operator. The downstream internet service providers then sell bandwidth on to end-users of the client systems (or there could even be more than one intermediate tier of internet service provider between the operator and end-users)

The operator typically also collects a database logging various pieces of information on each of the client systems involved. This information may comprise for example: the geographical location of the terminal, the dish size, and records of the signal strength and data

throughput experienced over the link (on both the forward and reverse link). For instance Avanti has over a billion VSAT signal and throughput logs spanning over five years, collected from over 30,000 VSATs.

Summary It is recognized herein that these data logs are currently not being exploited to their full potential. The data is currently stored in inaccessible ways - either archived in compressed files or in large, plain tables or databases, such as in an operations support system (OSS), with no tool for making use of the data. Furthermore, the collective data is currently just for information purposes, e.g. to identify uptake by users. Otherwise the data is only ever used on an individual basis, e.g. to check the details of a particular terminal if an end-user complains.

The inventors have recognized that there is a huge potential value hidden in the data, in that it could be used to analyse the performance of existing terminals in order to identify upgrades or corrections to the system. Aggregating, analysing, structuring and presenting this data in an understandable form could potentially have very large benefits for the operator and its service partners in terms of operational efficiency and anomaly detection. Particularly, by processing metadata on one or more performance-influencing factors such as the location of the terminal, dish angle, dish size, which beam is being used, etc., then it is possible to gauge the expected performance of an existing terminal or group of terminals, and thereby identify which terminals are underperforming (or more generally exhibiting an anomalous performance) compared to what might be expected.

According to one aspect disclosed herein, there is provided a method of analysing a system comprising multiple satellite terminals, based on at least one performance indicator and one or more performance-influencing parameters, wherein each of the satellite terminals comprises a satellite modem and a satellite antenna arranged to form a respective satellite link with a satellite, and to thereby access to an internet. The method comprises: collecting data on a set of some or all of the satellite terminals, wherein the data comprises, for each respective one of the set of satellite terminals, A) a respective value of the at least one performance indicator, being indicative of a performance of the respective link, and B) a respective value of each of the one or more performance-influencing parameters, which influence the performance of the respective link. The method further comprises, in relation to said set of satellite terminals or a subset of said set, using a computer-implemented tool to I) conduct a pre-analysis step based on the respective values of the one or more performance-influencing parameters in order to establish a basis for gauging an expectation or potential of the performance of the respective links, and II) relative thereto, analysing the respective values of the performance indicator in order to identify one or more satellite terminals from amongst said set or subset as performing anomalously; and based on said analysis, instigating an action to upgrade or correct an aspect of the system relating to at least one of the anomalously-performing satellite terminals.

In most cases the one or more anomalously-performing terminals being identified will be one or more underperforming terminals, e.g. underperforming relative to their peers and/or having the greatest potential for improvement. In this case action may be taken to upgrade the underperforming terminal (e.g. installing a bigger dish, a more powerful transceiver or higher performing modem) or to correct some related aspect of the system (e.g. to clear an obstacle such as an overgrown tree). However it may alternatively or additionally be of interest to identify one or more over-performing terminals (compared to the expectation for those terminals, e.g. for a given dish size and/or geographic location), which may occur due to a dishonest or mistaken reporting of configuration information (e.g. dish size, location, etc.) by an installer. In this case action may be taken to correct the recorded configuration information.

In embodiments said pre-analysis I) may comprise, for each of the set or subset of satellite terminals, determining a respective expected or potential value of the performance indicator based on the respective values of one or more of the performance-influencing parameters, and evaluating a respective value of an improvability metric being based on a comparison between the respective expected or potential value and the respective value of the performance indicator collected in said data; and said analysis II) may comprise, within said set or subset of satellite terminals, comparing the respective values of the improvability metric with one another in order to identify the one or more anomalously-performing satellite terminals based on having greater potential for improvement relative to the set or subset.

In embodiments, said pre-analysis I) may comprise filtering the set of terminals based on the values of one or more of the performance-influencing parameters collected in said data, so as to identify a subset of said set of satellite terminals expected to exhibit similar performance; and the comparison in said analysis II) may comprise comparing the respective values of the improvability metric with one another within the subset.

In embodiments, said pre-analysis I) may comprise filtering the set of terminals based on the values of one or more of the performance-influencing parameters collected in said data, so as to identify a subset expected to exhibit similar performance; and said analysis II) may comprise, within said subset, comparing the respective values of the performance indicator with one another, or comparing respective values of a metric derived from the performance indicator, in order to identify the one or more anomalously-performing satellite terminals based on performing anomalously relative to the subset.

In embodiments, said analysis I) may comprise, for each of the satellite terminals in the subset, determining a respective expected or potential value of the performance indicator based on the respective values of one or more of the performance-influencing parameters, and evaluating a respective value of an improvability metric being based on a comparison between the respective expected or potential value relative and the respective value of the performance indicator collected in said data; and said analysis II) may comprise comparing the respective values of the improvability metric with one another within the subset in order to identify the one or more anomalously-performing satellite terminals based on having greater potential for improvement relative to the subset.

In Embodiments, the comparison in said analysis II) may comprise sorting the subset according to the performance indicator or metric, and identifying the anomalously- performing terminals as being those in the most underperforming nth quantile.

In embodiments, the one or more performance-influencing parameters used in said preanalysis may comprise one or more of: (a) a geographical location of the satellite terminal, (b) an angle from which the antenna views its satellite, (c) an identifier as to which of multiple satellites the satellite terminal uses to form the link, (d) an identifier as to which of multiple beams the satellite terminal uses to form the link, (e) an identifier as to which of multiple hubs the satellite terminal uses to connect to the internet, (f) an identifier of a model and/or vendor of the modem, (g) a carrier frequency band of the link, (h) a polarity of the link, (i) an identity of an installer who installed the satellite terminal, (j) an installation date of the satellite terminal, (k) a reported dish size of the antenna, (I) an identity of a downstream internet service provider providing the internet access, (m) a type of downstream internet service provider providing the internet access, (n) a type of subscription through which the internet access is provided, (o) an indication of an environmental condition experienced by the antenna, and/or (p) a reported length and/or type of a cable between an indoor unit comprising the modem and an outdoor unit comprising the antenna.

In embodiments, the one or more performance-influencing parameters upon which the expected or potential value of the performance indicator is based may comprise one or more of: (a) a geographical location of the satellite terminal, (b) an angle from which the antenna views its satellite, (c) an identifier as to which of multiple satellites the satellite terminal uses to form the link, (d) an identifier as to which of multiple beams the satellite terminal uses to form the link, (e) an identifier as to which of multiple hubs the satellite terminal uses to connect to the internet, (f) an identifier of a model and/or vendor of the modem, (g) a carrier frequency band of the link, (h) a polarity of the link, (i) an identity of an installer who installed the satellite terminal, (j) an installation date of the satellite terminal, (k) a reported dish size of the antenna, (I) an identity of a downstream internet service provider providing the internet access, (m) a type of downstream internet service provider providing the internet access, (n) a type of subscription through which the internet access is provided, and/or (o) an indication of an environmental condition experienced by the antenna.

In embodiments, the one or more performance-influencing parameters upon which said filtering is based may comprise one or more of: (a) a geographical location of the satellite terminal, (b) an angle from which the antenna views its satellite, (c) an identifier as to which of multiple satellites the satellite terminal uses to form the link, (d) an identifier as to which of multiple beams the satellite terminal uses to form the link, (e) an identifier as to which of multiple hubs the satellite terminal uses to connect to the internet, (f) an identifier of a model and/or vendor of the modem, (g) a carrier frequency band of the link, (h) a polarity of the link, (i) an identity of an installer who installed the satellite terminal, (j) an installation date of the satellite terminal, (k) a reported dish size of the antenna, (I) an identity of a downstream internet service provider providing the internet access, (m) a type of downstream internet service provider providing the internet access, (n) a type of

subscription through which the internet access is provided, and/or (o) an indication of an environmental condition experienced by the antenna.

In embodiments, said performance indicator may be one of: spectral efficiency, carrier usage, data rate, volume of data, signal strength, signal to disturbance ratio, or error rate.

In embodiments, individual values of the performance indicator may be collected for each of the satellite terminals on multiple occasions over a period of time, and the value of the performance indicator used in said analysis may be an average (e.g. mean, median or mode) of the individual values over said period of time or a window within said period. In embodiments, individual values of the performance indicator may be collected for each of the satellite terminals on multiple occasions over a period of time, and the value of the performance indicator used to determine the improvability metric in said pre-analysis may be an average (e.g. mean, median or mode) of the individual values over said period of time or a window within said period.

In embodiments, said action may comprise any one or more of: upgrading the anomalously- performing terminal, correcting a reported dish size of the antenna of the anomalously- performing terminal, repositioning the antenna of the anomalously-performing terminal, realigning the antenna of the anomalously-performing terminal, clearing an obstacle in a line of sight between the antenna of the anomalously-performing terminal and its satellite, and/or adjusting an installation threshold level of the anomalously-performing terminal. In embodiments, said action may be instigated by any of: sending a technician to perform the action, contacting a downstream ISP to perform the action, contacting an end-user to perform the action, or automatically performing the action.

In embodiments, said internet is the Internet. Alternatively said internet may be a private internetwork or virtual private network (VPN).

In embodiments, different ones of the satellite terminals may be provided with said internet access by a plurality of different downstream internet service providers, and said method may be performed by an upstream internet service provider (the "operator" in

embodiments below).

In embodiments, said link may be a forward link which sends data from the internet via the satellite to the satellite terminal, the performance indicator indicating the performance of the forward link, and the performance-influencing parameters influencing the performance of the forward link. In embodiments, said link may be a reverse link which sends data from the satellite terminal via the satellite to the internet, the performance indicator indicating the performance of the reverse link, and the performance-influencing parameters influencing the performance of the reverse link.

In embodiments, the tool may comprise a user interface enabling a user of the tool to do any one or more of the following: select the performance indicator from amongst a plurality of available performance indicators, select the one or more performance-influencing parameters based upon which said filtering is performed from amongst a larger number of available performance-influencing parameters, select a range of values of at least one of the one or more performance-influencing parameters to filter out or to remain in the subset in said filtering, and/or select the quantile to identify in said sorting.

In embodiments, the data may comprise a geographical location of each of the set of satellite terminals, and the tool may comprise a graphical user interface which represents at least some of the set or subset of satellite terminals at their respective geographical locations on a graphical map along with a representation of the respective value of the performance indicator. According to another aspect disclosed herein, there is provided a computer implemented tool for analysing a system comprising multiple satellite terminals, based on at least one performance indicator and one or more performance-influencing parameters, wherein each of the satellite terminals comprises a satellite modem and a satellite antenna arranged to form a respective satellite link with a satellite, and to thereby access to an internet; the computer implemented tool comprising code embodied on a computer-readable medium and configured so as when run on one or more processing devices to perform operations of: accessing data on a set of some or all of the satellite terminals, wherein the data comprises, for each respective one of the set of satellite terminals, A) a respective value of the at least one performance indicator, being indicative of a performance of the respective link, and B) a respective value of each of the one or more performance-influencing parameters, which influence the performance of the respective link; and in relation to said set of satellite terminals or a subset of said set, I) conducting a pre-analysis step based on the respective values of the one or more performance-influencing parameters in order to establish a basis for gauging an expectation or potential of the performance of the respective links, and II) relative thereto, analysing the respective values of the performance indicator in order to identify one or more satellite terminals from amongst said set or subset as performing anomalously.

According to another aspect disclosed herein, there is provided computer apparatus for analysing a system comprising multiple satellite terminals, based on at least one

performance indicator and one or more performance-influencing parameters, wherein each of the satellite terminals comprises a satellite modem and a satellite antenna arranged to form a respective satellite link with a satellite, and to thereby access to an internet; the computer apparatus arranged to run a computer implemented tool so as to perform operations of: accessing data on a set of some or all of the satellite terminals, wherein the data comprises, for each respective one of the set of satellite terminals, A) a respective value of the at least one performance indicator, being indicative of a performance of the respective link, and B) a respective value of each of the one or more performance- influencing parameters, which influence the performance of the respective link; and in relation to said set of satellite terminals or a subset of said set, I) conducting a pre-analysis step based on the respective values of the one or more performance-influencing parameters in order to establish a basis for gauging an expectation or potential of the performance of the respective links, and II) relative thereto, analysing the respective values of the performance indicator in order to identify one or more satellite terminals from amongst said set or subset as performing anomalously. In embodiments, the computer implemented tool may be further configured in accordance with any of the features disclosed herein.

Brief Description of the Drawings To assist understanding of the present disclosure and to show how embodiments may be put into effect, reference is made by way of example to the accompanying drawings in which: Figure 1 is a schematic illustration of a system for providing internet access via satellite, Figure 2 schematically illustrates the geographic coverage of a cluster of satellite beams,

Figure 3 is a schematic illustration of a part of a system for providing internet access via a plurality of satellite beams,

Figure 4A is a schematic block diagram of a gateway earth station,

Figure 4B is a schematic block diagram of a plurality of client systems,

Figure 5 shows a screen shot of a user interface of a tool for analysing the performance of satellite terminals,

Figures 6 to 13 show further parts of a user interface of a tool for analysing the performance of satellite terminals,

Figure 14 gives a schematic overview of a process for analysing data on satellite terminals,

Figure 15 gives a schematic overview of a process for aggregating data from multiple sources,

Figures 16 to 20 illustrate some example use cases of a tool for analysing the performance of satellite terminals, and

Figures 21 to 25 illustrate some examples studies of the use of a tool for analysing the performance of satellite terminals. Detailed Description of Embodiments

Figure 1 gives a schematic overview of a system 100 for providing access to an internet 102, i.e. a wide area internetwork, such as that commonly referred to as the Internet (capital I), or such as a virtual private network (VPN). The system 100 comprises: a gateway earth station ("gateway" for short) 104; at least one satellite 110 in orbit about the earth; and multiple client systems 112 remote from the gateway 104, located in a region on the earth's surface to which internet access is being provided. The gateway 104 comprises one or more satellite hubs 402a, 402b each connected to the internet 102, and at least one antenna 106 connected to the hubs 402. Each of the client systems 112 comprises a satellite modem 120 and an antenna 114 connected to the modem 120. The satellite 110 is arranged to be able to communicate wirelessly with the hubs 402 of the satellite gateway 104 via the gateway antenna 106, and with the modems 420 of each of the client systems 112 via the respective client antennae 114, and thereby provide a satellite link 107 between the gateway 104 and each of the client systems 112 for transmitting internet traffic between a source or destination on the internet 102 and the client systems 112. For example the satellite links 107, hubs 402 and modems 420 may operate on the Ka microwave band (26.5 to 40 GHz), or Ku band (12-18 GHz). Each satellite link 107 comprises a forward link 107F for transmitting traffic originating from an internet source to the client systems 112, and a return link 107R for transmitting traffic originating from the client systems 112 to an internet destination.

Each of the hubs 402a, 402b serves (i.e. provides a respective internet access service to) a respective subset 112A, 112B of the client systems 112, so that internet traffic can be transmitted and received between the each respective subset 112A, 112ES of client systems and the internet 102 via the satellite links 107 with the respective hub 402a, 402b. Note that a client system 112 is referred to herein as a client from the perspective of the satellite system 100, i.e. at least in that it is a client of the satellite-based internet access service provided by the respective hub 402. In most embodiments, most or all of the client systems 112 will also be clients of one or more servers on the internet 102 (e.g. web servers, an email server, a VoIP server, etc.). However, it is not necessarily excluded that one or more of the client systems 112 could alternatively or additionally act as a server from the perspective of the internet 102 (e.g. providing web content to other users on the internet 102).

The end users 116 may be individual people, and/or organisations such as businesses.

Depending on implementation, one, some or all of the client systems 112 may each comprise a node of a local communication infrastructure, such as a router, switch, bridge, access point or gateway (i.e. any node capable of forwarding traffic), via which internet access is provided to the user equipment of a plurality of end-users within the region in question. E.g. the local communication infrastructure may comprise a relatively short range wireless network or a local wired infrastructure, such as a local area network (LAN), metropolitan area network (MAN), or campus or corporate area network (CAN), connecting onwards to a plurality of home and/or business routers and/or individual user devices in the region. Alternatively or additionally, one, some or all of the client systems 112 may each comprise an individual, private device, each with its own satellite antenna 114 and modem 420 for connecting to the satellite 110 along with a local interface such as a router, switch, bridge or access point for connecting to one or more respective user devices. For example an individual femtocell or picocell could be located in each home or business, each connecting to a respective one or more user devices using a short range wireless technology, e.g. a local RF technology such as Wi-Fi.

There are a number of options for implementing the satellite (or satellites) 110. For example, referring to Figure 2, the satellite 110 may be deployed in a geostationary orbit and arranged so that its field of view or signal covers roughly a certain geographic region 200 on the Earth's surface. Figure 2 shows South Africa as an example, but this could equally be any other country or region within any one or more countries (e.g. a state, county or province, or some other non-politically defined region). Furthermore, referring to Figures 2 and 3, using modern techniques the satellite 110 may be configured as a spot- beam satellite based on a beam-forming technology, so that the communications between the satellite 110 and the client equipment 112 in the covered region 200 are divided amongst a plurality of spatially distinct beams 202. Each beam 202 is directed in a different respective direction such that beams are arranged into a cluster, each beam covering a different respective (sub) area on the earth's surface within the region 200 in question (though the areas covered by the beams 202 may be arranged to overlap somewhat to avoid gaps in coverage). This is a way of increasing capacity, as the limited frequency band of the satellite 110 (e.g. Ka band) can be re-used separately in different beams 202 - i.e. it provides a form of directional spatial division multiplexing (though adjacent beams may still use different bands or sub-bands, especially if they overlap in space). By way of example Figure 2 shows five beams 202a-202e which between them approximately cover the area of South Africa, but it will be appreciated that other numbers and/or sizes of beam are also possible. Note however that this is just one example. Alternatively, the satellite 110 could be arranged in a geostationary orbit with a single wide beam. Also, a plurality of single beam and/or spot-beam satellites may be deployed in geostationary orbits in order to cover a wider geographic area than can be covered by a given satellite. As another possibility, the satellites 110 are not limited to being placed in geostationary orbit. In other embodiments for example, the internet access could be provided to a given region by means of one or more constellations of low earth orbit or medium earth orbit satellites, where a

constellation is a group of satellites in a non-geostationary orbit but which between them are sufficient in number (given their altitude) to provide constant coverage of the region in question in normal conditions.

In one model the operator of gateway 104 (or at least the gateway service) acts as an upstream ISP, i.e. providing bandwidth to multiple different downstream ISPs, each of whom in turn provides an internet access service to a respective group of end users 116. Furthermore, typically different ones of the downstream ISPs each use a different vendor's proprietary technology. For instance, different downstream ISPs may supply a different respective vendors' version of the client system 112 for use by its respective end-users 116.

Figure 4A is a block diagram showing part of the gateway 104 in more detail. As shown, the gateway 104 comprises a plurality of satellite hubs 402, each of a different respective vendor (e.g. each used by a different downstream ISP to serve its respective end users 116). For example, the gateway 104 may comprise the gateway antenna 106 and one or more buildings which house the hubs 402, along with various infrastructure so as to connect the hubs to the internet 102 and the gateway antenna 106. In Figure 1 and 4a, two hubs 402a and 402b made by two different vendors A and B are shown by way of illustration, one used by a first downstream ISP X and the other used by another downstream ISP Y, but it will be appreciated that other numbers may be used in the case of other numbers of vendors.

Each hub 402 comprises: a modulator 404; a demodulator 406; a network interface 410 such as an IP interface for connecting to the internet 102; and a hub control module 408 to which the network interface 410, modulator 404 and demodulator 406 are each connected. The modulator 404, demodulator 406 and control unit module 408 may be implemented in software, i.e. as code arranged to be executed on one or more processors of the respective hub 402. Alternatively one or more of these components could be implemented in dedicated hardware of the respective hub 402, or a combination of hardware and software. The gateway 104 further comprises an internet-facing interconnect (e.g. IP infrastructure) 109 to which each of the hubs 402 is connected via its respective network interface 410, so as to connect the hubs 402 to the internet 102. The gateway 104 also has an RF ("radio frequency") front-end 105 to which each of the hubs 402 is connected via its respective modulator 404 and demodulator 406, so as to connect the hubs 402 to the gateway antenna 106.

In the gateway configuration of Figure 4A, each of the different hubs 402a, 402b, ... of the different vendors A, B ... operate independently of one another to serve the client systems 112 of the different subsets 112A, 112B ... respectively. For example, for communicating with the respective groups of client systems 112a, 112b via the satellite(s) 110, the different vendors A, B, ... may be free to independently select a their own respective modulation schemes, their own respective differential encoding schemes, their own respective encryption schemes, their own respective error protection schemes, and/or their own respective communication protocols. Hence in general, the modulator 404 and demodulator 406 on one or more of the hubs 402 (e.g. 402a) may be configured to operate according to a different modulation scheme than those on one or more others of the hubs 402 (e.g. 402b); and/or, the control module 408 on one or more of the hubs 402 (e.g. 402a) may be configured to use a different differential encoding scheme, encryption scheme, error protection scheme and/or communication protocol than one or more others of the hubs 402 (e.g. 402b). Or in embodiments, one or more such schemes or protocols may be selected after deployment of the hub or even adapted dynamically at one or more of the hubs 402, such that they are at least sometimes different between the different hubs 402.

Note that the gateway 104 is not limited to being implemented as a single earth station at a single geographic site, and the gateway 104 could instead comprise multiple earth stations (each comprising at least one respective antenna 106) networked together over multiple different geographic sites.

Note also for completeness that the same modulation scheme, differential encoding scheme, encryption scheme, differential encoding scheme and/or error protection scheme does not necessarily have to be used on the forward link 107F and reverse link 107R (though in embodiments they may be the same).

Figure 4B shows an example of the client systems 112. By way of illustration, Figure 4B shows one client system 112a of the first subset 112A, served by the hub 402a of vendor A; and one client system 112b of the second subset, served by the hub 402b vendor B.

However, it will be appreciated that generally each vendor's hub may serve a respective subset of one or more client systems 112, and also that other numbers of vendors' equipment may be present.

Each client system 112 comprises a respective satellite terminal 412, a respective router 423, and a respective one or more user devices 424a. For example, one, some or all of the client systems 112 may each take the form of a VSAT (very small aperture terminal). Each satellite terminal 412 comprises a respective outdoor unit (ODU) 422, and a respective indoor unit (IDU) 420 connected to the respective ODU 422. The ODU 422 comprises the antenna 114 of the respective client system 112. The IDU 420 operates as a satellite modem, comprising a respective demodulator 414, modulator 416 and control module 418, wherein the respective demodulator 414, modulator 416 and client router 423 are each connected to the control module. The one or more respective user devices 424 are also connected to the respective client router 423. Each of the demodulator 414, demodulator 416 and control module 418 may be implemented in software, i.e. code arranged for execution on one or more processors of the respective IDU; or one or more of these components could instead be implemented in dedicated hardware, or a combination of hardware and software.

The user devices 424 take the form of computer devices such as desktop, laptop or tablet computers, smartphones, set-top boxes, and /or smart TVs etc., through which the respective end-users 116 consume the internet access provided via the hubs 402 and satellite(s) 110. The ODUs 422 are situated in an outdoor environment, in which the satellite 110 is visible to their antennae 114. The IDUs 422 are generally situated indoors, e.g. in a residential or business premises, and are each connected to the corresponding ODU 422 via a cable connection. In operation, outgoing data received from the internet 102 via the network interface 410 and intended for the satellite terminal 412 (and therefore ultimately for the user device (s) 424 connected to that terminal), is supplied from the internet 102 to the hub control module 408, via the internet-side interconnect 105. The control module 408 performs any preliminary processing of the data that may be required, such as encryption, differential encoding, error protection and/or reformatting to the relevant protocol for transmission, then supplies the data to the modulator 404 of the hub 402 for modulation into RF signals, which are transmitted via the RF front-end 109 and forward satellite link 107F. These RF signals are received at the satellite terminal 412 of the client system 112, via its antenna 114. The received signals are demodulated by the demodulator 414 at the satellite terminal 414 to extract the original data, which is supplied to the terminal's control module 418 to perform any further processing such as re-formatting, error detection or correction, decoding and/or decryption (to compliment or reverse the corresponding processing operation performed at the transmit side, as appropriate). The data is then output from the control module 418 to the router 423 for routing to the relevant user device(s) 424.

In the other direction, data originating with one of the user devices 424 and destined for the internet 102, is received by the control module 418 of the relevant client satellite terminal 412 via the corresponding router 423, and the control module 418 performs any preliminary processing that may be required, such as encryption, differential encoding, error protection and/or reformatting to the relevant protocol for transmission. The control module 418 then supplies the data to the modulator 416 of the terminal 412, which modulates this data into RF signals which are transmitted via the return satellite link 107R and received at the gateway antenna 106. The received signals are passed to the demodulator 406 of the hub 402 of the relevant vendor via the RF front-end 105, and demodulated by the vendor's demodulator 406 to extract the original data, which is supplied to the respective hub control module 408. The control module 408 of the vendor's hub performs any further processing such as re-formatting, error detection or correction, decoding and/or decryption (to compliment or reverse the corresponding processing operation performed at the transmit side, as appropriate), and then outputs this data to the internet 102 via the network interface 410 and IP side interconnect 109. Thus according to an arrangement such as described in relation to Figures 4A and 4B, the hub 402a, 402b of each vendor A, B... serves its respective client systems 112A, 112B... using much of its own proprietary technology, but whilst using the operator's satellite front-end 105, 106 and the actual building or physical structure of the gateway 104, as well as the satellite infrastructure 110 of the operator. In some arrangements in fact, most of the signal modulation and/or other signal processing is highly proprietary, and the satellite operator provides only the very lowest physical layer support for transmitting the data over the satellite link 107.

According to the present invention, there is provided a software tool 454 for analysing the performance of some or all of the satellite terminals 412 (refer again to Figure 1). The tool 454 may be installed and run locally on a user terminal 450 of the operator, or may be hosted remotely on a server (not shown) and accessed through the user terminal 450 of the operator, or may be implemented in a combination of a local and remotely-hosted software. The tool 454 may be referred to as a "VSAT mapping and aggregation tool" (VMAP), but it will be understood this is not limiting. As an input to the tool 454, the operator of the gateway 104 (or gateway service, i.e. the upstream ISP) collects various statistics concerning the satellite terminals 412, and stores these statistics in a database 452 (see again Figure 1). The database 452 may be stored locally on the user terminal 454 of the operator, or may be stored remotely on a server, or a combination of these. Either way, the tool 454 is arranged to access the statistics (i.e. the data) from the database 452 and processes these in order to analyse the performance of the satellite terminals 412.

Where the user terminal 450 has to access part or all of the tool 454 and/or database 452 from a server, this may be via any suitable network, e.g. the Internet, or a private network or virtual private network of the operator. Note also that a server as referred to herein may comprise one or more physical server units at one or more geographical sites.

An overview of the operation of the tool 454 is shown in Figure 14.

According to some embodiments, as shown at step S10 the, the data in the database 452 may be aggregated from multiple intermediate sources 1402, e.g. an OSS of the operator, a traffic shaper, and/or a respective network management system (NMS) of each of one or more of the hubs 402 (which is a subsystem of the respective hub 402). In this case the data is loaded from the multiple sources 1402), and indexed and stored in the combined database 452 (e.g. locally on the operator's user terminal 450). For instance the data may be aggregated from the network management systems of multiple hub vendors. The tool 454 may also aggregate the raw log data into smaller sets (e.g. daily, last week) to deliver realtime results. Note however, it is not excluded that some or all of the data could instead be reported directly to the database 452 used by the tool 454.

At step S20, the tool 454 conducts an analysis of at least some of the data in the database 452. This analysis may comprise performing calculations on the data sets to extract additional metrics (e.g. spectral efficiency, theoretical beam levels and carrier usage).

At step S30, the tool 454 outputs some or all of the results of the analysis to be presented to a person acting for the operator (e.g. an employee) on a screen of the operator's user terminal 450. This may comprise presenting the aggregated data set with filters, and/or indicators via maps and charts.

Note that the steps S10, S20, S30 do not necessarily have to be performed entirely one after another. E.g. in embodiments, the analysis and presentation of earlier-collected data may be performed while the collection of newer data is still ongoing.

Figure 15 gives an overview of an example process for aggregation the data into the database 452 from multiple sources 1402 (step S10). This process may be performed by the tool 454 or by another intermediate algorithm arranged to input into the database 452.

A first step SI is to reduce the raw data into chunks that can be filtered in real-time. The process then proceeds to a two layer aggregation mechanism. The first of these two layers, labelled step S2, is to aggregate logs that were collected every instance of a smaller unit of time, e.g. every lOmin or lh, into collections aggregated over a longer unit of time, e.g. daily collections. This may be done by averaging over the longer period in question. In

embodiments this need only be executed once when new logs are added. The second layer, labelled step S3, is to calculate last day, last week, last month and/or all-time statistics - updated regularly, e.g. once per day. In embodiments, the data filtering and analysis described below may be mainly carried out on the second layer aggregates for a real-time user experience. That is, the second layer aggregation takes the daily data set (output from the first layer aggregation) and computes all metrics for fixed periods, e.g. last day, last week, last month, last year and/or all time (all except for "all time" are computed relative to the current date), which are intervals that the operator may be interested at looking at. An advantage of this is that it enables the operator to analyse, filter and cross compare the results in real time as one has a much smaller data sets.

By whatever means collected (and optionally aggregated), the data in the database 452 comprises multiple items of data for each of the satellite terminals 412 in question. These items comprises at least one performance indicator which is a measure of the performance of a link 107 between a satellite terminal 412 and a satellite 110 (i.e. its performance in conveying internet traffic between the internet 102 and satellite terminal 412). Separate values may be maintained for the forward and reverse links 107F, 107R. Furthermore, the items of data in the database 452 comprise one or more performance-influencing parameters, being factors which affect the performance of the link. In embodiments, the performance indicator(s) may comprise a measure of data rate over the forward and/or reverse link 107F, 107R, such as an average data rate or maximum achieved data rate, e.g. measured in bits per second (bps) or bytes per second (Bps). As another example the performance indicator(s) may comprise the usage in the carrier spectrum, i.e. the bandwidth, of the forward and/or reverse link 107F, 107R - that is to say, the width in the carrier frequency spectrum allocated to the link 107, e.g. measured in Hz, kHz or resource units. As another example the performance indicator(s) may comprise a measure of spectral efficiency, which is a measure of the data rate divided by a measure of the carrier usage, e.g. in bps/Hz. As another example the performance indicator(s) may comprise a measure of total volume of data sent and/or received over the link, e.g. an absolute total to date or since an arbitrary reference point, or a total over a relatively large unit of time such as a day. This may be measured for instance in bits, bytes, kilobytes, megabytes or gigabytes. As another example, the performance indicator(s) may comprise a measure of signal strength, such as signal power, e.g. measured in dB relative to some defined reference. As another example, the performance indicator(s) may comprise a signal to disturbance ratio experienced over the forward and/or reverse link 107F, 107R, wherein disturbance may refer to either noise or interference, or a combination both. As yet another example, the performance indicator(s) may comprise a measure of error rate experienced over the forward and/or reverse link 107F, 107 R, e.g. packet loss rate. In embodiments, the spectral efficiency may be of particular interest. The end-users care about data rate, e.g. bps, but the operator sells its resources in terms of carrier bandwidth, e.g. in Hz. The spectral efficiency gives a measure of how efficiently the carrier bandwidth is being converted into the commodity which end-users are interested in. Note that in embodiments the bandwidth allocation is related to the signal level

experienced by the satellite terminal 412 (on the forward and/or reverse link 107F, 107R). A terminal 412 with a lower signal strength will automatically select to use a more robust coding that will use up more of the bandwidth of the respective forward or reverse satellite link 107F, 107R; and vice versa a terminal with a high signal strength will automatically select a less robust coding that will use up less of the bandwidth of the respective forward or reverse link 107F, 107R.

Note also that one or more of the items of data in the database need not necessarily be not be variables included explicitly in the raw data from the terminals 412 or the intermediate sources 1402, but rather may be measures derived from the raw data. E.g. spectral efficiency is a measure of data rate per unit bandwidth. In such cases case the values of the derived indicator collected in the database 452 may be computed by the tool 454 or another intermediate algorithm inputting to the database 452.

Turning to the performance-influencing parameters, these may comprise any one or more of a variety of factors. For example, the one or more performance-influencing parameters in the database 452 may comprise any one of more of:

(a) a geographical location of the satellite terminal 412 (e.g. in terms of GPS coordinates, street address or postcode);

(b) an angle (elevation and/or azimuth) from which the terminal's antenna 114 "views" its satellite 110 in order to form the link 107 (i.e. at which angle is it pointed towards the satellite 110);

(c) an identifier as to which of multiple satellites 110 the satellite terminal 412 uses to form the link (in the case where the system comprises a fleet of more than one satellite 110);

(d) an identifier as to which of multiple beams 202 the satellite terminal 412 uses to form the link (in the case of a spot-beam satellite 110);

(e) an identifier as to which of multiple hubs 402 the satellite terminal uses to connect to the internet (e.g. which vendor's hub);

(f) a model and/or vendor of the modem 404;

(g) a carrier frequency band of the forward and/or reverse link 107F, 107R;

(h) a polarity of the forward and/or reverse link 107F, 107R;

(i) an identity of an installer who installed the satellite terminal 412;

(j) an installation date of the satellite terminal 412;

(k) a reported dish size of the antenna 114; (I) an identity of a downstream internet service provider providing the internet access; (m) a type of downstream internet service provider providing the internet access, e.g.

whether a SVNO (shared bandwidth virtual network operator) or a GVNO (guaranteed bandwidth virtual network operator);

(n) a type of subscription through which the internet access is provided (e.g. a service level); (o) an indication of an environmental condition experienced by the antenna (e.g. a weather condition, or climate);

(p) a reported length and/or type of the cable connecting the outdoor ubnti comprising the antenna and the indoor unit housing the modem (as this affect the achievable signal strength.

Any one or more of the above factors may be relevant to performance. Some have a direct influence on performance, e.g. geographical location (relative to beam coverage), beam (different beans perform differently), hub (different hubs perform differently), etc. Other factors have a more indirect influence on performance, but can be relevant nonetheless. E.g. identity of installer could be relevant in case an installer is consistently

underperforming. In this case terminals linked to that installer would be expected to achieve similar performance either as a fixed negative offset compared to expected theoretical levels (e.g. all of them -2dB from expected); or a similar error in reporting, e.g. trying to "cheat" by installing multiple terminals with bogus reported location (where the installation threshold is lower - the installation threshold being a threshold signal level which the installer must achieve upon installation). For instance twenty terminals in the exact same location would be a warning sign. Note that the above are just examples, and there are many other alternative or additional pieces of information about the terminals which may be relevant to assessing performance, whether as measures of performance or as factors which influence performance.

Some of the above pieces of information may be reported up-front when the satellite terminal 412 is installed, e.g. its geographic location, dish size, angle (elevation and azimuth), the frequency band of the satellite link being used, and/or the polarity if the link. These may be reported by the installer, or may be reported automatically by the terminal 412 to one of the data sources 1402, 452. In the case of an automatic report, this may either be instigated by the terminal 452 or in response to a query from an element of the network, e.g. from the gateway 104, tool 454 or an OSS (one of the intermediate data sources 1402). Other pieces of information that the operator may wish to acquire are not necessarily provided up-front at installation, but rather in an ongoing fashion, or at least during operation. These instead require a vendor-specific API or generic API in order for an element of the network such as the gateway 104 or OSS to query the desired information from the terminal 412. For example such information may comprise the performance indicator (or performance-related information from which the performance indicator is to be derived), such as the signal strength, data rate, traffic volume, signal-to-disturbance ratio, and/or error rate. Such information may be measured automatically by the satellite terminal 412 and reported automatically in response to a query from the network, e.g. from the gateway 104, tool 454 or OSS.

Whether reported by the installer or automatically by the terminal 412, or by any other means, any of the above items of data may be reported directly to the database 452 used by the tool 454, or else may be reported indirectly by being reported to one of the

intermediate data sources 1402 (e.g. OSS or NMS) and then aggregated onwards into the database 452 used by the tool 454 (e.g. based on the process summarized in Figure 15). Also, whether reported by the installer, automatically by the terminal 412 or by any other means, note that the data may be reported via any suitable network, e.g. via the Internet, or via a mobile cellular network. For instance the satellite terminal 412 may be configured to report the values of one or more of the items of data via the internet 102 and satellite link 107 when it first connects to the internet 102 via the satellite 107 upon installation, either automatically or being triggered to do so by the installed. And/or, one or more of the items of data may be reported by the installer via a mobile cellular connection from an installation app on his or her smart phone. The data in the database 452 thus comprises values of at least one performance indicator and one or more performance-influencing parameters for each of the satellite terminals 412 to be analysed. The analysis performed by the tool 454 (step S20 in Figure 14) is based on these items of data, and comprises at least two stages. The first is a "pre-analysis" based on the values of one or more of the performance influencing parameters for a plurality of the satellite terminals 412, in order to establish a frame of reference against which performance can be gauged. Then as a second stage, the values of the performance indicator are analysed against this frame of reference in order to identify one or more underperforming terminals (or more generally that are exhibiting anomalous performance - e.g. a dishonestly installed terminal may be over-performing compared to the expectation for that terminal, e.g. for a given dish size and geographic location). The idea is that whilst it is difficult to judge the performance of a given satellite terminal 412 in isolation, the collected data on other, related parameters such as location, dish size, beam, partner, etc., can be exploited in order to automatically derive a yardstick against which to judge the performance - either based on its circumstances, or in relation to other terminals with similar parameters, or both. In one embodiment of this, the "yardstick" is a metric referred to herein as the improvability metric. Given knowledge of one or more performance-influencing parameters of a given satellite terminal 412, it is possible to estimate (to some degree at least) an expected or potentially-achievable value of the performance indicator, e.g. an expected spectral efficiency, or an expected signal strength. For example, given knowledge of the geographic location of the satellite terminal 412, its (reported) dish size, and the beam distribution 202 (and if the terminal 412 is in an area with overlapping beams, knowledge of which beam the terminal 412 is using), then it is possible for the tool 454 to compute an (approximate) expected performance, e.g. expected signal strength or spectral efficiency, that the satellite terminal 412 should expect to experience over its respective forward or reverse link 107F, 107R. The tool 454 then automatically compares this against the current value of the performance indicator, e.g. current signal strength or spectral efficiency, to compute the improvability metric for the satellite terminal 412. For instance the improvability metric may be defined as the delta between the theoretical expected value and the actual value in the data 452, or the ratio of these. As a variant of this, the theoretical value could be replaced with the optimal (best achievable) value. The tool 454 automatically computes the value of the improvability metric for each of multiple (some or all) of the satellite terminals 412 for which data is available. The tool 454 then automatically identifies one or more of these satellite terminals 412 having a greater potential for improvement according to the metric. For instance, the tool automatically identifies the satellite terminals from amongst those analysed which fall in the top nth quantile of potential improvement according to the improvability metric, e.g. top 1% or top 5% greatest potential for improvement.

In embodiments, the expected performance in terms of the expected signal link

performance per terminal may be computed from only: the location (latitude and longitude), an identification of the beam 202 (including an identification of the satellite 110 if there are multiple satellites) and the dish size. In terms of the overall network throughput (relative carrier use), IP volume (bps) and/or link efficiency per terminal may also included in the computation. In general other parameters could be factored in as well to improve the estimate. Fewer parameters could also be used, if only a rough gauge of expected performance is acceptable (e.g. assume that all terminals in a given geographical area, or in a given beam, share a certain average or typical expected performance).

A particular example for determining the greatest potential for improvement per terminal is referred to herein as a "forward - theoretical average carrier use (KHz delta)" metric, which may be computed as follows.

(i) calculate the carrier each terminal 412 is using today (e.g. in terms of IP volume or spectral efficiency);

(ii) calculate how much the carrier use would have been if it was operating at its

theoretical level;

(iii) take (i) minus (ii) and focus on the results above zero - i.e. terminals that could be using less of a carrier if they would increase their spectral efficiency to its theoretical level (without affecting the IP volume usage of the end customer); and

(iv) compare each terminal's score with the hub average carrier use to determine a

relative use of the improvement - so for example, if the "forward - theoretical average carrier use (KHz delta)" score for a terminal is 50 and the average carrier use in its hub is 25, improving that terminal to its theoretical level would be equivalent of 50/25 = 2 "average performing" terminals in the hub. So improving this terminal would "make room" for another two average terminals.

However, it will be appreciated that more generally, any one or more performance- influencing parameters can be used to gauge an expectation as to performance, and there are a variety of ways of comparing this to the actual experienced performance (e.g. subtract or take a ratio) in order to provide a metric quantifying the theoretical potential for improvement. For instance, another example metric may be referred so as the "forward - theoretical (EsNo delta)". This is the delta between the current forward (outroute) EsNo (energy per symbol to noise power spectral density) and the expected theoretical Forward (outroute) EsNo calculated from the VSAT's reported beam, dish size and location (or more generally any other measure of signal strength could be used in place of the EsNo). According to this metric, VSATs 412 with values larger than zero are performing better than expected, whilst VSATs 412 with values smaller than zero are performing worse than expected. Values much larger or smaller than expected means that it is likely that the wrong dish size or location was reported for the VSAT 412. Another example metric may be referred to as the "theoretical - forward spectral efficiency (bps/Hz delta)". This is the delta between the current forward (outroute) spectral efficiency and the theoretical spectral efficiency (bps/Hz Delta) for the particular location, beam and dish size. This metric may be filtered to only show positive values, i.e. only showing VSATs 412 that are doing worse than the theoretically calculated spectral efficiency. The purpose of this metric is to show the potential improvements in spectral efficiency if a VSAT 412 would have increased its EsNo (e.g. re-aligned) to its theoretical level.

Another example metric may be referred to as the "optimal - forward spectral efficiency (bps/Hz delta)". This is the delta between the current forward (outroute) spectral efficiency and the optimum spectral efficiency (bps/Hz delta) if the VSAT 412 would have operated in the maximum modcod (modulation and coding) at all times (regardless of reported location or dish size). A value of 0 means that the VSAT 412 is already operating in the maximum modcod over the specified time period. The purpose of this metric is to show the potential improvements in spectral efficiency if a VSAT 412 would have increased its EsNo to its optimal level (by either realignment or increased dish size). The higher the modcod, the higher spectral efficiency one will get from the network. However, in order to maintain a high modcod one also needs to have a high signal strength, otherwise one will start losing packets and cause the network to retransmit (as there is too much noise in the signal). In embodiments the satellite terminals 412 will automatically select a suitable modcod based on its current signal strength, if the signal strength increases it will increase to a higher modcod. E.g. every terminal 412 has a lookup table mapping between Es/NO and modcod (or more generally signal strength and modcod).

Another example metric may be referred to as the "forward - optimal average carrier use (KHz delta)". This is the same as the "forward - theoretical average carrier use" but using the optimum carrier use instead of the theoretical value, i.e. disregarding the location and dish size - like the "optimal - forward spectral efficiency" metric above.

In further embodiments, the process is not (or not only) based on a theoretical improvability metric, but rather the values of the performance-influencing parameters of multiple terminals 412 are assessed together as a group in order to provide the frame of reference for performance. In this case the tool 454 conducts a filtering operation on the set of satellite terminals 412 for which data is available in order to filter them according to one or more of the performance-influencing parameters, leaving only a subset of satellite terminals 412 having the same or at least similar values of the one or more performance-influencing parameters in question. As the subset of satellite terminals 412 exhibit similar performance- influencing properties, it can be assumed (to some degree of approximation at least) that they should be expected to experience a similar performance over their respective forward and/or reverse links 107F, 107R, or to have a similar potential (achievable) performance. The tool 454 then automatically identifies one or more of the satellite terminals 412 having the worst performance in the subset according to the chosen performance indicator, e.g. signal strength or spectral efficiency. For example, the tool 454 may sort the terminals according to the performance indicator, e.g. signal strength or spectral efficiency, and identify the lowest nth quantile of worst performing terminals 412. Note that the two embodiments above may also be combined, so as to sort the subset according to the theoretical improvability metric and identify the terminals 412 in the subset having the greatest potential for improvement.

The tool 454 provides a user interface through which the user of the operator's terminal 450 can instigate the analysis. E.g. see Figure 5, to be discussed in more detail shortly. In embodiments, the user interface of the tool 454 may also enable the user to select which performance indicator to use, and/or which performance-influencing parameters to perform the filtering based on, and/or a range of values to filter out or leave in (pass) in the filtering, and/or the value of the quantile. But beyond this the tool 454 performs the actual computations involved in the analysis of the multiple satellite terminal 412 automatically (as a whole, without the user having to instigate the computations relating to each terminal 412 individually).

Once the underperforming (or anomalously performing) satellite terminals 412 are identified, whether based on having an anomalously low (or even anomalously high) performance within the subset or based on having the greatest potential for improvement according to the improvability metric, then the operator can instigate a certain action in order to upgrade or correct some aspect of the system relating to the under- or

anomalously-performing terminals 412 in question. This action may comprise, for example, upgrading the underperforming terminal 412, such as by installing a bigger dish, a more powerful transceiver or higher performing modem, or by installing a software upgrade. As another example, the action may comprise correcting some physical aspect of the system such as by correcting or replacing faulty equipment (e.g. faulty terminal 412, antenna 114 or cabling there between); or by repositioning the antenna 114, realigning the antenna 114, clearing an obstacle (e.g. a tree) in a line of sight between the antenna 114 and its satellite 110, and/or adjusting an installation threshold level. As another example, the action may comprise correcting a software bug in the terminal 412 or NMS; or correcting configuration information stored by the operator in relation to the terminal 412 in question (e.g. in the OSS), such as correcting a reported dish size of the antenna 114. The action may be instigated by sending a technician to perform the action in question, contacting the relevant partner (downstream ISP) to ask them to perform the action, contacting an end-user to advise him or her to perform the action, or even by remotely controlling the satellite terminal 412 (e.g. from the gateway 104) to take some automated course of action (such as to run a diagnostic or download a software upgrade). Another example of an automated action can be applied if a statistically significant amount of terminals 412 within the same beam are all performing below the installation threshold - in that case it is very unlikely that they are all miss-pointed, so the threshold could be changed automatically. Also, certain reported locations or dish sizes are simply impossible due to geographical coverage (laws of physics), which could also be corrected automatically.

As an example, the tool 454 may be used to identify anomalies such as inaccurate installation information. For instance, the tool 454 may be used to group the satellite terminals 412 geographically. Those terminals in the same geographical area (approximately the same beam coverage) and pointing at the same satellite 110 in the same direction (same azimuth and elevation), should be expected to exhibit similar performance. Based on this assumption, the tool 454 can be used to identify anomalous performance, such as anomalies in signal strength. One way this can occur is if the installer reports an incorrect dish size. When an installer installs a satellite terminal, he or she will be given an installation threshold level, which is a threshold signal level which the installer must achieve (say 8dB) upon installation. This threshold is function of the dish size of the antenna 114. The installer cannot complete the installation until he or she has met the threshold level assigned by the operator (e.g. a code is required from the operator to complete the installation, which will not be granted until the threshold is met). However, the installer may lie, saying the dish is smaller than it really is, in order to be given an easier to meet (lower) installation threshold level. By using the tool 454 to look for geographical anomalies in performance, it is possible to investigate and identify such cases and take action to correct this, e.g. updating the dish size in the OSS, and/or sending a technician to revisit the installation. Note that in the case of falsely reported configuration information (e.g. dish size and/or geographic location), the anomaly could be either that the terminal 412 in question is underperforming or over performing. Over performing becomes of interest when

performance is suspiciously high, for example if a terminal's signal level is +5dB compared to its expected level for its reported dish size and location (one would only expect this to be +/- ~1.5dB max) then there is probably something wrong with the terminal or the reporting. I.e. if the signal to or from the terminal 412 is much higher than the expected level (for its reported location and dish size - i.e. the installer lied about it) and much higher than neighbouring terminals 412 with the same reported configuration, then the terminal is over performing but likely due to an error or falsehood in the reporting by the installer - which is an anomaly. In general the dishonest or mistaken reporting of various items of configuration information relating to the satellite terminal 412 or its installation (dish size, location, etc.) may lead to an anomalously high performance compared to the expectation for the reported configuration data. Incorrect configuration data in turn means the operator cannot tell what signal strength to expect from the terminal, 412 e.g. for setting a signal strength threshold to be demanded of the termial. Other causes of over performance (compared to expectation) could be faulty equipment or a problem or bug in the NMS leading to corrupt data. An example of underperforming might be a terminal 412 that reaches its threshold at the time of install, but gradually degrades over time, which will be detectable as the threshold remains the same (has not moved) while neighbouring terminals 412 with the same configuration are on the same level as before (assuming enough statistically significant neighbours).

Another cause of anomalies is obstacles in the line of sight between the antenna 114 of the satellite terminal 412 and the satellite 110, e.g. a tree has gradually grown into the line of sight in the time since installation. By using the tool 454 identifying an anomalously low performance of a given satellite terminal 412 compared to its neighbours, then the cause can be investigated and, if it turns out to be an obstacle such as a tree, then action cane be taken to clear the obstacle (e.g. trimming the tree).

Some example details of the tool 454 and its user interface will now be discussed in more detail in relation to Figures 5 to 13. Some example use cases are then discussed with reference to Figures 16 to 20. Some example studies are then discussed with reference to Figures 21 to 25.

Figure 5 gives an example of what the user interface (Ul) of the tool 454 may look like in embodiments. As illustrated, the user interface may comprise a filter & metrics option (e.g. filter tab) 600, an analytics option (e.g. tab) 900, an anomalies option (e.g. tab) 1200 and a beam coverage option (e.g. tab) 1300. N.B. in the following description of the tool Ul, the "user" refers someone acting for the operator, not an end-user of the terminals 412. Figure 6 shows an example of what happens if the user selects the filter & metrics option (e.g. tab) 600. As a first step, the user can select and/or combine any type of filters to look at the VSATs 412 he/she is interested in (or alternatively the user may omit this step to look at all VSATs). The user may for example filter down by partner, partner type (e.g.

SVNO/GVNO), satellite, hubs, modem, SLA, bandwidth plan, dish size, installer and/or installation date. The use may further specify ranges for performance indicators such as signal (dB), throughput (GiB/day) or theoretical signal (delta dB) in order to detect key VSATs (e.g. low signal/spectral efficiency but high usage).

As a second step, the user may select the metric he/she wants to analyse. For example this could be forward/return signal (dB), spectral efficiency (bps/Hz), and/or IP Volume

(GiB/day). Alternatively or additionally the user may select to analyse average carrier usage (IP volume / spectral efficiency, in KHz) in order to determine how much of a carrier each VSAT is occupying. E.g. the user may select to analyse optimal carrier usage - i.e. the delta between current carrier usage compared to the carrier usage that would have been achieved if the terminal would have operated at maximum spectral efficiency. And/or, the user may select to analyse theoretical carrier usage - i.e. the delta between current carrier usage compared to the carrier usage if the terminal would have operated at least as high as the calculated level in its location, for its (reported) dish size and beam. As another alternative or additional option, the user may select to analyse the forward-theoretical (delta dB) metric - which compares the VSATs current signal level with the theoretical signal level. In this case values >0 mean better than expected, whilst values < 0 mean worse than expected. Note: the first and second steps above may in general be performed in either order. Further, in variants of the above the filter and metrics features could be two separate options (e.g. two separate tabs), or one of them may even be omitted.

Figure 7 shows an example of what the user interface of the tool 454 displays after the user has selected the desired filter(s) and/or metric(s). After selecting any combination of filter(s) a map is updated with all VSATs matching the criteria with the selected metric. In the illustrated example, the Ul shows the expected signal level vs. the theoretical signal level (>0 means better, <0 means worse). In embodiments, single VSATs are displayed as squares, with the metric value on top (e.g. -0.21 below) and the VSAT site ID below (32100067) (or vice versa, or in some other relative placement). In embodiments groups of multiple VSATs or "clusters" are displayed as a circle, with the displayed metric value either being the average, min or max of the cluster (e.g. -0.10), and the value below being the number of VSATs in the cluster (e.g. 19). In embodiment, the colour of the circle or square (or other such graphical element) indicates the value of the metric.

More generally, any schema may be used to place graphical elements on a map to indicate satellite terminals 412 or clusters thereof at their respective locations on the map, each in association with an indication of an identity of the respective satellite terminal 412 and an indication of the respective value(s) of the analysed metric(s) or performance indicator(s).

Figure 8 illustrates another part of the user interface of the tool 454 which may be summoned by the user by selecting a specific one of the satellite terminals 412 or clusters of terminals in the Ul, e.g. by clicking on or touching a single VSAT (square) or right clicking on a VSAT cluster (circle). Doing this displays more detailed information, such as: average signal level over time, traffic volume over time, operational Information, location,

Job details, installation report, customer details, usage profiles per day of the week, usage profile per hour of the day, and/or value(s) one or more performance indicators. Data is either calculated for the single VSAT or as an average or range if selecting multiple VSATs. In embodiments, to display details for all VSATs, the user may zoom out to the maximum level and click on the cluster. Figure 9 illustrates an example of a part of the Ul of the tool 454 which may be summoned when the user selects the analytics option (e.g. tab) 900. This provides broken down details of what is visible on screen, for example: the highest and/or lowest VSATs for the selected metric (e.g. as a bar chart); a breakdown per filter property; and/or a grouping by any of the filters (e.g. partner by spectral efficiency, hub by volume, etc.). In embodiments the user may update this by simply zooming or panning the map. In embodiments the user may export this to a file of a format such as CSV in order to analyse further (in e.g. Excel). The example in the left-hand panel of Figure 9 shows 504 VSATs sorted by the theoretical gain in carrier usage improvement, and the top 7 VSATs with the highest potential of improvement, i.e. how much more efficient the network would be if the spectral efficiency of these VSATs were improved. In embodiments, clicking on a VSAT, "group by" option, or "quantile" option opens the individual VSAT(s).

Figure 10 illustrates an example of a part of the Ul of the tool 454 which may be summoned when the user selects the "group by" option. The "group by" feature allows for grouping visible VSATs by any of their properties (e.g. partner, hub, installer, etc.). Results can be displayed as either an average per VSAT (e.g. signal level) or total sum (e.g. bytes In/Out for a group). In embodiments this feature may only show the N highest or lowest results, e.g. only the high or lowest seven, fifteen, twenty-five, fifty or one-hundred results (and how many to display may be a user option). The "group by" feature may also provide the user with the option to sort by either metric (total value) or VSATs (the number of VSATs in the group). The example in Figure 10 shows: the average "forward - theoretical signal delta" (i.e. delta between expected and actual signal level per VSAT >0 = good <0 = bad), grouped by partner, sorted from low to high (i.e. worst averages), and showing the 25 worst performing. E.g. "ICT Telekom (815) -0.92" means that the partner "ICT Telekom" has 815 VSATs with an average signal delta of -0.92 dB per VSAT.

Figure 11 illustrates an example of a part of the Ul of the tool 454 which may be summoned when the user selects the "quantile" option. The "Quantile" feature allows the user to sort VSATs by quantile (e.g. top x% or bottom y%), high or low for the selected metric. In embodiments, the user can select to display results either by the percentage (%) of the total number of VSATs, by the number of VSATs (same but with absolute value) or by threshold (the threshold that the metric has to reach to enter that group). The example of Figure 11 shows the top % VSATs by "forward - optimal average carrier use" (i.e. how much less carrier usage a VSAT could occupy theoretically by a better alignment and/or larger dish). E.g. focusing on the top 1% worse VSATs will gain 17.78% of the theoretical improvements. Focusing on the Top 20% of VSATs yields 79.74% of all theoretical improvements.

Figure 12 illustrates an example of a part of the Ul of the tool 454 which may be summoned when the user selects the anomalies option (e.g. tab) 1200. The "anomalies" tab provides information about VSATs that has been flagged up as an "anomaly" by the VMAP system due to worse than expected signal levels, for instance: an "esnodiff" anomaly may be flagged if the signal is decreasing over time, or a "neighbour" type anomaly may be flagged is the VSAT is performing worse than neighbouring VSATS (e.g. <50km). In embodiments, each anomaly is categorized with a severity (CRITICAL/HIGH/MEDIUM/LOW). In

embodiments the user may select to combine the anomalies feature with one or more filters. In embodiments VSAT anomalies may also be shown as a banner when opening the VSAT or grouped VSAT view.

Figure 13 illustrates an example of a part of the Ul of the tool 454 which may be summoned when the user selects the beam coverage option (e.g. tab) 1300. The beam coverage tab allows one of several satellite beams to be plotted on the map under each VSAT or each cluster. This allows the user to visually compare the actual measured signal strength to expected signal strength, and thereby readily detect any discrepancy (e.g. VSAT colour >= beam colour). In embodiments this may be combined with setting the "cluster" merge type to minimum instead of average. In embodiments the user may select (e.g. right click) anywhere on map to find out what beam has coverage in that location. In embodiments, the Ul may allow plotting of multiple beams simultaneously.

Figures 16-18 illustrate a first example use case. Here the tool 454 is used to answer the question, how could the spectral efficiency be optimized for a particular satellite 110. The user uses the tool 454 to look at 9299 VSATs for a particular provider or vendor only, active between 12 Jan 2016 and 22 Feb 2016. As a first step (Figure 16), the tool 454 is used to identify the average network spectral efficiency. To do this the user select "Forward Spectral Efficiency" and zooms out to view the average: 1.68 bps/Hz. As a second step (Figure 16), the user changes the metric to "Theoretical - Forward Spectral Efficiency (bps/Hz delta)" to determine the total average improvement per VSAT: 0.07 (bps/Hz) / VSAT. The total theoretical improvement potential (assuming same location and dish size - only realigning antennas) = (1.68+0.07) / 1.68 = 4.16%. The user may also change the metric to "Optimum - Forward Spectral Efficiency (bps/Hz delta)" to determine the total average optimum improvement per VSAT: 0.29 (bps/Hz) / VSAT. The total optimal improvement potential (also assuming the location could be wrong or dish size upgraded) = (1.68+0.29) / 1.68 = 17.2%.

As a third step (Figure 17), the user uses the tool 454 to look at spectral efficiency per VSAT using "Quantile" analysis: target the "top X %" of VSATs (e.g. the worst aligned VSATs).

For the theoretical metric only (max improvement 4.16%): improving the top 1% (92 VSATs) yields an 11.14% of the total improvement => (4.16% * 11.14%) = 0.46%, or improving the top 5% (460 VSATs) = 33.2% of total improvements => 1.38%, or improving the top 20% (1889 VSATs) = 74.89% of total improvements => 3.12%. Including the optimal improvement metric (max improvement 17.2%), this yields an improvability of: top 1% (93) = 3.75% => 0.65%, top 5% (465) = 13.85% => 2.38%, top 20% (1860) = 41.95% => 7.21%.

In a fourth step (Figure 18), the user opens individual VSATs in the "top" clusters and determines the best way of improving that VSATs spectral efficiency, e.g. increased dish size, re-alignment, or shut down the VSAT. This may be determined by the user based on the results, or alternatively in some embodiments the tool 454 may propose one or more possible improvements or remedies automatically.

Figures 19-20 illustrate a first example use case. Here the tool 454 is used to answer the question, how could the carrier usage (IP volume or spectral efficiency) be optimised for a particular satellite. The user uses the tool 454 to look at 8524 VSATs for a particular provider or vendor only, active between 21 Jan 2016 and 22 Feb 2016 (fewer than the spectral efficiency use case, i.e. the first example use case above, as here VSATs with no data traffic are being filtered out).

In a first step (Figure 19), the tool 454 is used to identify the average network carrier usage. To do this the user selects "Forward Average Carrier usage" and zooms out to view the average: 48.74 Hz. In a second step (Figure 19), the user selects to determine the

"Theoretical" and "Optimum" carrier usage delta. The "Forward - Theoretical Average Carrier Use (KHz Delta)" metric is 2.58 Hz per VSAT => 5.58% improvement possible. The "Optimum - Theoretical Average Carrier Use (KHz Delta)" metric is 7.18 Hz, => 17.2% improvement possible (the same as for spectral efficiency - as expected).

In a third step (Figure 20), the user uses the tool 454 to looks at carrier usage efficiency per VSAT using "Quantile" analysis: by targeting the "top X %" of VSATs (e.g. the worst aligned VSATs with the highest usage). For the theoretical metric only (max improvement 5.58 %), improving the top 1% (85 VSATs) yields 26.28% of the total improvement => 1.46%.

Improving the top 5% (424 VSATs) = 58.71% of total improvements => 3.27%. Improving the top 10% (847 VSATs) = 77.77% of total improvements => 4.34%. Including the optimal improvement metric (max improvement 17.2%), this yields an improvability of: top 1% (93) = 14.25% => 2.45%, or top 5% (427) = 36.73% => 6.31%, or top 10% (853) = 52.88% => 9.09%. In a further step, the user or tool 454 draws a conclusion: much larger gain per VSAT vs. only looking at spectral efficiency usage.

Figure 21 illustrates an example study of spectral efficiency improvements (bps/Hz) using the tool 454. The study looks at how the network could be improved by increasing spectral efficiency, looking at 17159 VSATs (for a particular provider or vendor only) active between 15 Jan 2016 and 15 Feb 2016. It is found that the average network spectral efficiency is 1.74 bps / Hz. A question then is, how many VSAT does it take to be improved (e.g. by larger dish size or realignment) to bring to the highest possible spectral efficiency by focusing on the worst VSATs? An answer determined is the tool 454 is determined by exporting aggregated VSAT data into a spreadsheet and generating a report via pivot tables. Based on this it is determined that the maximum spectral efficiency for the provider or vendor in question is 1.97 bps / Hz, i.e. the theoretical maximum improvements are ~13.32% (=1.97/1.74). A conclusion drawing is that it would be desirable to target a fairly high number of VSATs to reach improvements; targeting the 2% of bottom VSATs (~320) gives a 1% increase in spectral efficiency, and ~ 900 VSATs (5.6% of fleet) need to be targeted for a 2% increase. Figure 22 illustrates a study of IP volume per VSAT (GiB/day) using the tool 454. The study is to determine the IP utilisation of the network per VSAT (same data set), i.e. who is using most of the operator's IP capacity grouped by volume (FWD). It is found that the average IP volume is 0.57 GiB / day with VSATs between 0.00 to 16.28 GiB / day. A question is then, how could focusing on high IP throughput terminals increase room in the network. An answer is determined using the tool 454 by exporting aggregated VSAT data into and generating and generate report via pivot tables. Based on this, a conclusion drawn is that few VSATs are using a majority of the operator's IP throughput (e.g. "80/20 rule"), while 70% of VSATs with the lowest IP volume are only using 23% of the network. The top 10% of VSATs are responsible of ~50% all traffic. The top 2% of VSATS are using ~20% of all IP traffic (~300 VSATs).

Figure 23 illustrates an extension or variant of the study of Figure 22. Here it is asked, what if one looks at Average Carrier Usage instead of IP volume? I.e. combining IP volume and spectral efficiency data (in terms of IP volume or spectral efficiency) (bps / (bps/Hz) => Hz). In this case it is found that the average network carrier usage is 32.53 KHz, with VSATs between 0.00 - 1033.70 KHz. A conclusion is that the curve is similar to IP volume usage.

One issue is that the operator may not be able to just shut down VSATs because they are using a high amount of spectrum and/or IP throughput as they might be paying for a higher bandwidth plan. Instead the operator may desire a way of determining the potential carrier usage improvement for each VSAT.

With this in mind, Figure 24 illustrates a study of Optimal Average Daily Carrier Usage (Hz) (in terms of IP volume or spectral efficiency) using the tool 454. Here, instead of looking at average carrier usage, the study looks at how much each VSAT could theoretically increase its carrier usage if operating at the highest spectral efficiency. Example: terminal X operates at an average carrier usage of 60KHz with an average spectral efficiency of 1.5 bps/Hz. If the terminal would have operated at a higher spectral efficiency (e.g. better alignment, larger dish size, and/or different hardware) it could potentially reach a spectral efficiency of 1.8 bps/Hz, meaning its carrier use would be 50 KHz. The delta is therefore 60-50 = lOKHz, i.e. this is how much resource would be freed up if the terminal would operate at the highest possible spectral efficiency (if a terminal is already at maximum spectral efficiency, the improvement potential will always be 0). This will especially highlight terminals with a low spectral efficiency but with a high IP throughput will have a high improvement potential and vice versa. In the example shown, the maximum improvement potential is 13.7% (same as spectral efficiency).

Note again there are possible variants of the metric, e.g. optimal average carrier use (using network maximum spectral efficiency regardless of where the terminal is located), or theoretical average carrier usage (using the theoretical maximum for the VSAT's current dish size and location).

Figure 25 illustrates results of the study of Figure 24. The maximum improvement potential is 13.7% (same as spectral efficiency). However by looking at carrier use only 0.3% of all VSATs (~50), this can improve the total network spectral efficiency by 1.2%. Just 2.3% (~320) of the bottom terminals yields a 3.9% improvement. Conclusion: huge improvements are achievable by just focusing a small amount of VSATs.

It will be appreciated that the above embodiments have been described by way of example only. Other variants may become apparent to a skilled person once given the disclosure herein. The scope of the present disclosure is not limited by the example embodiments, but only by the accompanying claims.