Patent Description:
Data networks are utilized for transmitting and receiving information using various platforms, or devices. Consumers are also capable of accessing data networks through various types of infrastructure (e.g., cable, DSL, fiber, etc.). Satellite networks have emerged as an option for consumers to access data, as well as voice, networks. Satellite communication systems utilize various types of satellite terminals (or simply "terminals"), including fixed, portable, transportable, etc., to establish communication over the satellite network. The terminal allows a consumer to access, for example, data networks via multiple user devices. The terminal is associated with a gateway which provides a point of connection to terrestrial data networks for the satellite network.

Gateways are typically configured to support links to many terminals and other satellite communication devices. Since each terminal (and satellite communication device) has a fixed link to a gateway, it can be difficult to manage and distribute load in a manner which maintains required quality of service (QoS) levels. Dynamic Outroute Load balancing can be used to support automatic load balancing across multiple outroutes within a beam to ensure that network resources are being fully utilized, spectrum is being optimally utilized for providing user throughputs during busy periods, and quality of service (QoS) can be provided at similar level for all terminals. This can prevent, for example, loss of active TCP connections and traffic after a terminal moves to another outroute due to load balancing. This dynamic outroute load balancing can also eliminate manual balancing workload, and allow a business system or other entity to direct a terminal installation to a particular outroute to promote balance.

Two types of load balancing methods are available, namely network assisted, but terminal initiated and network initiated. In network assisted load balancing, the terminal moves to another outroute for load balancing purposes when idle, i.e. not actively sending traffic. For network initiated load balancing, the network commands a terminal's outroute move regardless of whether or not that terminal has active traffic.

When multicast sessions are required, the gateway replicates and forwards the multicast stream over one or more respective outroute carriers of one or more spot beams of a satellite. When the gateway is configured to be in a static forwarding mode, the multicast stream is replicated and forwarded regardless of whether any terminals are arranged to actively receive the multicast stream. When the gateway is configured to be in a dynamic forwarding mode, the multicast stream is replicated and forwarded over multiple outroutes of multiple spot beams only when at least one respective terminal is arranged to actively receive the multicast stream via each of the multiple outroutes of the multiple spot beams.

The introduction of dynamic outroute load balancing in systems that carry multicast traffic can adversely affect system performance when terminals are moved to distribute loading across multiple available outroutes in a beam. For example, terminals receiving multicast traffic can be spread across outroutes, thereby requiring the same multicast sessions to be sent on every outroute. Such redundancy can degrade system performance and waste bandwidth that could be used to carry other traffic. Based on the foregoing, there is at least a need for an approach for automatically optimizing load balancing to minimize load capacity used for multicast, without having to hard code such assignments, while also leveraging multiple outroutes for different multicast sessions.

<CIT> describes a terminal that receives requests by a first and second clients for a slice of a data stream. The terminal receives a multicast packet that encapsulates the slice of the data stream, and extracts the slice. The terminal, then responds to the requests by sending the clients the extracted slice.

<CIT> describes a system and method for association of remote nodes with respective aggregation nodes in a high capacity shared bandwidth communications network. A terminal device receives a message transmitted by a gateway over the communications network, wherein the message includes service codes identifying one or more service capabilities of the gateway. Based on the service codes, it is determined whether the gateway is an eligible gateway for servicing one or more service requirements of the terminal device.

<CIT> describes a method and a satellite communication system wherein a satellite gateway earth station receives a multicast stream from an external network. The satellite gateway earth station replicates and forwards traffic from the multicast stream over a respective outroute carrier a spot beam of a satellite regardless of whether any terminal is arranged to actively receive any of the at least one multicast stream.

A method is disclosed for balancing traffic loads on beam outroutes containing both multicast and unicast traffic is described. The method includes: designating a first outroute for supplying at least multicast traffic within a beam of a satellite communication system, wherein the beam includes a plurality of outroutes and the plurality of outroutes carry both multicast and unicast traffic; comparing traffic loads of each outroute of the plurality of outroutes within the beam, including the first outroute; determining if variations in the traffic loads of the plurality of outroutes exceed a predetermined threshold; performing a load balancing routine, when the variations exceed the predetermined threshold, to redistribute the traffic loads of the plurality of outroutes by moving at least one terminal to a second outroute within the beam; and excluding, from the load balancing routine, any terminal within the first outroute and within all other outroutes of the plurality of outroutes that is actively receiving the multicast traffic.

Additional features of the invention are set out in the dependent claims.

The foregoing summary is only intended to provide a brief introduction to selected features that are described in greater detail below in the detailed description. As such, this summary is not intended to identify, represent, or highlight features believed to be key or essential to the claimed subject matter. Furthermore, this summary is not intended to be used as an aid in determining the scope of the claimed subject matter.

Various exemplary embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements and in which:.

An apparatus, system, and method for balancing beam outroutes containing both multicast and unicast traffic are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the disclosed embodiments. It will become apparent, however, to one skilled in the art that various embodiments may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the various embodiments.

<FIG> illustrates a satellite communication system <NUM> capable of providing voice and data services. The satellite communication system <NUM> includes a satellite <NUM> that supports communications among a number of gateways <NUM> (only one shown) and multiple stationary satellite terminals 140a-140n. Each satellite terminal (or terminal) <NUM> can be configured for relaying traffic between its customer premise equipment (CPEs) 142a-142n (i.e., user equipment), a public network <NUM> such as the internet, and/or its private network <NUM>. Depending on the specific embodiment, the customer premise equipment <NUM> can be a desktop computer, laptop, tablet, cell phone, etc. Customer premise equipment <NUM> can also be in the form of connected appliances that incorporate embedded circuitry for network communication can also be supported by the satellite terminal (or terminal) <NUM>. Connected appliances can include, without limitation, televisions, home assistants, thermostats, refrigerators, ovens, etc. The network of such devices is commonly referred to as the internet of things (IoT).

