WO2017021218A1

WO2017021218A1 - Satellite operations support system

Info

Publication number: WO2017021218A1
Application number: PCT/EP2016/067797
Authority: WO
Inventors: Scott Richardson
Original assignee: Avanti Communications Group Plc
Priority date: 2015-07-31
Filing date: 2016-07-26
Publication date: 2017-02-09
Also published as: GB2540945B; GB2540945A; GB201513517D0

Abstract

An operations support system, for use in a satellite system comprising multiple resources in the form of one or more satellites, one or more hubs, and a plurality of client systems. The operations support system comprises a database for storing respective information on each resource, and is configured to query the respective information from some of these resources via a provider-specific application programming interface of a provider of each respective resource, and to thereby store the respective information in a database. The operations support system further comprises a discovery mechanism configured to detect when a new one of the resources is added to the satellite system for which a providerspecific application programming interface is not currently available for querying the respective information from the new resource, and in response to use a generic protocol to query the respective information from the new resource.

Description

Satellite Operations Support System

Technical Field The present disclosure relates to an operations support system for use in a satellite 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 each of a plurality of client systems and a gateway earth station ("the gateway" for short); and the gateway connects to an internet, i.e. a wide area internetwork such as that commonly referred to as the Internet (capital I). Thus each of the client systems is able to gain access to the internet via the satellite link with the gateway, and the connection between gateway and internet. Each client system could be anything from an individual unit in the home, to a local network serving a whole office, school, hospital, village, community or the like.

The operator also typically runs an operations support system (OSS), which is a computer system comprising a database of various information on the client systems involved. This information may comprise for example: a serial number of the client system, an IP address of the client system, a frequency of the satellite link that the client system is using, billing information, and contact details for a user of the client system (street address, email address and/or telephone number). Traditionally, OSS databases had to be maintained manually, by human operators being informed of the information and manually entering into the computer system. Nowadays it is possible for the database to be maintained in a partially automated manner, by using an application programming interface (API) to interface between the OSS and the client systems (via the gateway and satellite link) in order to query the respective information to be stored in the OSS database.

Summary

However, a difficulty with the above is that the satellite system as a whole may involve resources from multiple different equipment providers, e.g. multiple different vendors. This will require a different API for each vendor or provider. For example, the operator of the gateway service is typically an upstream ISP (internet service provider), who does not deal directly with end-user consumers. Rather, the operator sells bandwidth to multiple downstream ISPs, who in turn sell bandwidth to the end consumers. Typically different downstream ISPs will choose to use the equipment of different vendors (or at least it is desirable to allow them the option to do so). Thus at least some different downstream ISPs will each operate according to a different proprietary technology, each having its own hub in the gateway provided by a different respective equipment vendor, and each using different corresponding, vendor-specific client systems at the consumer end accordingly. If each vendor provides a different proprietary model of the equipment used in its respective client systems, then the OSS of the upstream ISP will require a different API for the equipment of each of the vendors. Unfortunately when a new vendor supplies equipment for use in the satellite system, it can often take many months before the vendor makes its API available, or before the operator of the gateway service can integrate the vendor's proprietary, non-standard API. Therefore at the moment, the operator (upstream ISP) has to wait for an API to become available from the vendor in order to be able to acquire the required information automatically, which can increase the lead-time by several months. Alternatively it may be possible to launch a service for the new equipment without the API, but in this case the operator has to implement a workflow for having the information being reported by the installer of each client system and then this being entered in the OSS database manually This is a clumsy and labour-intensive approach, and increases expenses because greater expertise and yet another management system will be needed.

Similar issues could equally occur in other scenarios. For example, an existing vendor could launch a new version of their client equipment which may need a new API in order for the OSS to interface with it. Further, such issues could also arise when adding other resources, not just client systems. E.g. in the future, internet access could be provided from a given system via multiple different satellites such as small satellites (minisatellites),

microsatellites, picosatellites, femtosatellites and/or cube sats from multiple different providers.

It would be desirable if the OSS could interface to a new resource in the system even before a vendor-specific (or generally provider-specific) API is available.

