Background of the Invention The ETSI DVB standard specifies certain formats and protocols for satellite broadcasts, and allows for various return channel types including DVB-RCS, which specifies a return channel over satellite. An example of a DVB-RCS system is the Broadband Interactive (BBI) service operated by Société Européenne des Satellites. The satellite interactive terminals (SIT) of this system are fixed.

US 6,356, 539 describes an interactive satellite broadcast system using Ku-band broadcast satellites and an L-band mobile satellite system for the return link. The broadcast earth station and the mobile satellite system earth station are linked to a common hub, which provides a gateway to various services.

US 6,201, 797 describes a high bandwidth delivery and internet access service for airborne passengers, with various possible return channels including satellite-based channels.

Statement of the Invention According to one aspect of the present invention, there is provided a method of routing data packets via satellite to a mobile communications terminal, in which the data packets are sent either selectively either via a broadcast satellite or a mobile communications satellite, depending for example on one or more of the following: - whether the terminal is within coverage of the broadcast satellite - whether the terminal has acknowledged packets sent via the broadcast satellite; and - whether there is sufficient bandwidth available on the broadcast satellite.

An advantage of this method is that, although the broadcast satellite is normally capable of higher data rates in the forward direction and is therefore preferentially used

for forward link transmissions, the mobile communications satellite may be used to supplement the service of the broadcast satellite in circumstances where the use of the broadcast satellite is not possible or desirable.

According to another aspect of the present invention, there is provided a method of routing transmissions to a receiver through a selected one of a plurality of spot beams of a broadcast satellite which provides only a forward link, by receiving an indication of the spot beam location of the receiver through a return link of another satellite, such as a mobile communications satellite. In this way, the broadcast service may take advantage of location information to route traffic only to those beams in which the traffic is required; this is desirable for satellite multicasts, for example.

According to another aspect of the present invention, there is provided a method of packet data transmission via satellite, in which a multicasting protocol is used to support packet data multicasting over the satellite link.

Brief Description of the Drawings A detailed description of the preferred embodiments will now be described with reference to the accompanying drawings, in which: Figure 1 is a diagram of the topology of a hybrid satellite communications network in an embodiment of the present invention; Figure 2 is a system model diagram of the network; Figure 3 is a diagram of a user terminal in the network; Figure 4 is a diagram of the elements of the network and the relationships between them; Figure 5 illustrates the mobility management and routing elements of the network; Figure 6 is a protocol diagram of a protocol used in the embodiment; Figure 7 illustrates the routing of a request for contents in the embodiment; Figure 8 illustrates the routing of broadcast data in the embodiment; and Figure 9 is a flowchart of a forward path selection method in the embodiment.

Description of Embodiments Network Architecture An embodiment of the present invention provides a hybrid satellite communications network in which a satellite broadcast service, providing a high

bandwidth forward link at high frequency (Ka, Ku or C band, for example), is integrated with a mobile satellite communications network, which provides both forward and return links at low frequency (L band, for example). This network architecture is shown schematically in Figure 1. The broadcast satellite service consists of one or more broadcast satellites BS, each of which retransmits broadcast channels received on a feeder link from a broadcast earth station BES connected via a broadcast gateway BG to a packet network PN, which may use the TCP/IP set of protocols; this provides a broadcast forward link FLB. The mobile satellite communications network comprises one or more mobile communications satellites MS each of which provides both forward and return link channels FLM, RL between any of a plurality of user terminals UT and a satellite base station SBS interacting with a home land earth station HLES, which is also connected to the packet network PN. The return link channels are designed to carry packet data, which is suitable for the low capacity bursts of data typical of an interactive return channel. The mobile satellite communications network supports communication with mobile terminals, but may also provide communication services to fixed terminals.

Each user terminal UT is preferably connectable to only one broadcast gateway BG and one HLES any one time, although there may be a choice of broadcast gateways and HLES available to the user terminal UT at any location or time.

In one example, the broadcast satellite service conforms to the DVB-S standard, while the mobile satellite network conforms to the proprietary InmarsatTM MPDS (mobile packet data service) system definitions. However, other standards and system definitions may be used.

The broadcast satellite service may use the Unidirectional Link Protocol (UDLR), which supports multicast routing protocols and transfer tools. UDLR emulates bi- directional connectivity among routers connected only by a unidirectional link.

The broadcast coverage area BC of the broadcast service overlaps the mobile coverage area MC of the mobile satellite network, but there may be parts of the mobile coverage area MC not covered by the broadcast coverage area BC. The or each broadcast satellite BS may generate multiple beams BB1-3 within the broadcast coverage area BC, and the or each mobile satellite MS may generate multiple beams (not shown, for clarity) within the mobile coverage area MC.

Figure 2 shows the system architecture in more detail. The broadcast gateway BG provides the forward link FLB over a broadcast channel of the broadcast satellite BS to