According to an exemplary embodiment, the terminals <NUM> can be in the form of very small aperture terminals (VSATs) that are mounted on a structure, habitat, etc. Depending on the specific application, however, the terminal <NUM> can incorporate an antenna dish of different sizes (e.g., small, medium, large, etc.). The terminals <NUM> typically remain in the same location once mounted, unless otherwise removed from the mounting. According various embodiments, the terminals <NUM> can be mounted on mobile platforms that facilitate transportation thereof from one location to another. Such mobile platforms can include, for example, cars, buses, boats, planes, etc. The terminals <NUM> can further be in the form of transportable terminals capable of being transported from one location to another. Such transportable terminals are operational only after arriving at a particular destination, and not while being transported.

As illustrated in <FIG>, the satellite communication system <NUM> can also include a plurality of mobile terminals <NUM> that are capable of being transported to different locations by a user. In contrast to transportable terminals, the mobile terminals <NUM> remain operational while users travel from one location to another. The terms user terminal, satellite terminal, terminal may be used interchangeably herein to identify any of the foregoing types. The gateway <NUM> can be configured to route traffic from stationary, transportable, and mobile terminals (collectively terminals <NUM>) across the public network <NUM> and private network <NUM> as appropriate. The gateway <NUM> can be further configured to route traffic from the public network <NUM> and private network <NUM> across the satellite link to the appropriate terminal <NUM>. The terminal <NUM> then routes the traffic to the appropriate customer premise equipment (CPE) <NUM>.

According to at least one embodiment, the gateway <NUM> can include various components, implemented in hardware, software, or a combination thereof, to facilitate communication between the terminals <NUM> and external networks <NUM>, <NUM> via the satellite <NUM>. According to an embodiment, the gateway <NUM> can include a radio frequency transceiver <NUM> (RFT), a processing unit <NUM> (or computer, CPU, etc.), and a data storage unit <NUM> (or storage unit). While generically illustrated, the processing <NUM> can encompass various configurations including, without limitations, a personal computer, laptop, server, etc. As used herein, a transceiver corresponds to any type of antenna unit used to transmit and receive signals, a transmitter, a receiver, etc. The RFT <NUM> is useable to transmit and receive signals within a communication system such as the satellite communication system <NUM> illustrated in <FIG>. The data storage unit <NUM> can be used, for example, to store and provide access to information pertaining to various operations in the satellite communication system <NUM>. Depending on the specific implementation, the data storage unit <NUM> (or storage unit) can be configured as a single drive, multiple drives, an array of drives configured to operate as a single drive, etc..

According to other embodiments, the gateway <NUM> can include multiple processing units <NUM> and multiple data storage units <NUM> in order to accommodate the needs of a particular system implementation. Although not illustrated in <FIG>, the gateway <NUM> can also include one or more workstations <NUM> (e.g., computers, laptops, etc.) in place of, or in addition to, the one or more processing units <NUM>. Various embodiments further provide for redundant paths for components of the gateway <NUM>. The redundant paths can be associated with backup components capable of being seamlessly or quickly switched in the event of a failure or critical fault of the primary component.

According to the illustrated embodiment, the gateway <NUM> includes baseband components <NUM> which operate to process signals being transmitted to, and received from, the satellite <NUM>. For example, the baseband components <NUM> can incorporate one or more modulator/demodulator units, system timing equipment, switching devices, etc. The modulator/demodulator units can be used to generate carriers that are transmitted into each spot beam and to process signals received from the terminals <NUM>. The system timing equipment can be used to distribute timing information for synchronizing transmissions from the terminals <NUM>.

According to an embodiment, a fault management unit <NUM> can be included in the gateway <NUM> to monitor activities and output one or more alerts in the event of a malfunction in any of the gateway components. The fault management unit <NUM> can include, for example, one or more sensors and interfaces that connect to different components of the gateway <NUM>. The fault management unit <NUM> can also be configured to output alerts based on instructions received from a remotely located network management system <NUM> (NMS). The NMS <NUM> maintains, in part, information (configuration, processing, management, etc.) for the gateway <NUM>, and all terminals <NUM> and beams supported by the gateway <NUM>. The gateway <NUM> can further include a network interface <NUM>, such as one or more edge routers, for establishing connections with a terrestrial connection point <NUM> from a service provider. Depending on the specific implementation, however, multiple terrestrial connection points <NUM> may be utilized.

<FIG> illustrates a system <NUM> for load balancing of unicast and multicast traffic, according to one or more embodiments. The system <NUM> includes coverage beams <NUM> (only one shown) which provide communication by means of one or more outroutes. For example, the illustrated coverage beam <NUM> includes three outroutes, namely outroute_1, outroute_2, and outroute_3. It should be noted, however, that other coverage beams (or beams) <NUM> can include additional outroutes or less outroutes. The beams <NUM> overlay specific geographical areas in order to communicate with a gateway <NUM> and terminals <NUM>. Although not shown in <FIG>, the system <NUM> includes a satellite which generates the beams <NUM> to facilitate a bent pipe communication path in the manner shown in <FIG>. The outroutes can also be configured to carry specific types of traffic. As illustrated in <FIG>, for example, only outroute_3 is designated for supplying multicast services, while outroute_1 and outroute_2 provide point to point (or unicast) traffic.

