US20020104920A1

US20020104920A1 - Method and apparatus for loading satellite software while moving a satellite to a new orbit

Info

Publication number: US20020104920A1
Application number: US09/778,999
Authority: US
Inventors: Steven Thompson; David Whitefield; Rajeev Gopal
Original assignee: Individual
Current assignee: AT&T MVPD Group LLC
Priority date: 2001-02-08
Filing date: 2001-02-08
Publication date: 2002-08-08

Abstract

A method and system for increasing the availability of a satellite communications system is provided. A spare satellite is brought online by loading updated software in the satellite while the satellite is moving toward a new orbital position. The time required to bring the spare satellite into operation, and therefore restore service in the communication system, is thereby reduced.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is related to satellite communications and satellite control. More specifically, the present invention is directed to a method and system for increasing the availability of a satellite communications system by loading necessary software to a satellite while the satellite is in transit to a new orbit.

2. Description of the Prior Art

Telecommunications has become indispensable. Satellite telecommunication systems have an increasing role in meeting demand for telecommunications services. As satellite telecommunications systems come to be relied upon more and more, and as more and more entities and individuals depend on satellite telecommuncations, the reliability and availability of the satellite systems become more critical.

Individual satellites in a satellite telecommunication system inevitably fail, but there are typically spare satellites in orbit which can be brought online to restore service. However, service will be unavailable in the area covered by the failed satellite from the time of failure until the spare satellite is brought into operation. It is therefore desirable to minimize the amount of time required to bring a spare satellite into operation.

Typically, when a spare satellite is brought into operation, it is moved from one orbit to another. This may be for several reasons, including, but not limited to, placing the spare satellite into the same orbital position as the failed satellite, so that the many satellite terminals on the ground do not have to be reconfigured to regain service. Therefore, one of the important factors that determines the downtime until service can be restored is the time needed to place the spare satellite into its operational orbit.

Another factor which determines the minimum time to bring a spare satellite into operation is the time required to load software into the spare satellite to enable the satellite to perform telecommunications functions. As described below, satellites used in connection with the present invention employ sophisticated on-board processing, and the volume of software employed on-board the satellite is considerable. Because the software used by the satellite changes over time, and because the spare satellite is typically left in an inactive state while it is in its spare orbit, the latest version of the software typically needs to be uploaded to the spare satellite before the spare can be brought online. Thus, the volume of software that needs to be delivered has increased. Accordingly, the time required to deliver the software has also grown. In prior satellite systems, the software is delivered to the spare satellite either before or after the spare satellite is moved. Thus, the total time required to bring a spare satellite online is the combined time to move the satellite to a new orbit and to load the software.

SUMMARY OF THE INVENTION

It is an object of the present invention to increase the availability of satellite telecommunication systems by reducing the time required to bring a spare satellite into operation such as moving it into another orbital position. In accordance with one aspect of the invention, a method and system for loading software in a satellite communication system is provided. Software data is transmitted to the satellite over an available communications link such as a satellite tracking, telemetry and control (TT&C) link, while the satellite is moving to a new orbit.

In accordance with another aspect of the invention, a method and system for bringing a spare satellite online is described. Commands are transmitted to the satellite to cause the satellite to begin moving to a new orbit. While the satellite is moving to the new orbit, software data is transmitted to the satellite. Finally, commands are transmitted to the satellite to cause the satellite to remain substantially fixed in the new orbit.

BRIEF DESCRIPTION OF THE DRAWINGS

The various aspects, advantages and novel features of the present invention will be more literally comprehended from the following detailed description when read in conjunction with the appended drawings, in which: [0010]
FIG. 1 is a diagram of the components of a system in accordance with the present invention. [0011]
FIG. 2 is a diagram illustrating the paths of communication between various components in a system according to the present invention. [0012]
FIG. 3 is a block diagram of the payload of a satellite which may employ the present invention. [0013]
FIG. 4 is a diagram of an exemplary satellite communication system in which the present invention may be employed, and [0014]
FIG. 5 is a flow chart which illustrates the sequence of operations performed in accordance with an embodiment of the present invention.[0015]
Throughout the drawing figures, like reference numerals will be understood to refer to the same parts and components. [0016]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