the user terminal. The forward link uses a standard broadcast air interface, such as DVB- S. The broadcast gateway BG receives forward data streams from multiple different content providers CP and service providers, such as the HLES, encapsulates them with a specified quality of service (QoS), creates and modifies connection data records, accounting and billing records and error records, and modulates and uplinks the data streams to the broadcast satellite BS. The broadcast data streams may be broadcasts not addressed to any specific user terminal UT, multicasts addressed to a group or groups of user terminals UT, or unicasts addressed only to one specific user terminal UT.

The HLES and SBS provide both a forward link FLM and a return link RL to the user terminal. Theses forward and return links are used to perform system operation functions and signalling, such as initialisation, registration, service connection, service operation, service release and de-registration. The forward link FLM also provides an alternative path for the broadcast data streams under certain conditions, as will be described in more detail below. The return link RL may provide an interactive channel for interactive broadcast services.

The HLES receives data streams from the content providers CP, via the packet network PN, and selectively routes them either to the broadcast gateway BG, via a virtual private network VPN, or to the satellite base station SBS. Alternatively, at least some of the data streams may be routed directly from the content provider CP to the broadcast gateway BG.

User Terminal As shown in Figure 3, the user terminal UT comprises a broadcast reception antenna BA connected to a broadcast receiver BR and a mobile antenna MA connected to mobile earth station equipment MES. The broadcast receiver BR and the mobile earth station equipment MES are connected via a hub H to a portable computer PC, which runs communications and broadcast reception applications. A navigation receiver NAV, such as a GPS receiver, provides location information to the portable computer PC.

Network elements Figure 4 shows the basic elements of the network and the relationship between them in the specific embodiment in which the DVB and InmarsatTM MPDS protocols and

formats are used. The user terminal UT is a mobile network node having a COM port driven by dial-up networking (DUN) and connected to the MES, and a DVB card driven by a DVB card driver and connected to the broadcast receiver BR. A DVB intermediate driver interfaces DUN and the DVB card driver to the TCP/IP stack. DUN is configured by an MPDS DUN profile under the control of a RAS (Remote Access Server) DUN handler. Authentication is provided via a Radius Client. The DVB driver is controlled by a DVB card interface via a DVB card API (Application Programming Interface). A DVB client control application and GUI implements the user interface and control logic.

The control applications allow the user to select one of three different modes of connections and operation :"Slow","Fast"and"Off". In"Slow"mode, the application receives data by dialling into the mobile satellite service. In"Fast"mode, the application signals to the HLES to switch all forward traffic to the broadcast link FLB. In"Off' mode, the application signals to the HLES to switch off forward traffic to the UT, and hangs up the mobile satellite connection.

The application communicates with the HLES using the Radius protocol, which provides authentication to allow forward traffic to be switched on. A Radius reply message may contain information on the broadcast channel containing the data stream to be received by the UT, or may be a reject message if the user is denied access. The Radius protocol is also used by the UT to request the HLES to switch off forward traffic, and the HLES replies with a Radius Accept reply. The Radius protocol is also used to send a Keep Alive message to the HLES in the form of a Radius accounting message, to prevent the mobile satellite connection from timing out.

Routing of Forward Traffic The user terminal UT is mobile and may travel between different beams of the broadcast satellites BS and the mobile satellites MS. In the case of multicasts or unicasts, the broadcast gateway BG determines the beam or beams of the broadcast satellite within which the addressed UT or UTs are located, and transmits via those beams, as will be described below with reference to Figure 5.

The mobile satellite network includes a global location register which is copied to a local register GLR-L via the mobile satellite MS to each HLES. The global location register indicates the spot beam of the mobile satellite network within which each user terminal UT was last registered, and is updated as the registration status of each user

terminal UT changes. The HLES also stores, for each user terminal UT, the current beam of the broadcast satellite BS, as detected by the UT and signalled via the return link RL.

The broadcast gateway BG includes a router BR which routes each data stream received from the HLES via an internet protocol/broadcast gateway IPG to a broadcast modulator BM1-3 to which the addressed beam BB 1-3 corresponds. In the case where the data stream is routed via the mobile satellite network, the HLES addresses the data stream to a mobile satellite modem MM corresponding to the appropriate beam of the mobile satellite MS. The satellite base station includes a router MR which routes the data stream to the addressed mobile satellite modem MM.

Mobility and Routing Requirements As mentioned above, there may be some areas that are within mobile coverage MC but outside broadcast coverage BC. For each user terminal UT, one of the following broadcast modes is defined for the forward data streams: Broadcast Only if the user terminal goes out of broadcast coverage BC, the connection is dropped; Mobile Only connection is always made via the mobile satellite network and never via the broadcast service Broadcast Preferred the broadcast service is used when available for the forward link, otherwise the data stream is routed via the mobile satellite network.

Broadcast Only In broadcast only mode, the following process is performed. The user terminal UT identifies the beam of the broadcast satellite BS that it can currently receive. This may be done either by the broadcast satellite transmitting a different beam identifier signal in each beam, and the user terminal detecting the received signal strengths of the beam identifier signals, or by the user terminal storing a table of frequencies at which each beam transmits, and detecting the received signal strengths at the different frequencies.