The gateway <NUM> can connect to a network such as a backhaul network <NUM> in order to establish communication with one or more centralized data centers <NUM> such as the NMS shown in <FIG>. Depending on the specific implementation, the gateway <NUM> can also utilize public/private networks <NUM> to communicate with the data centers <NUM>. According to the illustrated embodiment, the data center <NUM> can include IP gateways (IPGW) <NUM>, code rate organizers (CRO) <NUM>, and a bandwidth manager <NUM>. The IPGW <NUM> is configured to provide layer-<NUM> and layer-<NUM> functionality by processing packets transmitted to, and received from, the internet <NUM>. The IPGW <NUM> can include, depending on the specific implementation, a spoofer for acknowledging packets received at the gateway <NUM> such as transmission control protocol (TCP) and User Datagram Protocol (UDP) packets. Furthermore, a single IPGW or a pool of IPGW can be utilized.

The CRO <NUM> is configured to determine the modulation and coding applied to the signal stream in order to generate an output signal which optimizes spectrum utilization. For example, the CRO <NUM> can estimate bandwidth capacity and arrange incoming data from the IPGW <NUM> into a data stream which optimally utilizes available bandwidth when transmitted to the terminals <NUM>. According to one or more embodiments, the CRO <NUM> can be configured to dynamically adjust the modulation and coding (ModCod) used for a particular outroute in order to improve link conditions or to change the size of multicast outroutes based on the traffic load of all outroutes within the beam.

The bandwidth manager <NUM> is configured to allocate bandwidth for all terminals <NUM> supported by the gateway <NUM>. The bandwidth manager <NUM> can therefore communicate with the gateway <NUM>, IPGW <NUM>, and CRO <NUM> in order to obtain information pertaining to bandwidth efficiency when allocating bandwidth to the terminals <NUM>. While <FIG> illustrates the data center <NUM> as being remotely located from the gateway <NUM>, it should be noted that they can be collocated. Additionally, the functionality of the data center <NUM> can also be incorporated into hardware and/or software components of the gateway <NUM>.

According to various embodiments, the system <NUM> can assign multicast outroutes in either a static or dynamic manner. Using the static approach, the system <NUM> can designate a particular outroute for all multicast traffic (or multicast services) either permanently or for an extended period. Any terminal <NUM> wishing to receive multicast services would remain on the designated outroute (i.e., multicast outroute). The multicast outroute is also capable of carrying unicast traffic in order to simultaneously provide multicast traffic together with unicast traffic such as internet protocol (IP) based services. Furthermore, terminals <NUM> that are only carrying unicast traffic can remain on the multicast outroute.

In the dynamic case, the IPGW <NUM> (i.e., the multicast sender on the outroute) automatically selects or designates an outroute for multicast traffic. The IPGW <NUM> then announces on all outroutes within the beam that the multicast is coming over the selected outroute. All terminals <NUM> interested in receiving the multicast would automatically move to the selected outroute. As discussed in greater detail below, load balancing routines can be implemented to move other terminals <NUM> away from the selected multicast outroute. In many cases, upcoming multicast session schedules are known as well as the particular start time and duration. For example, multicasts using HLS (HTTP Live Streaming) protocol, popular TV show broadcasts, and pay-per-view events, to name a few, etc. can be prescheduled because they have known dates, start time, duration, etc. In such cases, the IPGW <NUM> can periodically announce the session multicast group ID, start time, and the multicast outroute ID over all outroutes on the beam <NUM> prior to the start (e.g., <NUM> hours) of the multicast session. Terminals <NUM> interested in receiving this multicast session can automatically move to the announced multicast outroute just before the start time. Furthermore, information necessary for validating conditional access to the multicast session can be provided to all appropriate terminals <NUM> before starting the multicast.

During normal operations the amount of traffic carried over outroutes within the beam <NUM> can vary such that the traffic load across the outroutes becomes unbalance, thereby resulting in inefficient use of the satellite link. Such a condition can sometimes result from multiple terminals <NUM> switching to a multicast outroute (i.e., outroute_3) in order to access a multicast service. If the traffic loads of each outroute were balanced prior to the terminals <NUM> switching to the multicast outroute, the traffic loads will now be unbalanced. Specifically, the multicast outroute will now have an increased traffic load relative to the other outroutes due to the additional terminals <NUM>. Furthermore, certain complications can arise due to the designation of a multicast outroute wherein terminals <NUM> receiving the multicast must remain.

According to various embodiments, different types of load balancing routines can be performed depending on the amount of imbalance which currently exists. The load balancing routines also take into account the need for terminals <NUM> receiving a multicast session to remain within the designated multicast outroute. This is done without having to replicate the multicast traffic on the other outroutes. One type of load balancing can be independently initiated by each terminal, and another type can be initiated by the network (e.g., via the gateway or bandwidth manager). Different threshold values can be set, for example, to select or trigger a particular type of load balancing routine. The threshold values can be based on variations between the traffic load on each outroute. The specific manner in which the variations are determined can be system design and implementation. For example, the variations can be based on the relative difference between the outroute having the highest traffic load and the outroute having the lowest traffic. The two threshold values can be selected such that a lower threshold (e.g., <NUM>%) is used to trigger a terminal initiated load balance, while a higher threshold (e.g., <NUM>%) is used to trigger a network initiated load balance.