According to one aspect disclosed herein, there is provided an operations support system, for use with a satellite system comprising multiple resources in the form of one or more satellites, one or more hubs, and a plurality of client systems, each of the hubs providing a respective group of the client systems with access to an internet by using at least one of the satellites to communicate traffic between the internet and the respective client systems via a satellite link between the hub and each of the respective client systems; the operations support system comprising: a database for storing respective information on each respective one of a plurality of said resources, wherein the operations support system is configured to query the respective information from some of said plurality of resources via at least one provider-specific application programming interface of a provider of each respective resource, and to thereby store the respective information in said database; and a discovery mechanism configured to detect when a new one of said resources is added to the satellite system for which a provider-specific application programming interface is not currently available for querying the respective information from the new resource, and in response to use a generic protocol to query the respective information from the new resource and thereby store the respective information in said database, the generic protocol being common to the new provider and other parties.

In embodiments, the queried information may comprise one or more of: a serial number of the respective resource; a model type of the respective resource; a firmware version of the respective resource; a signal-to-noise ratio, error rate, or other measure of quality of the satellite link used by the respective resource; a quantity of the traffic sent and/or received by the respective resource over the satellite link; a transmit and/or receive power of the respective resource on said satellite link; an uptime of the resource; a reboot history of the resource; a default gateway for use in the communication of said traffic; an ARP cache for use in the communication of said traffic; a DNS for use in the communication of said traffic; an IP mask for use in the communication of said traffic; one or more NAT rules for use in the communication of said traffic; one or more port forwarding rules for use in the

communication of said traffic the resource; one or more QoS rules for communicating for use in the communication of said traffic; and/or a cable length between an indoor unit and an outdoor unit of the respective resource.

In embodiments, the resources for which the respective information is stored in said database may at least comprise a plurality of the client systems; the resources queried via a provider specific application programming interface may at least comprise some of the plurality of client systems; and the discovery mechanism may be configured to detect the new resource, and perform said querying using the generic protocol, at least when the new resource is a new one of the client systems.

In embodiments, said one or more satellites may be multiple satellites, and: the resources for which the respective information is stored in said database may at least comprise a plurality of the satellites; the resources queried via a provider specific application programming interface may at least comprise some of the plurality of satellites; and the discovery mechanism may be configured to detect the new resource, and perform said querying using the generic protocol, at least when the new resource is a new one of the satellites. In embodiments, said one or more hubs may be a plurality of hubs, and: the resources for which the respective information is stored in said database may at least comprise information a plurality of the hubs; the resources queried via a provider specific application programming interface may at least comprise some of the plurality of the hubs; and the discovery mechanism may be configured to detect the new resource and perform said querying using the generic protocol at least when the new resource is a new one of the hubs.

In embodiments, the discovery mechanism may be configured to perform said detection by monitoring the traffic for a new address.

In embodiments, said generic protocol may be SNMP or SSH.

In embodiments, for each of one or more of the resources, the discovery mechanism may be further configured to use one or more of the application programming interfaces to test whether or not the resource supports each of one or more control capabilities.

In embodiments, the discovery mechanism may be further configured to assist in a partially automated installation of the new resource.

In embodiments, the discovery mechanism may be configured to detect the new resource and perform said querying using the generic protocol at least when said new resource is from a new provider for whom a provider-specific application programming interface is not currently available for querying the respective information.

In embodiments, the discovery mechanism may be configured to detect the new resource and perform said querying using the generic protocol at least when said new resource is a new model or type of resource provided by an existing provider, for which model or type a provider-specific programming interface is not currently available.

In embodiments, the internet to which access is provided by at least one of the one or more hubs may be the Internet. In embodiments, said monitoring may comprise monitoring for a new IP address in the traffic. According to another aspect disclosed herein, there is provided a gateway earth station comprising the operations support system, and the one or more hubs.

According to another aspect disclosed herein, there is provided a satellite system

comprising the gateway earth station, the one or more satellites, and the client systems.

According to another aspect disclosed herein, there is provided a computer program product, for use in a satellite system comprising multiple resources in the form of one or more satellites, one or more hubs, and a plurality of client systems, each of the hubs providing a respective group of the client systems with access to an internet by using at least one of the satellites to communicate traffic between the internet and the respective client systems via a satellite link between the hub and each of the respective client systems; the computer program product comprising code embodied on a computer-readable medium and configured so as when executed to perform operations of: accessing a database for storing respective information on each respective one of a plurality of said resources; querying the respective information from some of said plurality of resources via at least one provider-specific application programming interface of a provider of each respective resource, and thereby storing the respective information in said database;