System Overview [0017]
With reference to FIG. 1, the [0018] broadband multimedia system 10 of the present invention preferably employs one or more geosynchronous orbit (GEO) satellites 20 a, 20 b and offers a wide range of user data rates and services on a bandwidth-on-demand (BOD) basis. The system uses the latest generation of high-power satellites, employing in-board digital signal processing, multiple high-gain spot beams, and on-board packet routing. The broadband multimedia satellite system 10 is preferably capable of supporting a maximum peak capacity of at least 10 Gigabits per second (Gbps) of user data in a point-to-point (PTP) transmission mode. Delivery of services to users is provided via low-cost ultra-small-aperture terminals (USATs). The broadband multimedia satellite system 10 operates in the 30/20 GHz Ka-band spectrum allocated to Kaband Fixed Satellite Services (FSS). The system capacity is scalable by either the addition of satellites in adjacent orbital slots, or by adding satellites in the same orbital slot that are operated in a different frequency band to enable future system expansion.
The broadband multimedia satellite system is a Ka-band packet based transmission system that enables the offering of bandwidth-on-demand (BOD) connections in support of voice, data, video, and other interactive services and applications such as interactive digital communications and high-speed internet (HSI) access. The combination of small terminal size with high throughput makes the broadband multimedia satellite system useful for users ranging from large and medium-sized corporations and [0019] other organizations 12 to small businesses 14, and consumer/SOHO users 16. Raw data rates supported per single carrier are preferably 16.384 Mbps (8E1), 2.048 Mbps (E1), and 512 kbps (E1/4). A 128 kbps fall-back mode is also provided for improved availability of lower end terminal types. Interfaces into terrestrial networks (e.g., the public switched telephone network (PSTN) 18, cellular networks and corporate data networks) allow seamless integration into existing communications system infrastructures.
A fundamental difference between conventional FSS systems and the broadband [0020] multimedia satellite system 10 is the regenerative nature of the broadband multimedia satellite system payload. In a conventional FSS satellite system, a single beam typically services the satellite coverage area. Information transmitted by a central station is received by the satellite and broadcast to all user terminals within the footprint. The user terminals transmit back to their intended destination through the satellite to the hub station. Thus, the satellite simply acts as a repeater. Mesh connections (i.e., user terminal-to-user terminal connections) must always be routed through the hub creating additional latency, due to the double hop required.
In the broadband [0021] multimedia satellite system 10 of the present invention, however, the uplink uses multiple spot beams that provide coverage for uplink cells geographically distributed over the satellite coverage area. The system 10 is provided with a satellite payload which can combine inter-beam routing with a broadcast capability. Each uplink cell preferably operates on a fixed polarization with a four-cell reuse pattern to maximize capacity density. The downlink coverage sub-divides each uplink cell into preferably seven microcells.
Frequency reuse is supported via both spatial and polarization reuse. Reuse provides substantial capacity increases as the broadband multimedia satellite system realizes an average of 25 times reuse on both the uplink and the downlink. Additionally, the [0022] satellite 20 differs from conventional satellites in that user data or broadcast multimedia packets are processed, and routed by the satellite payload. The satellite 20 therefore performs a significant amount of the switching and routing responsibilities previously relegated to the network control facility of the central hub station in conventional FSS systems.
When operating in the PTP mode, the satellite payload receives a packet from an uplink cell and routes it only to the downlink cell in which a destination satellite terminal (ST) is located. The payload is also capable of replicating and routing a packet to up to forty multiple downlink cells for point-to-multi-point (PMP) applications. Finally, the system has the capability to transmit broadband multimedia packets to all ST's within the continental United States (CONUS), Alaska, Hawaii, predefined parts of Canada and selected Latin American cities. There are preferably two CONUS broadcast beams (one for each polarization) that simultaneously cover all or a portion of the satellite coverage area. [0023]
Network Operations Control Center [0024]
A network operations control center (NOCC) [0025] 22 is provided, as shown in FIG. 2, to perform a number of operations such as validating ST's for authorized use of the system 10 resources and to support scheduled connections or BOD traffic which can also be referred to as connection-oriented calls. Connection oriented calls involve an ST sending packets to one or more ST's at a fixed rate. The scheduled connections are based on configuration from the NOCC 22 that provides information such as when the connection is to be established, how long, the needed bandwidth, priority, etc. ST's support both scheduled-and on-demand connections. The on-demand connections are not authorized if the connection does not meet NOCC admission criteria. The connection setup first requires the NOCC admission control and then the Payload bandwidth allocation before packets can be sent.
The [0026] system 10 also supports connectionless traffic that does not require NOCC involvement to establish calls. For connectionless traffic, an ST sends a burst of packets to one or more ST's. The ST requests from the payload the number of packets that it wants to send (a volume request). The connectionless setup requires only a payload bandwidth allocation before packets can be sent (i.e. no NOCC admission control). Connectionless traffic may be further characterized by priority.
FIG. 2 illustrates the flow of data and/or commands and responses between the [0027] NOCC 22 and a number of other system 10 components which are discussed below. A wide area network (WAN) 24 connects the NOCC 22 to network service providers (NSP) 26, ST suppliers 28, customer ST's 30, satellite control facilities (SCF) 32, and a backup NOCC 34. The satellite links, that is, the packet network, is indicated at 36 in FIG. 2.
The [0028] NOCC 22 preferably performs a number of management operations. The NOCC 22 performs resource management operations, as illustrated at 38, such as mapping an external address such as an IP address corresponding to an ST to an internal address employed by the system 10. Other resource management operations can include registering and authenticating ST's prior to their admission to the system 10, reserving call connections and updating routing information. The NOCC maintains a number of databases that are useful for resource management such as a database for dynamic address maps, a database for schedule connections, a connections database, a connection record log, a routing database, a multicast membership roster and replication table, a resource allocation database, and a log of currently registered ST's.
The NOCC also performs capacity management operations such as uplink frequency planning and downlink broadcast power planning, as indicated at [0029] 39. The NOCC 22 determines wholesale bandwidth assignments to allow a wholesaler(s) to provide services and bandwidth to various retailers (e.g. NSP's 26). The retailers can then provide services and bandwidth to customers such as enterprises, extranets, SOHO's, telecommuters and other consumers. To support capacity management operations, the NOCC 22 maintains a number of databases such as uplink frequency allocation plans, downlink power cell plans, a table for avoiding downlink interference, a downlink queue mapping table, a downlink latency plan, CONUS beam forming coefficients, and weather data.
The [0030] NOCC 22 also performs a number of operations to manage the ST's, as indicated at 42, such as ST resource usage data collection and performance data collection, reporting operations (e.g. to NSP's and/or wholesalers for billing purposes), configuring ST's, software downloads, and ST status monitoring including fault detection, isolation and recovery. The NOCC 22 maintains several databases to support ST management operations, such as internal address maps, ST configuration data, ST resource usage and faults. In addition, the NOCC 22 performs ST service management operations such as ST service order handling, and ST quality of service (QoS) reporting. Additional ST data is maintained at the NOCC 22 such as ST usage and authorization levels, ST closed user groups, black lists for unauthorizes ST's, among other data. As indicated at 44, the NOCC 22 maintains a WAN connection to ST suppliers to exchange identification (e.g. electronic serial numbers or ESN's and security data).
The [0031] NOCC 22 also performs a number of operations to manage the satellite payload such as payload fault detection and isolation, configuring the payload and performing software downloads, performance data collection, ST resource allocation data collection from the payload, and payload security key updates. Accordingly, the NOCC 22 maintains databases for payload configuration and performance data, ST resource allocation, and payload faults. The databases can include, but are not limited to, demodulator configuration (e.g. uplink cell assignment, carrier rates and unique word (UW) assignment for correlation purposes), carrier availability (e.g. contention channel assignment, and channels available for BOD), security parameters for demodulators, inband link and BOD requests, a multicast table, downlink power control parameters (e.g. total power, shape beam parameters, and a power table), downlink interference parameters and scheduling parameters (e.g. queue mapping, TDMA slot control table, and latency timeout table), downlink antenna parameters (e.g. calibration data and shaped mean parameters) and congestion conrtol parameters. The payload sends traffic measurement data and status packets periodically to the NOCC 22 such as the number of packets received by each demodulator in the payload, packets sent to each destination location and BOD requests received from each uplink cell.
The [0032] NOCC 22 performs network management operations, business management operations and customer care operations. Network management operations include, but are not limited to, security management (e.g. via a key server), accounting management indicated at 46, configuration management, fault management, and SCF management indicated at 48.
The [0033] NOCC 22 performs a number of operations to manage itself, such as LAN equipment monitoring, WAN link monitoring and equipment management, database management and fault alarm management. Databases are maintained at the NOCC 22 to maintain such NOCC element management information as LAN configuration, WAN configuration, server configuration, software configuration, user and group configuration with respect to network operators, network engineers, customer care representatives and system administrators, faults operator profiles and audit logs, performance data, a redundant database, among other information. An NSP 26 interface is also implemented by the NOCC 22 to provide such operations as a firewall, security certificate handling, data access to other NOCC subsystems, proxy web servers, and an FTP distribution server, using NSP access control profiles maintained by the NOCC 22.
Satellite Payload [0034]
FIG. 3 is a block diagram of the [0035] payload 50 on-board the satellite(s) 20. The satellite payload 50 comprises receive antennas 52 a, 52 b for both right hand circular polarized (RHCP) and left hand circular polarized (LHCP) uplink beams from various uplink cells. Downconverters 54 (e.g. Ka-band downconverters) downconvert the frequency of the received signals to the frequency at which the signals may be processed by a switch matrix 56. The switch matrix 56 connects a variable number of demodulators 58 to each uplink cell based on demand.
The coverage region of the [0036] system 10 preferably comprises 112 uplink cells. The amount of uplink capacity in each cell is determined by the number of demodulators assigned to the cell. In the illustrated embodiment, 256 demodulators 58 are available for assignment, but preferably only 224 of them are assigned to cells at any given time. Each demodulator 58 preferably provides 96 512 kbps channels of capacity. A cell can be assigned from zero to as many as eight demodulators 58.
The uplink bandwidth of 500 MHz is divided into eight equal subbands of 62.5 MHz. Thirty-two [0037] demodulators 58 are available in each subband. A demodulator 58 is assignable to any uplink cell, but can only be assigned to one cell at a time (demodulators can be reassigned to new cells but cannot be shared between cells). The task of assigning frequencies to uplink cells can be viewed as two distinct tasks. First, frequency subbands are allocated to uplink cells subject to system contraints. Second, physical demodulators are assigned to the cell according to the subband allocation, subject to constraints imposed by the microwave switch matrix 60 on the payload 50.
The [0038] payload 50 preferably comprises 5376 E1, or the equivalent thereof, multi-rate demodulators 58 for E1/4. E1 and 8E1 transmissions, for example. A fast packet switch (FPS) 60 switches the outputs of the demodulators 58 among variable rate modulators (e.g. 24 modulators) 62. The FPS 60 is preferably a 10 gigabits per second (Gbps) asynchronous transfer mode or ATM-type fast packet switch. A payload control computer (PCC) 64 is provided to perform BOD and payload management operations. Ka-band direct input/output (I/O) modulators 66 generate hopping beams (e.g. 428 Mbps hopping beams) that are time division multiplexed with broadcast beams (e.g. two 147 Mbps broadcast beams). The dwell time per downlink cell is dynamically determined based on demand. A bypass configuration indicated generally at 68 allow use of the satellite 20 as a bent-pipe transponder with coverage that can be adjusted. A transmit antenna 70 that can generate, for example, 24 beams is connected to the outputs of the 24 modulators 66 or the bypass circuit 68.
IV. Spare Satellite Operation [0039]
An exemplary [0040] satellite telecommunication system 100 in which the present invention is employed is shown in FIG. 4. A first satellite 102 communicates with a set of satellite terminals (ST's) 104 via a high bandwidth communications link 106 that is preferably in the Ka band. A second satellite 108 is also shown. The second satellite 108 communicates with a second set of ST's 110 via another high bandwidth communications link 112, which is also preferably in the Ka band. The system 100 also comprises a spare satellite 114. The system 100 further comprises a satellite control facility (SCF) 116 which is responsible for controlling and monitoring the health and status of each of the satellites in the system. The satellites 12, 108 and 114, the ST's 104 and 110 and the SCF 116 operate as described above in connection with FIG. 3. It will be understood by those skilled in the art that the number of satellites and ST's shown is merely illustrative. The present invention may be employed in a satellite telecommunication system having more or fewer satellites, or more or fewer ST's.
Ordinarily, a Satellite Control Facility (SCF) maintains contact with and control over the satellites in a satellite system through tracking, telemetry and control RF links (TT&C). Through the TT&C link, the SCF is able to provide the primary control for the satellite, communicating with the satellite to maintain it in the desired operating condition and to monitor its health. The SCF controls the propulsion subsystem onboard the satellite, and delivers commands which cause the satellite to move to its new orbit. The SCF needs to be able to deliver commands to the satellite and monitor the satellite's health at essentially all times, and particularly while the satellite is being moved. Thus, the TT&C link is designed to be more robust than the communications channel of the satellite payload, which may be, for example, in the Ka band. The TT&C link transmits at a slower rate than the main communications channel of the satellite payload, but is correspondingly less susceptible to the doppler shifts and timing changes which occur while the satellite is moving from one orbit to another. [0041]
Furthermore, the capacity of the TT&C link is not fully utilized by the SCF. Thus, there is spare capacity for communicating with the satellite present in the TT&C link. Therefore, it would be desirable to utilize the spare capacity present in the TT&C link to reduce the time required to bring a spare satellite online. By transmitting required software to the satellite using the spare capacity present in the TT&C link while the spare satellite is moving into its operational position, rather than before or after the move, the total time required to bring the spare satellite into operation can be reduced. [0042]
With continued reference to FIG. 4, the [0043] SCF 116 communicates with each satellite via telemetry, tracking and control (TT&C) links 118, 120, 122, which operate at lower frequencies than the Ka band. Lower frequencies are utilized for the TT&C links because signals at these frequencies are more robust, and the high bandwidth Ka band channels 106, 112 may not be available while a satellite is being moved due to Doppler shifts, changing time delays, etc. Communication with the satellite throughout all phases of the satellite's mission is critical, therefore it is imperative that a communications channel be open to the satellite while the satellite is being moved to a new orbit. The TT&C links 118, 120, 122 are designed to be very robust, and are available throughout all phases of a satellite's mission. It is through the TT&C links 118, 120, 122 that the SCF 116 delivers commands to the satellites 102, 108, 114 that cause the satellite to move to a new position using the satellite's propulsion mechanism. The SCF 116 is also must be able to communicate with the satellite while the satellite is moving via the TT&C links in order to monitor the status of the satellite or to transmit commands.
As stated above, the present invention is particularly helpful when used in conjunction with a satellite that employs software to run payload equipment. The software is frequently updated and needs to be transmitted to the satellites periodically. However, the payloads of spare satellites are typically left in a powered off condition until they are needed. This is because powering up the payload periodically runs the risk of shortening the life of the spare satellite. Thus, it is undesirable to power up the spare satellite to upload updated software, and when a spare satellite is brought into operation to replace a failed satellite, the software in the spare satellite typically needs to be updated before the satellite can be made operational. [0044]
The software could be loaded either before or after the spare satellite was moved to its new orbit. However, as satellites become more sophisticated, the software required to run them, and to perform payload processing, becomes more voluminous. Thus, the delay in bringing a spare satellite into operation increases with the volume of software needed by the satellite, due to the time required to load the software. By way of example, the satellite of the present invention is sophisticated, and essentially operates as an internet router in the sky. Accordingly, the volume of software required to operate the satellite payload is on the order of tens of megabytes. If the software is loaded via the TT&C links, which are limited to 1200 baud, the software load may take several hours to complete. [0045]
In accordance with the present invention, the time required to bring a spare satellite online is reduced by transmitting the software to the satellite while the satellite is moving. Thus, one of the more time consuming steps necessary to bring the spare satellite into operation is accomplished during the move to the new orbital slot, rather than before or after the move to the new orbital slot. [0046]
The process of loading software while the satellite is moving is illustrated in FIG. 4. First, at [0047] step 200, a determination is made that one of the existing satellites has failed. Next, at step 202, the SCF 116 transmits commands to the spare satellite which cause the spare to begin moving to the orbital position held by the failed satellite. All satellite subsystems that are required for the move are powered on or enabled at this point.
During the move of the satellite, satellite subsystems/units which need significant (e.g. many hours) of warm up time to reach steady-state performance are powered on or enabled. Also, subsystems which have performance that must be trended or calibrated over significant amounts of time are powered on or enabled. In addition, the current set of security keys are loaded to the spare satellite. The NOCC notifies all NSP's of the outage. [0048]
At [0049] step 204, the SCF 116 monitors the status of the spare satellite throughout the move. This includes monitoring bus telemetry by means of a tracking antenna. The SCF 116 also performs satellite ranging and orbit determination during the drift. At step 206, the SCF begins transmitting updated software to the spare satellite. The SCF completes transmission of the updated software at step 208.
Once the satellite arrives at the destination orbital position, the [0050] SCF 116 transmits commands to the spare satellite causing it to remain in its new orbit, at step 210. In order to accomplish this, the SCF 116 sets up and causes the satellite to execute trajectory trim maneuvers and a burn to stop the satellite motion. Once the satellite has arrived in the new orbital slot, the SCF 116 performs fine adjustment of the satellite position, as well as ranging and orbit determination.
Finally, the spare satellite is brought into operation in the new orbit, at [0051] step 212. In order to bring the satellite into operation, the SCF 116 first initializes the inband communications between the NOCC and the satellite. However, before inband communication is possible, the following actions occur:
The spare satellite passes a suite of in orbit tests to ensure the operational integrity of the satellite prior to being placed into the parked state. [0052]
The payload and PCC are powered on. [0053]
The appropriate set of unique words are received by the satellite. [0054]
The active NOCC inband command key index is set at the satellite based on information received from the NOCC. [0055]
The initial configuration of the switch matrix and demodulators is received from the SCF. [0056]
At least two demodulators per CONUS uplink cell are configured to ensure connectivity from any CONUS location. [0057]
Downlink cell tables are initialized to assume no rain conditions. [0058]
PCC paramters and FPS congestion thresholds are initialized to default values. [0059]
Encryption in the inband link is enabled. [0060]
Once the inband link is operational, the payload may be configured very quickly for the proper time of day capacity plan. At this point, the NOCC is ready to use the spare satellite. The NOCC can then configure the payload of the satellite to the operational state. The capacity plan for the given time of day and day of week is loaded. The PCC is configured with the last values before the outage occurred. FPS congestion thresholds are set to the last values before the outage occurred. The switch matrix is configured for the given capacity plan. The demodulators are configured for the given capacity plan. A time of day (TOD) counter on-board the satellite is set to the next usable value. Downlink microcell power levels are set according to a radar weather feed. Satellite ephemeris data is set to the best known information, and updated frequently until orbit determination shows that operational accuracy is achieved, and thereafter nominal update intervals resume. CONUS shaped beam coefficients are set. The downlink TDM frame structure is set based on the given capacity plan. ST's are informed that transmission is not yet allowed. [0061]
Once the satellite is in an operational state, the NOCC begins enabling ST's. The NOCC staggers the resumption of service by groups of ST's to avoid overloads on contention channels. After all ST's have been enabled and communications are reestablished, service is considered to be restored. ST's may begin to transmit old usage data (from before the outage), and security key updates can occur at regularly scheduled intervals. [0062]
Although only a few exemplary embodiments of this invention have been described in detail above, those skilled in the art will readily appreciate that many modifications are possible in the exemplary embodiments without materially departing from the novel teachings and advantages of this invention. Accordingly, all such modifications are intended to be included in the scope of this invention as defined in the following claims. [0063]

Claims

What is claimed is

1. A method of transmitting software to a satellite comprising the steps of:

transmitting commands to the satellite to cause the satellite to begin moving toward a new orbital position selected from the group consisting of a different orbit and a different orbital slot,

transmitting software to the satellite over an available communications link while the satellite is moving toward said new orbital position, and

transmitting commands to cause the satellite to substantially stop moving toward said new orbital position.

2. The method of claim 1, wherein said available communications link is a TT&C link.

3. The method of claim 1, wherein said software comprises all of the information necessary to bring the satellite into an operational state.

4. The method of claim 1, wherein said new orbital position is a substantially geosynchronous orbit.

5. A method of moving a satellite to a new orbit comprising the steps of:

6. The method of claim 5, wherein said available communications link is a TT&C link.

7. The method of claim 5, wherein said software comprises substantially all of the information necessary to bring the satellite into an operational state.

8. The method of claim 5, wherein said new orbital position is a substantially geosynchronous orbit.

9. A system for moving a satellite to a new orbit comprising:

a satellite adapted to receive control signals over a communications link, and

a transmitter for transmitting control signals to the satellite, whereby said transmitter transmits control signals that cause the satellite to begin moving toward a new orbital position selected from the group consisting of a different orbit and a different orbital slot, and further transmits information necessary to bring the satellite into an operational state via the communications link while the satellite is moving to the new orbital position.

10. The system of claim 9, wherein said transmitter transmits control signals that cause the satellite to substantially stop moving once said satellite has reached said new orbital position after substantially all of said information has been received by the satellite.

11. The system of claim 9, wherein said new orbital position is a substantially geosynchronous orbit.