According to the disclosed embodiments, terminal initiated load balancing is dynamically performed on a per terminal basis. The data center <NUM> generates a load metric for each outroute within the beam <NUM>. The load metrics are subsequently broadcast to all terminals <NUM> within the beam <NUM>. Each terminal <NUM> utilizes this information to independently determine if it is currently in an outroute with a high traffic load. For example, the terminal <NUM> can utilize the first threshold (e.g., <NUM>%) to initiate load balancing if the traffic load of its current outroute is <NUM>% greater than the lowest outroute traffic load, or other type of traffic variation that can be subject to the first threshold. The terminal <NUM> can then move to the outroute having the lowest traffic load. Since the traffic load information is broadcast to all terminals <NUM> within the beam <NUM>, each terminal can periodically utilize this information to move to the most efficient outroute, thus balancing the traffic load across all outroutes. The data center <NUM> can also establish predetermined intervals at which terminals <NUM> can check the first threshold to see if load balancing should be performed. Multiple intervals can also be established such that groups of terminals <NUM> check the first threshold to see if load balancing should be performed instead of all terminals simultaneously or randomly.

According to the disclosed embodiments, one or more outroutes within the beam <NUM> can be designated for the multicast service delivery. Outroute_3, for example, has been designated for the multicast delivery. Terminals <NUM> that are currently receiving the multicast service must therefore remain on outroute_3. However, outroute_3 carries both unicast and multicast traffic, and contains terminals <NUM> receiving unicast traffic as well as terminals <NUM> receiving both unicast and multicast traffic. This is necessary because terminals <NUM> receiving the multicast traffic are typically engaged in at least one unicast session simultaneously.

According to at least one embodiment, the terminal initiated load balancing routine is overridden if a terminal <NUM> is currently receiving the multicast session. More particularly, terminals <NUM> that are currently within the multicast outroute will not move regardless of the traffic load in the multicast outroute relative to other outroutes in the beam <NUM>. Terminals <NUM> in the multicast outroute that are only involved with unicast traffic, however, would move to another outroute if the first threshold is exceeded. According to an embodiment, consideration can be given to the multicast bit rates occupying the multicast outroute, since these could change from time to time based on the link condition of active terminals <NUM>. Furthermore, the unicast traffic of the terminals participating in multicast reception is also taken into consideration for the load metric (traffic load) calculation.

As previously discussed, multiple thresholds can be established in order to trigger different types of load balancing. If a second threshold is reached, a network initiated load balancing routine can be implemented. For example, the gateway <NUM> and/or data center <NUM> (particularly the bandwidth manager <NUM> and the IPGW <NUM>) can initiate the load balancing routine. According to an embodiment, the data center can monitor Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) join messages from the terminals <NUM> in order to determine which will be receiving multicast sessions. The network initiated load balancing routine would not move any of the terminals <NUM> determined to be receiving the multicast sessions from the multicast outroute.

Since terminals <NUM> that are actively receiving a multicast session are not moved, it is possible that the traffic load on the multicast outroute can become much higher than the traffic load of the other outroutes in the beam <NUM>. According to one or more embodiments, the data center <NUM> can take various steps to prevent or reduce overload on an outroute or beam with only multicast traffic. A threshold committed information rate (CIR) can be established for each multicast outroute. The threshold can be statically configured or derived based on the available estimated capacity of a beam <NUM> and the portion of the beam that can be used for multicast traffic. Different beams <NUM> can also have different configurations and maximum allowed CIR for multicast traffic.

According to an embodiment, a separate threshold can be set for the demand in multicast traffic. If the current demand for multicast traffic exceeds the threshold, multicast sessions and their respective priorities can be used to block lower priority multicast sessions so as to avoid dropping packets from the higher priority sessions. This can prevent multicast packets from being randomly dropped or discarded, thereby affecting all multicast sessions. Depending on the specific implementation, such a threshold can be set per virtual network operator (VNO). When a beam/outroute is carrying multicast sessions, the difference between the estimated beam/outroute capacity and the CIR currently used for multicast traffic can also be considered for the load balancing of unicast traffic across various outroutes within the beam <NUM>.

If the system <NUM> includes a flexible payload reconfigurable satellite, the position and size of a beam can be dynamically adapted to accommodate the number of terminals <NUM> receiving or attempting to receive the multicast traffic. According to one or more embodiments, a machine learning based analytics procedure can be used to predict the locations of predominant receivers of specific multicast traffic sessions. Furthermore, reconfigurations in the size and location of beams can be predefined based on static planning of multicast sessions and targeted receivers. Prior to the start of specific multicast sessions that will be broadcast to specific locations, the satellite payload can be switched or reconfigured automatically. When the multicast sessions end, the satellite payload configuration is automatically reversed.

<FIG> illustrates an embodiment for reducing or preventing traffic loss during load balancing operations. When a terminal <NUM> will move from a source (or first) outroute to a destination (or second) outroute as a result of load balancing, the IPGW <NUM> replicates traffic between the source and destination outroutes of the terminal <NUM>. More particularly, the IPGW <NUM> replicates forward link traffic of a terminal <NUM> (moving or selected to be moved) to both the source outroute CRO <NUM> and the destination outroute CRO <NUM> during the switching or moving process. According to such a feature, the system of <FIG>, for example, can reduce or minimize traffic loss or outage, particularly for UDP traffic.