detecting when a new one of said resources is added to the satellite system for which a provider-specific application programming interface is not currently available for querying the respective information from the new resource; and in response to said detection, using a generic protocol to query the respective information from the new resource and thereby store the respective information in said database, the generic protocol being common to the new provider and other parties. According to another aspect disclosed herein, there is provided a method, performed in relation to a satellite system comprising multiple resources in the form of one or more satellites, one or more hubs, and a plurality of client systems, each of the hubs providing a respective group of the client systems with access to an internet by using at least one of the satellites to communicate traffic between the internet and the respective client systems via a satellite link between the hub and each of the respective client systems; the method comprising: accessing a database for storing respective information on each respective one of a plurality of said resources; querying the respective information from some of said plurality of resources via at least one provider-specific application programming interface of a provider of each respective resource, and thereby storing the respective information in said database; detecting when a new one of said resources is added to the satellite system for which a provider-specific application programming interface is not currently available for querying the respective information from the new resource; and in response to said detection, using a generic protocol to query the respective information from the new resource and thereby store the respective information in said database, the generic protocol being common to the new provider and other parties.

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 is a schematic illustration of a satellite system including equipment of a newly added vendor;

Figure 6 is a schematic block diagram of a gateway earth station including a discovery mechanism; and

Figure 7 is a schematic block diagram showing a relationship between an operations support system, satellite hub and client system.

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) 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 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, 112B 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 the satellite 110 and/or gateway 104 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.

This is illustrated in more detail in relation to Figures 1, 4A and 4B.

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 116. 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 112 A, 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 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. The operator of the gateway 104 (or gateway service, i.e. the upstream ISP) may wish to run an operations support system (OSS) 450 which supports processes such as maintaining network inventory, configuring network resources, fault management, traffic management, and/or managing one or more other aspects of the service. The OSS 450 may be implemented at the gateway 104, or may be otherwise connected to it, e.g. via the internet 102 or a separate network. Note also that the OSS 450 (including the various elements 452, 454, 602 discussed below) may be implemented in one or more server units, at one particular geographic site or distributed over a plurality of geographic sites (e.g. by being connected together over the internet 102).

In order to support one or more of the above-mentioned responsibilities of the OSS 450, the OSS comprises a database 452 where it stores information ("metadata" or "meta information") on the various resources of the satellite system (where a "resource" refers herein to a particular instance of a client system 112, hub 402 and/or satellite 110). For example, the database may store information on each of: some or all of the client systems 112; and/or some or all of the satellites 110 used in the system; and/or some or all of the hubs 402. The stored meta information may comprise for example:

• a serial number of the respective resource (e.g. serial number of the IDU 420 and/or ODU 422);

• a MAC address of the respective resource (e.g. of the IDU 420);

• an IP address of the respective resource (e.g. of the IDU 420);

• a frequency of the satellite link 107 used by the respective resource (on the forward link 107F and/or reverse link 107R);

• a polarity of the satellite link 107 used by the respective resource (if distinct

polarization channels are used e.g. left or right circular, or horizontal or vertical);

• a transmit and/or receive power of the resource;

• a serial number of the resource;

• a model type of the resource;

• a firmware version used by the resource;

• contact details for a user or owner of the respective resource (e.g. postal address, email address, phone number, and/or personal name);