Alternatively, as illustrated in Figure 6, the user terminal may request (Sl) and receive (S2) from the HLES a current spot beam map, which indicates the location coverage of each spot beam of the broadcast satellite (s) BS. The user terminal determines its own

location using a location system receiver, such as a GPS receiver, and determines, from the spot beam map, the spot beam in which it is currently located (S3).

Next, the user terminal UT tunes to a broadcast channel within the detected spot beam. If the broadcast channel is received correctly, the user terminal UT sends to the HLES a confirmation (S4) of the detected spot beam. The HLES updates a mobility management table (S5) to record this spot beam against the user terminal, and looks up the corresponding broadcast gateway modulator BM. An example of records from the mobility management table is shown below in Table 1 : Table 1-Mobility Management Table UT Spot Beam ID Gateway Modulator 12345678 355 (PAS8 Beaml) 172.20. 0.99 12345677 356 (PAS8 Beam2) 172.20. 0.98 23456789 211 (Intelsat 64 Beam2) 172.21. 0.50 ... I... I...

Next, the user terminal sends (S6) a request for content to the content provider CP via the HLES. Figure 7 shows an example of this, in which the SBS receives a request from a first user terminal UT1 for content from a first content provider CP1, a request from a second user terminal UT2 for content from the first content provider CP1, and a request from a third user terminal UT 3 for content from a second content provider CP2.

Each request packet is encapsulated in a packet addressed to the HLES, which decapsulates the packets and routes them through the packet network PN to the requested content provider CP1, CP2.

Finally, the requested contents are transmitted to the user terminal UT as follows.

First, the content provider CP sends (S7) the requested data stream to the HLES. The HLES identifies the current broadcast spot beam for the UT and routes (S8) the requested data stream to the broadcast gateway modulator BM corresponding to that spot beam, and the data stream is transmitted (S9) to the user terminal UT. If the mobility management table record for that user terminal is in the process of being updated, the HLES buffers the data stream until the update is complete.

An example of the routing of the data stream is shown in Figure 8, in which content packets from the first content provider CP1 are addressed to the first and second user terminals UT1, UT2, and content packets from the second content provider CP2 are addressed to the third user terminal UT3, routed via the HLES. The HLES determines

from its mobility management table that the user terminals UT1, UT2 and UT3 are respectively in the beams BB1, BB2 and BB3 and encapsulates the content packets in packets addressed to the corresponding broadcast modulators BM1, BM2, BM3, which transmit the packets so that they are retransmitted in the corresponding beams BB 1, BB2 and BB3.

Mobile Only The mobile-only mode corresponds to a conventional mobile satellite network procedure and will not be described further.

Mobile Preferred This mode differs from the Broadcast Only mode in that HLES routes the data stream via the mobile satellite system in any of the following cases: - the UT cannot detect a broadcast spot beam or recognises that it is outside broadcast coverage BC - insufficient capacity is available on the broadcast satellite (s) BS - the UT does not acknowledge reception of the data stream transmitted via the broadcast satellite BS.

An example of selection of the forward path is shown in Figure 9. Processes performed by the UT are shown in dashed outline, while processes performed by the HLES are shown in dotted outline. The process begins (PI) with a UT in off or standby mode. The UT attempts to acquire a return link channel RL in an initial sync procedure (P2), and, if unsuccessful (P3), returns to standby mode (PI). Otherwise, if Mobile Only mode is set for that UT (P4), the UT follows a standard communications procedure with the mobile satellite network (P5). If Mobile Only is not set, the UT attempts (P6) to acquire a broadcast channel FLB, for example by identifying the broadcast beam BB within which it is located, as described above. If unsuccessful (P7), the UT follows a standard mobile satellite network communications procedure (P5) if not in Broadcast Only mode (P8), otherwise it returns to standby mode (P1).

If the UT is successful (P7) in acquiring a broadcast channel FLB, the HLES receives requests for content and forwards the content to the UT (P9), as described above with reference to Figures 7 and 8. During this process, if there is not enough capacity on the broadcast channel (P10), the HLES routes the content via the mobile forward link

FLM (Pll), but if there is sufficient capacity (P10), the HLES forwards the content via the broadcast link FLB (P12) and awaits acknowledgement messages (P13) from the UT via the return link RL. If there is no acknowledgement, the HLES retransmits (P14) the packets via the mobile forward link FLM (Pll).

Services The embodiment described above supports interactive broadcast and multicast services, as well as bi-directional communications. The data content may include one or more of audio, video and user data. The embodiment supports multicast streaming to closed user groups. The use of multicasting allows broadcast only to selected users or user groups within the same beam. For example, location-specific information may be broadcast to users known to be within a defined location within a beam.

Although the user terminals UT are described as being mobile, it is not essential that all such terminals are capable of being moved, and embodiments of the present invention may also provide broadcast services to fixed installations.

Other variants of the embodiments described above may be envisaged, and aspects of the present invention are not limited to the specific embodiments described.