<FIG> illustrates a system <NUM> for load balancing of unicast and multicast traffic, according to an embodiment. The system <NUM> includes one or more coverage beams <NUM> (only one shown) which provide communication by means of one or more outroutes. As illustrated in <FIG>, illustrated coverage beam <NUM> includes outroute_1, outroute_2, and outroute_3. It should be noted, however, that the number of outroutes is only intended to be illustrative, and in no way limiting. The coverage beams (or beams) <NUM> can be configured such that they include more outroutes or less outroutes. Although not shown in <FIG>, the system <NUM> includes at least one satellite which generates the beams <NUM> to facilitate a bent pipe communication path.

According to the embodiment illustrated in <FIG>, the outroutes of the coverage beam <NUM> are served by two gateways, namely gateway_1 412A and gateway_2 412B. Although only two gateways <NUM> are shown, it should be noted that other implementations can incorporate additional gateways depending on the system configuration and requirements. Gateway_1 412A is configured to serve outroute_1 and outroute_3, while gateway_2 412B is configured to serve outroute_2. Furthermore, outroute_3 is designated for supplying multicast traffic. In order to support the use of multiple gateways <NUM> managing traffic within the same beam, the system <NUM> can include a satellite having flexible and/or reconfigurable payload capabilities.

The gateways <NUM> can connect to a network, such as a backhaul network <NUM>, in order to establish communication with one or more centralized data centers <NUM> such as the NMS shown in <FIG>. The gateways <NUM> can also utilize public/private networks <NUM> to communicate with the data center <NUM>. According to the illustrated embodiment, the data center <NUM> can include one or more IP gateways (IPGW) <NUM>, one or more code rate organizers (CRO) <NUM>, and a bandwidth manager <NUM>. The IPGW <NUM> is configured to provide layer-<NUM> and layer-<NUM> functionality by processing packets transmitted to, and received from, the internet <NUM>.

According to the illustrated embodiment, at least one IPGW <NUM> is configured with multi-outroute capabilities. A single IPGW <NUM> can therefore be used to serve outroutes that are fed from two different gateways. Such a configuration differs from prior systems where a particular beam can only be served by a single gateway. In such prior systems, both or all outroutes across which load balancing occurs must be fed from the same gateway and thus the same RFT. The multi-outroute IPGW <NUM> illustrated in <FIG>, however, advantageously allows terminals <NUM> to maintain TCP connections intact with PEP functionality because they remain on the same IPGW <NUM> even if the outroute move triggers a gateway switch.

The CRO <NUM> is configured to determine the modulation and coding (ModCod) applied to the signal stream in order to generate an output signal which optimizes spectrum utilization. The CRO <NUM> can also estimate bandwidth capacity and arrange incoming data from the IPGW <NUM> into a data stream which is subsequently transmitted to the terminals <NUM>. The bandwidth manager <NUM> is configured to allocate bandwidth for all terminals <NUM> supported by the two gateways <NUM>. Depending on the specific implementation, the data center <NUM> can be collocated with one of the gateways <NUM>. Furthermore, the functionality of the data center <NUM> can also be incorporated into hardware and/or software components of either gateway <NUM>.

According to various embodiments, the system <NUM> can be configured to assign multicast outroutes in either a static or dynamic manner. For static assignment, the system <NUM> (particularly the data center <NUM>) can designate a particular outroute for all multicast traffic (or multicast services) either permanently or for an extended period. Any terminal <NUM> wishing to receive multicast services would need to first identify and register with the gateway (412A or 412B) responsible for managing the multicast outroute. The terminal <NUM> would then move to the designated outroute (or multicast outroute). If the IPGW <NUM> includes multi-outroute capabilities, movement between different gateways <NUM> would be transparent to the terminals when a change in outroute occurs.

For dynamic assignment, the IPGW <NUM> automatically selects or designates an outroute for multicast traffic. The IPGW <NUM> then announces on all outroutes within the beam <NUM> that the multicast is coming over the designated outroute. The IPGW <NUM> can also announce the gateway responsible for managing the designated outroute. All terminals <NUM> interested in receiving the multicast would identify the gateway <NUM> managing the designated outroute (if it is not announced), register with the gateway, and move to the designated outroute. Movement between different gateways <NUM> would be transparent to the terminals <NUM> when a change in outroute occurs, if the system <NUM> includes at least one IPGW <NUM> which has multi-outroute capabilities.

According to the illustrated embodiment, the system <NUM> can perform load balancing routines that are initiated by either a terminal or the network. Terminal initiated load balancing can be dynamically performed on a per terminal basis, using load metrics received from the data center <NUM>. Each terminal <NUM> utilizes this information to independently determine if it is currently in an outroute with a high traffic load, and initiates load balancing. If the necessary threshold criteria is satisfied, the terminal <NUM> can move to a destination outroute corresponding to the outroute having the lowest traffic load. In addition to the features described in the embodiment illustrated in <FIG>, the terminal <NUM> must determine if the destination outroute is managed by a different gateway from its current gateway. According to various embodiments, the data center <NUM> can also establish predetermined intervals at which terminals <NUM> can check the first threshold to see if load balancing should be performed. Multiple intervals can also be established such that groups of terminals <NUM> check the first threshold to see if load balancing should be performed instead of all terminals simultaneously or randomly.