• billing information for billing a user of the respective resource (e.g. card or bank details, and payment plan); • a quantity of traffic used by the respective resource (e.g. a number of bytes sent by the resource over the satellite link 107, and/or a number of bytes received by the resource over the satellite link 107;

• a signal-to-noise ratio, error rate, indication of packet errors, or other measure of quality of the satellite link experienced by the respective resource;

• an uptime of the resource (up to the current time);

• a reboot history of the resource;

• a default gateway for communicating with the resource;

• an ARP (address resolution protocol) cache for communicating with the resource;

• a primary DNS (domain name server) for communicating with the resource;

• an IP mask used by the resource;

• NAT (network address translation) rules for communicating with the resource;

• port forwarding rules for communicating with the resource;

• QoS (quality of service) rules for communicating with the resource;

• a capability of the respective resource (e.g. of the IDU 420), e.g. whether a particular aspect of the IDU 420 can be controlled remotely, and if so what aspects; and/or

• a length of the cable connecting between the IDU 420 and ODU 422.

For instance, the serial number is a unique ID of the resource itself (the actual equipment), and may be used by the operator of the gateway service to trace and/or monitor the resource. (The MAC and IP addresses are not necessarily unique, e.g. the resource could sit behind more than one network interface each with a different MAC address.)

The OSS 450 will collect together such meta information on some or all of the client systems 112 currently connected, registered or subscribed to the system.

Some of these pieces of information are already provided up-front when the client system 112 is installed, e.g. the contact information, billing information, and the frequency (and if applicable polarity) of the satellite link being used. Furthermore, some others of these pieces of information are visible to the OSS at the IP layer, e.g. the IP address. However, other pieces of information that the operator of the OSS 450 may wish to acquire are not necessarily provided up-front and are not available at the IP layer. These

conventionally instead require an API from the vendor of the resource in order for the OSS to query the desired information. For example such information may comprise the serial number of the resource (e.g. serial number of the IDU 420 and/or ODU 422), and/or the cable length between the IDU 420 and OUD 422. Another example of information that (conventionally) requires a vendor-specific API to query is signal-to-noise ratio, error rate or other such measure of quality (which may be collected at the OSS e.g. for quality control and/or diagnostics purposes). This is an attribute of the physical layer, and different resources may have different vendor-specific ways of measuring and/or reporting this.

Note that these are just examples, and there are many other alternative or additional pieces of information about the resource which the operator of the OSS 450 may wish to query from the resource, e.g. any one or more of these specified by the TR-069 CPE WAN

Management Protocol (CWMP). Such information may be categorized into two types: I) generic, and II) vendor-specific. The number of potential parameters is considerable as borne out by the TR-069 specification and could number in the many hundreds, but some further examples in the generic category include: IP masks, default gateway, ARP cache, primary DNS, bytes received, byes sent, packet error, uptime, reboot history, NAT rules, port forwarding rules, QoS rules, etc. Vendor-specific may include: model type, firmware version, transmit power, receive power, etc.

In order for the OSS 450 to be able to automatically gather and/or maintain such meta information in its database 452, each of a plurality of the vendors A, B... provides the OSS operator with a respective API (application programming interface) 454a, 454b for interfacing with its respective model or models of (proprietary or vendor-specific) client system 112a, 112b... The OSS 450 is configured to use each of the APIs 454a, 454b to communicate with the respective subset of client systems 112A, 112B of the corresponding vendor A, B... in order to query the desired meta information from each of the individual client systems 112. That is, the OSS uses the relevant API 454a, 454b to send an information request to the client system 112a, 112b... in question (via the respective hub 402a, 402b...) and satellite link 107 according to a suitable protocol that will be recognised by the respective type of client system 112A, 112B as a request to return information, and that will be acted upon accordingly. In response, the client system 112a, 112b... returns the requested meta information to the OSS 450 (again via the respective hub 402a, 402b... and satellite link 107), and upon receipt of this the OSS 450 stores the returned information in a corresponding field in its database 452.

Note: the arrangement shown in Figure 6 assumes that the OSS is equipped with the vendor-specific APIs for the client systems 402. This is indeed one implementation, but is not necessarily the case in all possible embodiments. Figure 7 illustrates two alternatives: in one case (a) the OSS 450 comprises the client API 454 for communicating with the client system 112, and uses this to communicate with the client system 112 for the purposes disclosed herein (though still physically communicating via the hub 402). Alternatively however, as shown in case (b) of Figure 7, the OSS 450 itself need not comprise the client API 454. Instead, it may comprise an API 702 of a hub 402, and the hub 402 comprises the vendor-specific API 454 for the client system 112. Hence in this case, in order to perform the various communication disclosed herein, the OSS 450 communicates with the hub 402 via the hub API 702, and the hub 402 relays the communications by communicating with the client system 112 via the client API 454. A combination of these two approaches is also possible, e.g. if the OSS 450 is equipped with the API for one or more of the client systems or providers while one or more of the hubs 402 are equipped with one or more others. The following examples may be described by reference to Figure 6, but it will be appreciated that the arrangement shown in Figure 6 is not necessarily limiting.

By whatever means implemented, it is therefore possible for the OSS 450 to query various information from a client system 112 (or other resource) by means of a vendor specific API 454. However, there is a difficulty in that not all vendors make their APIs available to the operator in a timely fashion. In fact, it can add several months' lead time waiting for an API from a new vendor who is newly joining the satellite system. Figure 5 illustrates a new client system 112n of a new vendor N being added to the system, along with a corresponding hub 402n of the new vendor at the gateway 104. Even though the hub 402n of the new vendor N is present, the OSS 450 does not necessarily have the relevant API of that vendor allowing the OSS 450 to query the meta information desired for its database 452. Or in another scenario, the new client system 112n could even be a new model of client system 112 of an existing vendor A or B provided by the vendor or third party, but where the existing vendor has not made a suitable API available to the operator for querying the desired meta information for the OSS database 452.

As yet another example, it could be the case that the satellites 110 via which the internet access is provided comprise multiple satellites provided by different providers, and the OSS 450 may collect meta information on the various satellites in its database 452, but a new provider may not make a suitable API available for this as soon as a new satellite is in orbit. This scenario may increasingly arise with the advent of satellite systems built around a large number of small sats, microsats, nanosats, picosats, femtosats, cube sats or the like.

It would be desirable to make the compiling and/or maintenance of the meta information in the database 454 less reliant on receiving an API 454 from the vendor or provider of the resources in question, even when the resource (e.g. client system 112) being queried is highly proprietary or for any other reason vendor-specific.

The following is based on a recognition that many items of equipment such as client systems 112 often come equipped with a generic (application layer) protocol such as SNMP (Simple Network Management Protocol), SSH (Secure Shell), HTTP or Telnet that could be used instead of an API to query some or all of the meta information for the OSS database 452.

Accordingly, as illustrated in Figure 6, according to embodiments disclosed herein, the OSS 450 is additionally equipped with a discovery mechanism 602. The function of this is twofold.

Firstly, the discovery mechanism is coupled between the hubs 402 and the internet 102, e.g. being coupled to the internet-side interconnect 109 of the gateway 104, so as to monitor the traffic between the internet 102 and one or more or the hubs 402a, b, ... n. Particularly, the discovery mechanism 602 is arranged to monitor the traffic for new network addresses (e.g. any new IP addresses) that does to correspond to an IP address of a resource already known in the OSS database 452, and for which an API 454 does not currently exist in the OSS 450. Thus the discovery mechanism is configured to automatically detect when a new resource (e.g. new client system 112n) is added to the system from a new provider (e.g. new vendor N).

Secondly, the discovery mechanism 602 is configured so as, in response to this detection, to send a request message to the relevant resource, e.g. to the new client system 112n, to request the desired meta information to be returned from that resource to the OSS 450 (via the respective hub 402n and satellite link 107) - but in this case using the generic protocol (e.g. SNMP or SSH) instead of a provider-specific (e.g. vendor-specific) API 454. The resource in question (e.g. client system 112n), also being suitably equipped with the generic protocol, may return the requested meta information to the OSS 450 in response (again via the respective hub 402n and satellite link 107), and the OSS 450 stores this information in its database 452. This step is performed in an at least partially automated manner in response to the detection of the new resource. E.g. it could be completely automated with no involvement of a human, or the OSS 450 may prompt a human operator with an alert that a new resource has been found and ask him or her to confirm that the query is to be sent.

The discovery mechanism 602 may be implemented as follows. To initially configure the mechanism 602 to be able to detect a resource of a particular new vendor, or perhaps a particular new model, may involve an initial manual work from an engineer. This may be done offline with a dedicated test instance of the resource, or may be done the first time an unrecognized type of resources is encountered during operation of the discovery mechanism in the field. Either way, the engineer goes through a process of "fingerprinting" to probe the device with one or more generic protocols to find out the communication capabilities of the new resources (e.g. a new piece of client equipment 112). That is, the engineer tries sending the resource one or more probe messages in one or more of the generic potential protocols it may recognize, and observes what result is received back. So for example, the engineer sends the resources a simple message in SNMP to discover of the resource "speaks" SNMP. If a reply is received, this means it does. The engineer may optionally then also try one or more further messages in SNMP to discover from the resource "how well do you speak SNMP". After tying one protocol, the engineer may also try one or more other protocols, e.g. tries sending an SSH message and observes whether or not a reply is successfully received; and again, if so, optionally tries sending one or more further SSH messages to test "how well do you speak SSH". This may be repeated with any number of protocols, e.g. HTTP, Telnet, etc. Similarly, it is possible to derive potential identifying information by sending a probe message in a dedicated protocol of the operating system, e.g. the operating system may reply with its version number, and/or the name of the network operator it is using, etc., and this may provide further information to help to identify the resource.