As previously discussed, multiple thresholds can be established in order to trigger different types of load balancing. If a second threshold is reached, a network initiated load balancing routine can be implemented. For example, the gateway <NUM> and/or data center <NUM> can initiate the load balancing routine to select terminals that are eligible for moving. According to an embodiment, the data center <NUM> can monitor IGMP or MLD join messages from the terminals <NUM> in order to determine which will be receiving multicast sessions. The network initiated load balancing routine would not move any of the terminals <NUM> determined to be receiving the multicast sessions from the multicast outroute. According to one or more embodiments, the data center <NUM> can prevent or reduce overload of an outroute or beam with only multicast traffic by establishing a threshold CIR for each multicast outroute. The threshold can be statically configured or derived based on the available estimated capacity of a beam <NUM> and the portion of the beam that can be used for multicast traffic. Different beams <NUM> can also have different configurations and maximum allowed CIR for multicast traffic.

Since multiple gateways <NUM> are used to manage the outroutes, the data center can identify the gateway managing the destination outroute for each selected terminal that must be moved. If the destination outroute of a terminal <NUM> is managed by a different gateway from the terminal's current gateway, the terminal <NUM> must be associated, or registered, with the gateway of the destination outroute prior to moving. According to one or more embodiments, the data center <NUM> can include one or more multi-outroute IPGWs <NUM> capable of transparently facilitating terminal transition from one gateway to another.

<FIG> is a flowchart illustrating steps for performing load balancing on beams having both unicast and multicast traffic. At <NUM>, a multicast outroute is designated from a plurality of outroutes within a beam. According to one or more embodiments, more than one multicast outroute can be designated. At <NUM>, the traffic loads of each outroute within the beam are compared. As previously discussed, the data center can generate a load metric for each outroute within the beam, and subsequently transmit the load metrics to all terminals. Accordingly, each terminal would be capable of comparing the traffic load associated with each outroute contained in the beam.

At <NUM>, it is determined whether the variations in the traffic loads of all outroutes exceed a predetermined threshold. According to an exemplary embodiment, the predetermined threshold can be based on a difference between the outroute having the highest traffic load and the outroute having the lowest traffic load, between the traffic load of an outroute in which a particular terminal is currently located and the outroute having the lowest traffic load, etc. Those skilled in the art can select the specific details of setting the threshold based on desired system configuration, level of precision, etc. If the threshold is set for <NUM>%, for example, the terminal can check to see if the variation between the traffic load of its current outroute is greater than <NUM>% of the outroute having the lowest traffic load. If the variation does not exceed the threshold, then it is not necessary to perform any load balancing, and the process would end. If the variation exceeds the threshold, then a load balancing routine is performed at <NUM>.

At <NUM>, one or more terminals are selected to be moved from a current outroute to a destination outroute. At <NUM>, it is determined whether the selected terminal, or terminals, is currently receiving multicast traffic. If any of the terminals is currently receiving multicast traffic, control passes to <NUM>. These terminals are not moved because such a movement would interrupt the multicast traffic currently being received. Accordingly, the system can be configured to override any load balancing activities that would move such terminals. The process would subsequently end.

If it is determined, however, that the selected terminals are not receiving multicast traffic, then control passes the <NUM>. The selected terminals are then moved to a destination outroute. For example, if the load balancing routine is initiated by a predetermined terminal, then only the predetermined terminal would be selected to move to the destination outroute. If the load balancing routine is initiated by the network, however, then some terminals may be selected for moving, while other terminals may be ineligible for moving. The selected terminals can also be moved to different destination outroutes, as appropriate to balance the traffic loads across all outroutes within the beam. The process ends at <NUM>.

<FIG> is a flowchart illustrating steps for performing load balancing on beams having both unicast and multicast traffic, in accordance with various embodiments. At <NUM>, it is determined whether a static multicast outroute is desired. If a static multicast outroute is desired, then control passes to <NUM>. The system designates a particular outroute for carrying multicast traffic. If a static multicast outroute is not desired, then control passes to <NUM>. The system dynamically selects an outroute to designate for carrying multicast traffic. The outroute can be designated to carry multicast traffic for a specific length of time (e.g., 2hrs. ) or desired time slot (e.g., 8pm - 9pm). At <NUM>, the system announces the designated multicast outroute to all terminals within the beam. The announcement can include all necessary details for receiving the multicast traffic. For example, if the multicast traffic will contain premium content that must be purchased in advance, certain information required to authenticate the purchase can also be included in the announcement.

At <NUM>, any terminals interested in receiving, or qualified to receive, the multicast traffic move from their current outroute to the outroute designated for multicast traffic. At <NUM>, traffic loads from all outroutes within the beam are compared to each other. As previously discussed, this can be facilitated based on the data center supplying load metrics for all outroutes to the terminals in the beam. At <NUM>, it is determined whether variations in the traffic loads of the different outroutes exceed a second threshold. According to the illustrated embodiment, the second threshold can be the higher of <NUM> predetermined threshold values set by the system or an operator. Thus, if the second threshold is set at <NUM>%, then the first threshold would have to be a lower value, such as <NUM>% or <NUM>%.

If it is determined that the variations exceed the second threshold, then control passes to <NUM> where a network initiated load balancing routine is performed. Control then transfers to <NUM>. If the variations do not exceed the second threshold, then control passes to <NUM>. At <NUM>, it is determined whether variations in traffic loads exceed a first threshold. If the variations do not exceed the first threshold, then control transfers to <NUM> where the process ends. If the variations exceed the first threshold, however, then a terminal initiated load balancing routine is performed at <NUM>. As previously discussed, the first threshold is lower than the second threshold. Thus, a higher threshold is established for the system to intervene for any load balancing in order to provide an opportunity for the terminals to redistribute themselves.