Alternatively or additionally, the vendor themselves may provide the OSS operator with inform formation about what response to expect from the resource(s) they provide.

Once it has been discovered in this initial phase what responses to expect from a particular vendor's resource (equipment,) or a particular model of resource, in response to a particular probe message or set of probe messages, then this provides a "fingerprint" that can subsequently be used "in the field" to recognize that particular vendor's resource or model of resource. The discovery mechanism 602 is preferably configured to recognize multiple such fingerprints for different respective vendors' resources and/or different respective models of resources. The discovery mechanism 602 can thus be pre-configured so that, when it later detects traffic from a particular source that it does not recognize (e.g. an unknown IP address) during operation of the satellite system, it automatically sends the predetermined set of probe messages to that traffic-source and automatically detects whether one of the predetermined "fingerprint" sets of response is received back. Thus the discovery mechanism 602 can know what vendor's equipment or what model of equipment it has encountered, and what are the communication capabilities of that equipment (SNMP, SSH, HTTP, etc.).

Once the discovery mechanism 602 has thus discovered the communication capabilities of the newly encountered resource, it can then use these to query one or more further pieces of meta information from the resource (e.g. what is your serial number? do you support CRUD operations? etc.), and store this information in the OSS 450. Note: the discovery mechanism 602 could be configured to perform the discovery by sending probe messages in various generic protocols without a manual pre-configuration stage by an engineer, e.g. by systematically going through an exhaustive set of probe messages. However, the purpose of the manual stage is to determine what probe messages can be safely sent without crashing the resource. The safe set of probe messages determined at this stage could comprise a flow-chart or decision-tree of probe messages - e.g. if the resource has responded to message X, it is safe to then probe it with messages Y and Z, etc. Once the engineer has determined a safe set of probe messages, the discovery mechanism 602 can then be configured to automatically apply this set in the field to discover the communication capabilities of particular new instances of the resources when encountered.

Optionally, the discovery mechanism may also be used to discover one or more capabilities of a resource, e.g. of a client system 112.

In embodiments, a resource such as a client system 112 may enable some aspect of the resource to be controlled remotely. For example, this may be used to allow a client system 112 to be controlled remotely via the satellite link 107 from the OSS 450, one of the hubs 402, or another control system of the satellite system, such as to allow an operator of the satellite system to control the client system(s) 112. E.g. such a mechanism may be used to remotely cause the client system 112 to perform CRUD (create, read, update and delete) operations, such as to cause the client system 112 to reset, or to try to re-establish the satellite link 107, to move to another hub 402, or to stop transmitting on the satellite link 107 or from Its respective dish 114.

For instance, if it is identified that a transmitting client system 112 is causing interference with other client systems 112, it may be desired to turn the interfering client system 112 off or at least instruct it to stop transmitting while the cause is investigated (perhaps a fault with the client system). If a suitable API 454 is available, this can be done remotely by the operator of the satellite system via the satellite link 107. However, if a suitable API is not available, the operator has to contact the downstream service provider, who in turn has to phone the end-user of the client system 112 to ask them to manually switch off the client system 112. Similarly, even if an API is available, a particular model of client system 112 may not support the desired functionality. Another example is to cause the client system 112 its link 107 to switch to a different hub 402, such as for load balancing or maintenance purposes. While one hub 402 per vendor is shown in Figures 4a and 6, in fact there may be multiple hubs available for use by a client system 112 of a given vendor. Typically a single hub is not adequate to handle all the traffic in a given beam from the client systems 112 of a given vendor, at least not at all times, and in general demand may vary. Therefore often there are implemented multiple hubs that can be used the client systems 112 of a given vendor, and using a suitable API 454 it is possible to control the client systems to switch hub to provide for better load balancing, or to allow one or more hubs to be powered down when demand is low. Alternately or additionally, the API 454 may allow client system 112 to be controlled to switch to another hub while maintenance is performed on a hub to which they were connected. However, if an API 454 is not available, such actions are not possible. And/or the API may be available, but a particular model of client system 112 may not support the functionality in question.

Hence for various reasons, it may be desired to determine whether a client system supports one or more particular capabilities such as to be controlled remotely via the satellite link 107, and if so which operations are supported (reset, re-establish link, switch hub, etc.). Therefore in embodiments, the discovery mechanism 602 may be configured to probe the capability of a resource such as a client system 112, to test whether or not it supports the one or more capabilities of interest. To do this it probe the client system 112 using one or more of the APIs 454 available to test whether a certain capability is exposed by the respective API 454. Note also that different capabilities may be exposed by different APIs, e.g. capability X may be exposed by a first API, while capability Y may be exposed by another API. The discovery mechanism 602 then generates a message to the operator of the satellite system advising as to what capability (if any) was found to be is exposed on the client system 112 (or resource) being tested. If a given capability was found, e.g. ability to be remotely reset, switched off or made to switch hub, this enables the capability to be exploited; but if not the operator may have to resort to alternative measures (e.g. manual intervention).

In yet further embodiments, the discovery mechanism 602 may be further configured to assist in an at least partially automated installation procedure. For example, it would be desirable of the consumer (end user) could perform some or all of the installation of his or her client system 112 him- or herself, or if the consumer need only hire a technician with the basic expertise required to physically install the client-side antenna 114 rather than specialist in installing satellite systems (e.g. a generic TV aerial installer rather than a specialist satellite technician). To facilitate this, there may be provided an application (or "app") to guide the user or installing technician through some or all of the installation process (a "wizard" app). This may comprise an on-line service activation feature, by which the user can go online and use the app to complete a transaction to pay for the service and also initiate the service. As part of this, the discovery mechanism described above may be triggered to automatically query one or more pieces of meta information about the client system 112 being installed, e.g. serial number of the IDU 420. In embodiments, completion of the online activation may be made conditional on one or more such pieces of information being successfully discovered by the discovery mechanism 206. It will be appreciated that the above embodiments have been described only by way of example.

For instance, the generic protocol used by the discovery mechanism is not limited to being SNMP or SSH, and other options are possible as long as the resource in question (e.g. client system 112n) is equipped to recognise and respond to the protocol.

Further, note that the types of meta information listed above are only examples, and in other systems other meta information or other combinations of meta information may be desired or required for storage in the OSS database.

Further, note that the term "API" or "application programming interface" as used herein does not limit to any particular protocol, language or form of interface, other than that it is vendor-specific or more generally provider-specific. An API could be implemented as any software module that provides a predefined rule or set of rules for interfacing with the relevant provider's resource to request meta information for the OSS database. Furthermore, 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 116) networked together over multiple different geographic sites.

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.

Claims

1. An operations support system, for use with a satellite system comprising multiple resources in the form of one or more satellites, one or more hubs, and a plurality of client systems, each of the hubs providing a respective group of the client systems with access to an internet by using at least one of the satellites to communicate traffic between the internet and the respective client systems via a satellite link between the hub and each of the respective client systems; the operations support system comprising:

a database for storing respective information on each respective one of a plurality of said resources, wherein the operations support system is configured to query the respective information from some of said plurality of resources via at least one provider-specific application programming interface of a provider of each respective resource, and to thereby store the respective information in said database; and

a discovery mechanism configured to detect when a new one of said resources is added to the satellite system for which a provider-specific application programming interface is not currently available for querying the respective information from the new resource, and in response to use a generic protocol to query the respective information from the new resource and thereby store the respective information in said database, the generic protocol being common to the new provider and other parties.

2. The operations support system of claim 1, wherein the queried information comprises one or more of:

a serial number of the respective resource;

a model type of the respective resource;

a firmware version of the respective resource;

a signal-to-noise ratio, error rate, or other measure of quality of the satellite link used by the respective resource;

a quantity of the traffic sent and/or received by the respective resource over the satellite link;

a transmit and/or receive power of the respective resource on said satellite link; an uptime of the resource;

a reboot history of the resource; a default gateway for use in the communication of said traffic;