At <NUM>, terminals that are eligible for moving are selected. If a terminal initiated load balancing routine was performed, then only one terminal would be selected for movement. As previously discussed, terminal initiated load balancing is independently performed by each terminal. Accordingly, only one terminal would be eligible for movement if the first threshold is exceeded. If the load balancing routine is initiated by the network, then multiple terminals may be eligible for movement. At <NUM>, it is determined whether multiple gateways are being used to manage the outroutes within the beam. If a single gateway is being used, then control passes to <NUM>. If multiple gateways are being used, then the gateway managing the destination outroute for each terminal is identified at <NUM>.

According to one or more embodiments, steps <NUM> and <NUM> can be omitted if the data center includes one or more multi-outroute capable IPGWs. At <NUM>, it is determined whether any of the selected terminals are currently receiving multicast traffic. If any of the selected terminals are currently receiving multicast traffic, then they are not eligible for movement. This is indicated at <NUM>. Network initiated load balancing can therefore include some terminals that are eligible for moving and others that ineligible because they are currently receiving multicast traffic.

At <NUM>, each terminal selected for moving registers or associates itself with the appropriate gateway, if the destination outroute is managed by a different gateway from the terminal's current gateway. If only one gateway is used, or the data center includes a multi-outroute capable IPGW, then it may not be necessary to register with the gateway. More particularly, if a single gateway is being used, then all terminals have already been registered with the gateway. If multiple gateways are being used, various embodiment provide for a multi-outroute IPGW configured to transparently facilitate the terminal transition from one gateway to another. At <NUM>, all of the selected terminals are moved to the destination outroute. As previously discussed, if a terminal initiated load balancing routine is performed, only one terminal would be eligible for moving. If the load balancing routine is network initiated, then multiple terminals may be eligible for movement. Furthermore, such eligible terminals can be moved to different outroutes within the beam in order to balance the traffic loads. The process ends at <NUM>.

The disclosed load balancing features are applicable to both physical outroute or to outroute streams on a physical outroute. For example, a physical outroute can contain multiple streams. One stream can be allocated to carry multicast traffic, while the remaining streams of the physical outroute are used to carry unicast traffic. The data center can subsequently announce details pertaining to the stream that will carry the multicast traffic. If the system incorporates beam hopping functionality, the same multicast can be sent through only one feeder uplink and terminals on multiple beams can receive it by configuring the satellite to replicate the multicast. According to various embodiments, the disclosed systems can be configured to identify the extended failure of an outroute providing the multicast service vs. the transient loss of an outroute due to rain attenuation. If the multicast outroute goes away due to extended failure, terminals can automatically move to another outroute for point to point service, thereby preventing being stuck without service on an outroute that is not available. The terminal can check the status of the outroute periodically, and move back when the outroute recovers. On the other hand, if the outroute goes away due to rain attenuation, the terminal would not move away from the multicast outroute and will only experience a temporary outage period.

Various features described herein may be implemented via software, hardware (e.g., general processor, Digital Signal Processing (DSP) chip, an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Arrays (FPGAs), etc.), firmware or a combination thereof. For example, such hardware/software/firmware combinations can be incorporated into the previously described terminals, receivers, transmitters, transceivers, gateway, data center, bandwidth manager, IPGW, CRO, NMS, baseband components, etc. Additionally, such hardware can be interfaced to connect and/or facilitate communication between different components such as the CRO, IPGW, and bandwidth manager.

Furthermore, various features can be implemented using algorithms illustrated in the form of flowcharts and accompanying descriptions. Some or all steps associated with such flowcharts can be performed in a sequence independent manner, unless otherwise indicated. Those skilled in the art will also understand that features described in connection with one Figure can be combined with features described in connection with another Figure. Such descriptions are only omitted for purposes of avoiding repetitive description of every possible combination of features that can result from the disclosure.

The terms software, computer software, computer program, program code, and application program may be used interchangeably and are generally intended to include any sequence of machine or human recognizable instructions intended to program/configure a computer, processor, server, etc. to perform one or more functions. Such software can be rendered in any appropriate programming language or environment including, without limitation: C, C++, C#, Python, R, Fortran, COBOL, assembly language, markup languages (e.g., HTML, SGML, XML, VoXML), Java, JavaScript, etc. As used herein, the terms processor, microprocessor, digital processor, and CPU are meant generally to include all types of processing devices including, without limitation, single/multi-core microprocessors, digital signal processors (DSPs), reduced instruction set computers (RISC), general-purpose (CISC) processors, gate arrays (e.g., FPGAs), PLDs, reconfigurable compute fabrics (RCFs), array processors, secure microprocessors, and application-specific integrated circuits (ASICs). Such digital processors may be contained on a single unitary IC die, or distributed across multiple components. Such exemplary hardware for implementing the described features are detailed below.

Fig. <NUM> is a diagram of a computer system that can be used to implement features of various embodiments. The computer system <NUM> includes a bus <NUM> or other communication mechanism for communicating information and a processor <NUM> coupled to the bus <NUM> for processing information. The computer system <NUM> also includes main memory <NUM>, such as a random access memory (RAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random-access memory (DDR SDRAM), DDR2 SDRAM, DDR3 SDRAM, DDR4 SDRAM, etc., or other dynamic storage device (e.g., flash RAM), coupled to the bus <NUM> for storing information and instructions to be executed by the processor <NUM>. Main memory <NUM> can also be used for storing temporary variables or other intermediate information during execution of instructions by the processor <NUM>. The computer system <NUM> may further include a read only memory (ROM) <NUM> or other static storage device coupled to the bus <NUM> for storing static information and instructions for the processor <NUM>. A storage device <NUM>, such as a magnetic disk or optical disk, is coupled to the bus <NUM> for persistently storing information and instructions.

The computer system <NUM> may be coupled via the bus <NUM> to a display <NUM>, such as a light emitting diode (LED) or other flat panel displays, for displaying information to a computer user. An input device <NUM>, such as a keyboard including alphanumeric and other keys, is coupled to the bus <NUM> for communicating information and command selections to the processor <NUM>. Another type of user input device is a cursor control <NUM>, such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor <NUM> and for controlling cursor movement on the display <NUM>. Additionally, the display <NUM> can be touch enabled (i.e., capacitive or resistive) in order facilitate user input via touch or gestures.

According to an exemplary embodiment, the processes described herein are performed by the computer system <NUM>, in response to the processor <NUM> executing an arrangement of instructions contained in main memory <NUM>. Execution of the arrangement of instructions contained in main memory <NUM> causes the processor <NUM> to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the instructions contained in main memory <NUM>. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement exemplary embodiments. Thus, exemplary embodiments are not limited to any specific combination of hardware circuitry and software.

The computer system <NUM> also includes a communication interface <NUM> coupled to bus <NUM>. The communication interface <NUM> provides a two-way data communication coupling to a network link <NUM> connected to a local network <NUM>. For example, the communication interface <NUM> may be a digital subscriber line (DSL) card or modem, an integrated services digital network (ISDN) card, a cable modem, fiber optic service (FiOS) line, or any other communication interface to provide a data communication connection to a corresponding type of communication line. As another example, communication interface <NUM> may be a local area network (LAN) card (e.g. for Ethernet™ or an Asynchronous Transfer Mode (ATM) network) to provide a data communication connection to a compatible LAN. Wireless links can also be implemented. In any such implementation, communication interface <NUM> sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information. Further, the communication interface <NUM> can include peripheral interface devices, such as a Universal Serial Bus (USB) interface, a High Definition Multimedia Interface (HDMI), etc. Although a single communication interface <NUM> is depicted in Fig. <NUM>, multiple communication interfaces can also be employed.

The network link <NUM> typically provides data communication through one or more networks to other data devices. For example, the network link <NUM> may provide a connection through local network <NUM> to a host computer <NUM>, which has connectivity to a network <NUM> such as a wide area network (WAN) or the Internet. The local network <NUM> and the network <NUM> both use electrical, electromagnetic, or optical signals to convey information and instructions. The signals through the various networks and the signals on the network link <NUM> and through the communication interface <NUM>, which communicate digital data with the computer system <NUM>, are exemplary forms of carrier waves bearing the information and instructions.

The computer system <NUM> can send messages and receive data, including program code, through the network(s), the network link <NUM>, and the communication interface <NUM>. In the Internet example, a server (not shown) might transmit requested code belonging to an application program for implementing an exemplary embodiment through the network <NUM>, the local network <NUM> and the communication interface <NUM>. The processor <NUM> may execute the transmitted code while being received and/or store the code in the storage device <NUM>, or other non-volatile storage for later execution. In this manner, the computer system <NUM> may obtain application code in the form of a carrier wave.

The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to the processor <NUM> for execution. Such a medium may take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as the storage device <NUM>. Non-volatile media can further include flash drives, USB drives, microSD cards, etc. Volatile media include dynamic memory, such as main memory <NUM>. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise the bus <NUM>. Transmission media can also take the form of acoustic, optical, or electromagnetic waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a USB drive, microSD card, hard disk drive, solid state drive, optical disk (e.g., DVD, DVD RW, Blu-ray), or any other medium from which a computer can read.

Fig. <NUM> illustrates a chip set <NUM> upon which features of various embodiments may be implemented. Chip set <NUM> is programmed to implement various features as described herein and includes, for instance, the processor and memory components described with respect to Fig. <NUM> incorporated in one or more physical packages (e.g., chips). By way of example, a physical package includes an arrangement of one or more materials, components, and/or wires on a structural assembly (e.g., a baseboard) to provide one or more characteristics such as physical strength, conservation of size, and/or limitation of electrical interaction. It is contemplated that in certain embodiments the chip set can be implemented in a single chip. Chip set <NUM>, or a portion thereof, constitutes a means for performing one or more steps of the figures.

The processor <NUM> and accompanying components have connectivity to the memory <NUM> via the bus <NUM>. The memory <NUM> includes both dynamic memory (e g. , RAM, magnetic disk, re-writable optical disk, etc.) and static memory (e.g., ROM, CD-ROM, DVD, BLU-RAY disk, etc.) for storing executable instructions that when executed perform the inventive steps described herein. The memory <NUM> also stores the data associated with or generated by the execution of the inventive steps.

Claim 1:
A method comprising:
designating a first outroute for supplying at least multicast traffic within a beam (<NUM>, <NUM>) of a satellite communication system (<NUM>), wherein the beam includes a plurality of outroutes and the plurality of outroutes carry both multicast and unicast traffic;
comparing traffic loads of each outroute of the plurality of outroutes within the beam, including the first outroute;
determining if variations in the traffic loads of the plurality of outroutes exceed a predetermined threshold;
performing a load balancing routine, when the variations exceed the predetermined threshold, to redistribute the traffic loads of the plurality of outroutes by moving at least one terminal (<NUM>, <NUM>, <NUM>) to a second outroute within the beam; and
excluding, from the load balancing routine, any terminal within the first outroute and within all other outroutes of the plurality of outroutes that is actively receiving the multicast traffic.