an ARP cache for use in the communication of said traffic;

a DNS for use in the communication of said traffic;

an IP mask for use in the communication of said traffic;

one or more NAT rules for use in the communication of said traffic;

one or more port forwarding rules for use in the communication of said traffic the resource;

one or more QoS rules for communicating for use in the communication of said traffic; and/or

a cable length between an indoor unit and an outdoor unit of the respective resource.

3. The operations support system of any preceding claim, wherein:

the resources for which the respective information is stored in said database at least comprise a plurality of the client systems;

the resources queried via a provider specific application programming interface at least comprise some of the plurality of client systems; and

the discovery mechanism is configured to detect the new resource, and perform said querying using the generic protocol, at least when the new resource is a new one of the client systems.

4. The operations support system of any preceding claim, wherein said one or more satellites are multiple satellites, and wherein:

the resources for which the respective information is stored in said database at least comprise a plurality of the satellites;

the resources queried via a provider specific application programming interface at least comprise some of the plurality of satellites; and

the discovery mechanism is configured to detect the new resource, and perform said querying using the generic protocol, at least when the new resource is a new one of the satellites.

5. The operations support system of any preceding claim, wherein said one or more hubs are a plurality of hubs, and wherein:

the resources for which the respective information is stored in said database at least comprises information a plurality of the hubs;

the resources queried via a provider specific application programming interface at least comprise some of the plurality of the hubs; and

the discovery mechanism is configured to detect the new resource and perform said querying using the generic protocol at least when the new resource is a new one of the hubs.

6. The operations support system of any preceding claim, wherein the discovery mechanism is configured to perform said detection by monitoring the traffic for a new address.

7. The operations support system of any preceding claim, wherein said generic protocol is SNMP or SSH.

8. The operations support system of any preceding claim, wherein for each of one or more of the resources, the discovery mechanism is further configured to use one or more of the application programming interfaces to test whether or not the resource supports each of one or more control capabilities.

9. The operations support system of any preceding claim, wherein the discovery mechanism is further configured to assist in a partially automated installation of the new resource.

10. The operations support system of any preceding claim, wherein the discovery mechanism is configured to detect the new resource and perform said querying using the generic protocol at least when said new resource is from a new provider for whom a provider-specific application programming interface is not currently available for querying the respective information.

11. The operations support system of any preceding claim, wherein the discovery mechanism is configured to detect the new resource and perform said querying using the generic protocol at least when said new resource is a new model or type of resource provided by an existing provider, for which model or type a provider-specific programming interface is not currently available.

12. The operations support system of any preceding claim, wherein the internet to which access is provided by at least one of the one or more hubs is the Internet.

13. The operations support system of claim 6 and 12, wherein said monitoring comprises monitoring for a new IP address in the traffic.

14. A computer program product, for use in a satellite system comprising multiple resources in the form of one or more satellites, one or more hubs, and a plurality of client systems, each of the hubs providing a respective group of the client systems with access to an internet by using at least one of the satellites to communicate traffic between the internet and the respective client systems via a satellite link between the hub and each of the respective client systems; the computer program product comprising code embodied on a computer-readable medium and configured so as when executed to perform operations of:

accessing a database for storing respective information on each respective one of a plurality of said resources;

querying the respective information from some of said plurality of resources via at least one provider-specific application programming interface of a provider of each respective resource, and thereby storing the respective information in said database;

detecting when a new one of said resources is added to the satellite system for which a provider-specific application programming interface is not currently available for querying the respective information from the new resource; and

in response to said detection, using a generic protocol to query the respective information from the new resource and thereby store the respective information in said database, the generic protocol being common to the new provider and other parties.

15. A method, performed in relation to a satellite system comprising multiple resources in the form of one or more satellites, one or more hubs, and a plurality of client systems, each of the hubs providing a respective group of the client systems with access to an internet by using at least one of the satellites to communicate traffic between the internet and the respective client systems via a satellite link between the hub and each of the respective client systems; the method comprising:

querying the respective information from some of said plurality of resources via at least one provider-specific application programming interface of a provider of each respective resource, and thereby storing the respective information in said database; detecting when a new one of said resources is added to the satellite system for which a provider-specific application programming interface is not currently available for querying the respective information from the new resource; and