WO1999045652A2 - Architecture for a ground system terminal for a broadband network - Google Patents

Abstract

The present invention provides a basic platform/architecture for customer premises equipment (CPE) for use in communications systems such as satellite communications systems. The present invention provides a CPE (400) which is capable of transferring data to and from a plurality of different systems having different infrastructures associated therewith. This data is processed to a data form that is supplied to a multimedia services core processor (404) which is responsible for data, service and network management functions and for providing a plurality of features such as security and accounting - to name a few. The output of the core processor is supplied, via an open interface architecture, to one or more of application specific variants (406) for coupling to one or more corresponding user equipment. Such application specific variants may provide appropriate interface to user equipment such as televisions, personal computers and video conferencing units.

Description

ARCHITECTURE FOR A GROUND SYSTEM TERMINAL FOR A BROADBAND NETWORK

Field of the Invention

This invention relates to communication systems and, in particular, to ground system terminals for transferring information between itself and a plurality of infrastructures and for interfacing to a plurality of application specific products.

Background of the Invention

Communication systems provide the medium by which one user at a first endpoint of the system may communicate to one or more other users of the system at one or more other endpoints. In order for users to communicate effectively, the users must be equipped with the proper terminal/equipment that is required and recognized by the system. Further, most, if not all, terminals of communication systems are designed to operate with one specific infrastructure for interfacing to one specific product. For example, a typical satellite receiver is capable of receiving information from only one infrastructure - a specific GEO satellite. Further, that satellite receiver is designed to interface to only one type of product - a video unit whether it be a VCR or TV. As a further example, a cable set-top box is capable of receiving information from only a cable TV infrastructure, and for interfacing only to a VCR or TV. It would be desirable, however, to provide a terminal for use with a communication system whereby the terminal has the capability to transfer information to and from a plurality of different infrastructures and for interfacing to a plurality of application specific products.

Brief Description of the Drawings

FIG. 1 is a block diagram illustrating an architecture of a satellite communications system in accordance with the present invention;

FIG. 2 is a block diagram illustrating a conceptual diagram of the satellite communications system of FIG. 1 ;

FIG. 3 is a block diagram illustrating, in more detail, the distributors virtual network manager (DVNM) of FIG. 1 ; FIG. 4 is a block diagram illustrating, in more detail, an architecture of the customer premises equipment (CPE) of FIG. 1 in accordance with the present invention;

FIG. 5 is a conceptual diagram illustrating the multimedia operating system of the CPE shown in FIG. 4; FIG. 6 is detailed block diagram illustrating one type of a

CPE for use in the system of FIG. 1.

Detailed Description of the Drawings

The present invention provides a basic platform/architecture for customer premises equipment (CPE) for use in communications systems such as satellite communications systems. Such a satellite communications system may take the form of the Celestri™ satellite communications system, being designed and developed by Motorola, Inc. or the satellite communications system being developed by Teledesic. The present provides a CPE which is capable of transferring data to and from a plurality of different systems having different infrastructures associated therewith. To name a few, the CPE may be responsive to data from the infrastructures associated with the Celestri™ or Teledesic satellite systems, direct satellite TV, or cable TV. This data is processed to a data form that is supplied to a multimedia services core processor which is responsible for data, service and network management functions and for providing a plurality of features as will be described herein. The output of the core processor is supplied, via an open interface architecture, to one or more application specific variants for coupling to one or more corresponding user equipment. Such application specific variants provide appropriate interfaces to user equipment such as televisions, personal computers and video conferencing units, for example.

The present invention is applicable to just about any terrestrial or satellite communications system. That is, any communication system can enjoy the advantages of the present invention since the CPE architecture is able to be used by a plurality of systems for providing a plurality of services.

Referring now to FIG. 1 , an architectural block diagram of the Celestri™ satellite communications system of which may utilize the present invention, is shown. System 100 includes a constellation of low-earth orbit (LEO) satellites 152, one or more mission operations control centers (MOCC) 156 which includes a satellite operations control center (SOCC) 158 and a network operation control center (NOCC) 160, one or more distributors virtual network managers (DVNM) 161 , and at least one customer premises equipment (CPE) as represented by home terminal 166, small business terminal 174, corporate terminal 176, gateway terminal 178 and broadcast feeder terminal 182.

Additionally, system 100 includes one or more GEO stationary earth orbit (GEO) satellites 154, also referred to as GSO satellites, that may be utilized for broadcast of high bandwidth data, whereby typically the LEO satellites provide interactive services to the CPE's since LEO satellites enable much smaller transit delays as compared to GEO satellites.

In the Celestri™ system, 63 LEO satellites are envisioned and will orbit the earth at approximately 800 miles above the surface of the earth, whereby up to 9 GEO satellites are envisioned and will orbit the earth at approximately 23,000 miles above the surface of the earth. Accordingly, the LEO satellites are typically used for interactive data that is sensitive to delay whereby the GEO satellites are typically used for the transmission of information that is not sensitive to delay and also for the broadcast of high bandwidth data. Note, however, that although that is what the satellites are typically used for, it is understood that the LEO satellites could also be used for the transmission of high bandwidth broadcast data, whereby GEO satellites could also be used for transmission and broadcast of interactive data if such delay is acceptable. In a preferred embodiment, satellites 152 are interconnected via optical inter-satellite links (ISL's) 162 to provide a global communication network infrastructure. In alternate embodiments, different types of links such as RF links may be used.

The satellite operations control center (SOCC) 158 typically includes the processing equipment, operator stations, software and other facilities used in the launching, control, maintenance, and decommissioning of the satellites in the constellations. Satellite operations processing and communications with the constellation are accomplished from two satellite operation control centers and local and remote antenna facilities using communication channels and the inner satellite network for continuous access to any satellite in the constellation. Further, the SOCC controls the flight orbit of the satellites within the system whereby it receives various telemetry data regarding the satellites describing, for example, its altitude, its speed, and whether it is in the correct orbital position. The SOCC also has the ability to fire the satellites' jets in order to control its orbit. The SOCC also has the ability to move the solar panels on the satellites as well as recharge its batteries.

Network operations control center (NOCC) 160 includes the processing equipment, operators' stations, software and other facilities that perform the network management functions allocated to the system management domain. Generally, a NOCC is co-located with a SOCC and shares the communications resources and other support facilities within a MOCC. The routing information included in a look-up table is desirably updated multiple times a minute to account for the motion of the LEO satellites. This information for the table updates is predetermined by a routing management function in the NOCC and block uploaded to the satellites. Distributor virtual network manager (DVNM) 161 controls the service and subscriber management for the system for each individual service provider. The Celestri™ system is fully operational with one DVNM, but it is anticipated that a number of service providers will sell access to the system and each of these providers will have at least one of their own DVNM.

Each CPE unit 166, 174, 176, and 178 have the capability to transmit and receive data to and from LEO satellites 152 and to receive broadcast data from GEO satellites 154. Further, terminal 182 is capable of transmitting data from the ground up to the GEO for re-broadcast to the other CPE units 166, 174, 176 and 178. The CPEs provide the subscriber interfaces to the Celestri™ system and also support a variety of network management functions for the associated DVNM. In the Celestri™ System, four classes of CPE terminals are envisioned: (1) gateway terminal 178, (2) corporate terminal 176, (3) small business terminal 174, and (4) direct-to-home terminal 166. Gateway terminal 178 provides an interface to a public switching telephone network (PSTN) or other public networks at data rates up to 155 million bits per seconds (Mbps). Corporate terminal 176 provides access for enterprise networking and provisioned private lines at data rates up to 51 Mbps. Small business terminal 174 is a VSAT class terminal designed to provide a variety of services for small businesses at a receive data rate of up to 16 Mbps and at a transmit data rate of up to10 Mbps. Direct-to- home terminal 166 is a small satellite terminal designed to provide multi-media and telecommuting services to the home at a receive data rate of up to 64 Kbps-16 Mbps and at a transmit data rate of up to64 Kbps-2 Mbps. Home terminal 166 may be coupled to, for example, TV 168, phone 170, and computer 172.

Additionally, system 100 includes a fifth type of CPE terminal as represented by broadcast feeder terminal 182 which is coupled to service provider 181. Terminal 182 is capable of uploading data to GEO satellites 154 at data rates up to 51 Mbps. Service provider 181 may also receive data from GEO satellites 154 at a rate of 20 Mbps, for example, for monitoring purposes, for example. Terminal 182 may also receive and transmit data to LEO satellites 154 if necessary. For example, terminal 182 may communicate with the LEO satellites for acknowledging, adding or deleting various user broadcast services whereby users of the system would uplink to the GEO services via the LEO satellites.

Referring now to FIG. 2, a conceptual network architecture 200 for the Celestri™ satellite communications system is shown.

Components shown in FIG. 2 that are identical to components shown in FIG. 1 are identified by the same reference numbers. The system includes local management domain 201 and system management domain 203 whereby a plurality of local management domains typically exist in the communications system.

System management domain 203 includes LEO satellites 152 and GEO satellites 154. LEO satellites 152 additionally include intersatellite links (ISL) 162 for transferring information between the various LEO satellites. System Management Domain 203 includes a primary MOCC 156 and a backup MOCC 213 whereby each MOCC includes a SOCC and NOCC as described above. The SOCC and NOCC are coupled to remote antenna facilities 215 for the transmission and reception of signals to and from LEO satellites 152 and GEO satellite 154. Further, MOCCs 156 and 213 are coupled to system domain business management center 217 whereby center 217 provides a clearing house for billing transactions between the DVNM's.

Local management domain 201 includes a plurality of CPE units such as CPEs 166, 174 and 176 (as well as CPEs 178 and 182 that are not shown in FIG. 2), as described with respect to FIG. 1 , as well as DVNM 161. In addition to the functions described with respect to FIG. 1 , the NOCC is responsible for managing the physical configuration of the network with the exception of the management of the subscriber CPE's, which is managed by the DVNM's. However, the NOCC manages the DVNM's and wholesales bandwidth to the DVNM's as well as monitors performance of the system and handles various faults within the system, for example, if one or more of the satellites are not operating properly, the NOCC will respond and re-route various satellite paths within the constellation.

Referring now to FIG. 3, a high-level block diagram of a distributors virtual network manager 300 is shown. DVNM 300 includes a local area network, or other distribution network, at the local site of the DVNM as depicted by distributor virtual network operational network 301. Block 303 is the operational data network which is typically a terrestrial network which ties in all the DVNM's as well as the NOCC and SOCC within the Celestri™ system. Network 303 is primarily useful when the Celestri™ system is first brought into functionality whereby network 303 provides a terrestrial network that is capable of providing end-to-end signal closure when there are less than a full constellation of satellites in orbit.

Virtual Network Antenna Facility (VNAF) 305 includes the antenna facility for the transmission and reception of signals 304 between the satellites and DVNM 300. It is understood that several VNAF 305's may be associated with each DVNM 300 to provide for geographical diversity such that each DVNM is not affected by rain/weather. For example, DVNM 300 may include at least two VNAF 305's separated by 30 to 50 miles. DVN Operations Manager 307 is responsible for setting up and removing connections for various calls within the Celestri™ system. For example, when DVNM receives a request from a CPE to set up a connection, it is received via VNAF 305 and passes through network 301 whereby DVN Operations Manager 307 first translates the native address of the CPE desiring to be called into a Celestri™ system address.

Manager 307 also verifies that the two CPE's desiring to communicate with one another are compatible. Also, Manager 307 then verifies whether the connection is authorized per the configuration, guidelines and/or rules associated with DVNM 300 and its corresponding DVNM, if not within DVNM 300. Finally, Manager 307 confirms that the requested bandwidth is available within the Celestri™ system.

DVN Service Manager 309 is responsible for various services or features that would ride on top of connections, for example, special calling features such as call waiting, call forwarding or three-way calling. Further, Manager 309 may also provide content, for example, by providing movies, database searches, or any other signals that may be on top of a connection. DVN Business Manager 311 is responsible for collecting billing information based on (a) the connection that Manager 307 has set up and (b) the services that are delivered via Manager 309. Manager 311 also collects billing information from the NOCC for the wholesale bandwidth that it has been allocated. That is, Manager 311 essentially buys wholesale bandwidth from the Network Operations Control Center and is responsible for reallocating such bandwidth to the various CPE's based upon demand and keeping track of such billing information for the CPE's within its distributor network. Referring to FIG. 4, a block diagram illustrating, in more detail, an architecture of the customer premises equipment (CPE) of FIG. 1 , is shown. FIG. 4 represents the basic architecture applicable to all CPEs 166, 174, 176, 178 and 182 of FIG. 1. CPE Architecture 400 includes three functional blocks as identified by capture information from broadband service block 402, multi-media services core system block 404, and application-specific variants block 406. Each block includes both hardware and software for implementing its desired function.

Block 402 is coupled to an outside medium for transferring information between that medium and core system 404. With respect to the outside medium, block 402 includes the necessary hardware and software for interfacing to a plurality of different infrastructures corresponding to different communications systems. To that end, block 402 provides the connectivity to a plurality of system networks such as, for example, the Celestri™ Satellite Communications System, an ADSL network associated with a telephone company, a local multi-media distribution service (LMDS) associated with a terrestrial communications system, a cable line associated with a cable company, the Teledesic System, satellite TV systems such as Direct TV and a high-speed data line for accessing the internet or the like. The purpose of block 402 is that whatever information is particular to information of a particular communications system's infrastructure, block 402 functions to capture such information from its corresponding service provider. Additionally, block 402 functions to isolate the physical transport medium from the rest of the components within CPE architecture 400. To that end, the output of block 402 includes data that typically is at base band, or at some IF, and such data is compatible with core system 404. Accordingly, core system 404 is not concerned about where the data came from or is going to, that is the function of block 402. Rather, core system 404 merely performs the necessary processing on data via a predetermined interface between blocks 402 and 404. The format of this baseband data transferred to core system 404 may take of an electrical bus/serial bus type of interface, for example, PCI bus, NU bus, or even DS3/T3 or OC-3 SONET format.

Multi-media services core system 404 operates in a multimedia system for transferring data to and from block 402 to provide management of data flowing through core system 404. Core system 404 also provides service management such as establishing connections and tearing down connections and verifying and confirming addresses, for example. Further, core system 404 provides various network management functions such as network configuration, detecting and reporting various faults and counting bits flowing through core system 404 for the purposes of accounting and billing, for example. That is, core system 404 handles the multimedia functions and operations that are common for data associated with the different infrastructures coupled to block 402 regardless of the particular business structure that the network provider is using.

Some of the services that may be provided by core system 404 include, but are not limited to, encryption, connectivity, information transportation, authentication, minimum delay service delivery, precedence/priority, call intercepting, multicasting, customer service, statistical data collection and reporting, and delayed service delivery. Multimedia services core system 404 also has the capability through its management functions to provide a plurality of features. Such features include, but are not limited to, security, accounting, extensibility, scalability, nomadicity and interactivity. In more detail, security is a feature that may be provided for providing both privacy and user authentication. These security features may be a set of tools that are provided to the application-specific variants block 406 so that they may be able to enjoy the privacy and authentication capabilities that are built into core system 404.

The feature of accounting may be provided for tracking various services that a service provider may want to bill for. For example, the accounting function may be counting bits moved, packets moved, cells moved, or consumption of a particular large block of data such as a movie. Note, that by utilizing the features of security and accounting, the present CPE architecture has the capability to provide secure billing to a user for a plurality of services that is being received by CPE architecture 400. Additionally, the feature of accounting may be used for metering and merging other services delivered or consumed in the home such as water, power, gas, or the like. The feature of extensibility may be provided whereby it is envisioned that each of the functions is expected to have an application programming interface (API) associated therewith so as to allow different combinations of the basic features to be used by service programmers such as by the Celestri™ system manufacturer, or other third-party software developers. This will be described in more detail with respect to the open interface architecture and block 406.

The feature of scalability refers to the ability to use CPE architecture 400 for a variety of different classes of CPE's such as those for the home use versus those for small businesses and large corporations. This basic architecture is scaleable for a plurality of different CPE embodiments whereby each embodiment is targeted for a particular type of user.

The feature of nomadicity refers to the feature of allowing users to have access to their subscribed services regardless of which CPE terminal they may be accessing at any particular time. Such a feature would envision the capability to identify the user desiring to access the CPE along with information describing which features/services that the user is authorized to access. The feature of interactivity refers to the capability of providing data in both directions. That is, although it was earlier described that broadband service block 402 provided data to core system 404, it is understood that core system 404 also supplies data to broadband service block 402. Further, data coming from the user's environment may be sent through application-specific variants block 406 to be processed by core system 404, and vice versa. CPE architecture 400 provides for a fully bi-directional terminal. The output of core system 404 is coupled to application- specific variants block 406 whereby the interface between blocks 404 and 406 is envisioned to be an open interface architecture. That is, the definition of how core system 404 communicates with application- specific variants 406 will be made available to the public. However, certainly a private/unpublished interface is well within the scope of the present invention. Examples of interfaces that may be used between blocks 404 and 406 include Windows™ interface, Macintosh Toolbox™ interface or UNIX drivers. Accordingly, this would allow many different vendors to create various application-specific variants that would communicate with core system 404 by providing the necessary interface between core system 404 and various user equipment. This open interface will have the capabilities of being (1 ) high speed, (2) standard and desirable by many users, (3) able to support multiple streams of data so as to allow core system 404 to provide necessary data to a plurality of users within the users' environments and (4) personal so as to allow for various personal features for each user. Application-specific variants 406 may take the form, for example, of various software for providing the necessary interface between core system 404 and user equipment capatible with ethernet, PCMCIA, ATM, CE bus and X10 standards, for example.

As an example, suppose that a user desires to implement a video conferencing system utilizing the CPE architecture 400. Such user would need to acquire a specific video card, i.e., an application specific variant, that would operate with their selected video equipment and that would interface with core system 404 via the open interface architecture. Such a video card would typically include hardware components as well as software drivers necessary for transferring data according to the selected open interface. This would allow the user to utilize CPE 400 to set up a video conferencing call whereby the video card would take the form of the application-specific variant of box 406, box 404 would perform the necessary processing and data and service and network management, and such information would then be sent out over a selected infrastructure medium, such as the Celestri™ system, via broadband service block 402. Further, this video information could then be received by another user and possibly one utilizing even a different infrastructure than the Celestri™ system provided that that user has the necessary application-specific variant card for such video conferencing.

Referring to FIG. 5, a conceptual diagram of multimedia operating system 500 of the CPE 400 of FIG. 4 is shown. Components shown in FIG. 5 that are identical to components shown in FIG. 4 are identified by the same reference numbers. Capture information from broadband service block 402 is shown to include an antenna subsystem 502 and an RF (radio frequency) subsystem 504. Antenna subsystem 502 is responsible for receiving and transmitting signals associated with a plurality of infrastructures whereby if satellite signals are being transferred, antenna subsystem 502 may include one or more phased array antennas or satellite dishes. RF subsystem 504 is responsible for the necessary down conversion and associated processing to take data from an external medium at some radio frequency and convert it to base band or some other suitable IF that may be processed by core system 404. Note that although block 402 of FIG. 5 shows components that are typically useful for the transmission and reception of wireless signals, such as satellite signals, it is understood that block 402 may also include hardware and/or software for the transmiision and reception of signals associated with hard-wired infrastructures such cable or telephone. FIG. 5 illustrates core system 404 in a more detailed functional architecture form. Core system 404 includes API 506 which is a portion of the open interface architecture between core system 404 and application-specific variants 406 which supports various features of the CPE architecture such as various strategic features 508 or various third-party features 510. Strategic features 508 are features that are provided by a core system manufacture, for example, which are envisioned to be strategic to the Celestri™ system or the overall multimedia operating system and may include, for example, video conferencing and on-demand consumption of videos. Third-party features 510 include various software interfaces for interfacing third- party products to core system 404 such as electronic point of sale products, electronic gaming products, home security units and messaging services.

CPE RF driver 512 constitutes the electrical interface to broadband service box 402 as aforementioned.

Standard interface drivers 514 constitute a portion of the application-specific variant 406 whereby the executive/kernel realtime operating system (RTOS) 516 would provide a way for plugging in standard interface drivers 514 whereby RTOS 516 would constitute a portion of the open interface architecture between core system 404 and application-specific variants 406. Drivers 514 are coupled to a plurality of hardware devices such as networks 518, telecom 520, computing devices 522, and entertainment devices 524.

Underneath API 506 there exists core user functions 526, core signaling functions 528, and core management functions 530 which correspond to the data management, service management, and network management functions as discussed with respect to FIG. 4. Security functions 532 provide the security features as was discussed with respect to FIG. 4 for providing privacy and authentication. Thus, FIG. 5 illustrates that there are a variety of core functions, as illustrated with respect to blocks 526, 528, 530, and 532, and then residing on top of those core functions, via an API (506), is a plurality of additional features as identified by blocks 508 and 510.

In a preferred embodiment, RTOS 516 may take the form of, for example, any of numerous commercially-available real-time operating system products that are well known to one skilled in the art. Alternately, a custom operating system could be used.

CPE resources 536 and SIM resources 538 is intended to represent the hardware associated with the physical implementation of the CPE terminal. In CPE resources 536, there exists the processor, the memory, and the DSP that are in the terminal itself. Further, SIM resources 538 are intended to represent the processors and memories in a smartcard that may be plugged into the terminal when a user desires to interface and use the terminal.

Referring to FIG. 6, a detailed block diagram illustrating one type of a CPE unit is shown. CPE terminal 600 of FIG. 6 is a preferred embodiment of a direct-to-home terminal as aforedescribed and represented in FIG. 1 as component 166. CPE 600 takes the form of the CPE architecture illustrated in FIG. 4 whereby components shown in FIG. 6 that are identical to components shown in FIG. 4 are identified by the same reference numbers. As shown in FIG. 6, CPE 600 includes one transmit path 602 and two receive paths, 604 and 606, relative to the LEO satellites and one receive path 608 relative to the GEO satellites.

Transmit path 602 for the LEO system includes LEO modulators 670 which modulates data packets provided to it by the processor 678 and supplies these packets to the LEO upconverter 652. Upconverter 652 upconverts the signal to the transmission frequency where it is then amplified by LEO power amplifier 650 and then sent to beam-forming circuitry 630 and eventually to antenna 636 for transmission to one or more LEO satellites.

Receive path 604, which is identical to receive path 606, includes antenna 638 for receiving signals from LEO satellites. Antenna 638 is coupled to beam-forming circuitry 632. Once the signal is received, it is then supplied to downconverter 648 which downconverts the receive signal to some desired IF (intermediate frequency) signal. The IF signal is then sent to LEO demodulators 666 for demodulating the receive signal and then eventually being processed by processor 678. LEO receive path 606 is identical to LEO receive path 604 as previously described, whereby components 640, 634, 646 and 664 of receive path 606 correspond to components 638, 632, 648 and 666 of receive path 604, respectively.

Receive path 608 is used for receiving signals from a GEO satellite whereby signals are first received by antenna dish 642 which is sent to downconverter 644 and to GEO demodulator 662 for eventual processing by processor 678. It is noteworthy that CPE 600, since it is a home terminal, illustrates only one receive GEO path. However, other classes of CPE's that may transmit to GEO satellites would include a transmit path to transmit signals to a GEO satellite and would look similar to transmit path 602 for LEO satellites. Timing and control subsystem 668 is the unit within CPE 600 that coordinates and synchronizes the transmit and receive paths. That is, timing control unit 668 coordinates the timing of the LEO transmitters via the LEO modulator block 670 whereby subsystem 668 plays an important function since CPE 600 must transmit a signal ahead of time to a destination satellite so that it arrives at the satellite at the expected time. The timing and control subsystem 668 also measures the reception of signals through receive paths 604 and 606 via LEO demodulators 666 and 664 and through receive path 608 via GEO demodulator 662. Further, timing control subsystem 668 controls the frequency of the demodulators to take into account Doppier effects of the satellites.

Processor 678 controls all of the demodulators, the timing control subsystem 668 and beam steering subcircuitry 660 via the interface between processor 678 (of core system 404) and capture information from broadband service block 402. Core system 404 includes processor 678, memory 676, and RAM 674 as well as SIM I/O 680 and CPE time unit 682. It is understood that components 674, 676, and 678 are shared between core system 404 and applications-specific variants section 406. However, one skilled in the art will easily recognize that each unit 404 and 406 may include separate processors, memories (i.e., nonvolatile), and RAM without departing from the spirit and scope of the invention. CPE time reference 682 functions to control components within the RF subsystem by providing accurate time information.

Security interface module (SIM) I/O (input/output) unit 680 provides privacy and authentication by authenticating the user of CPE 600 as well as authenticating CPE 600 for its specific services.

Power conversion units 654 and 672 supply power to the outdoor and indoor units, respectively whereby the antennas, the beam forming circuitry and converters are typically included within the outdoor unit.

Processor 678 is then coupled to a plurality of interface units, via an open interface architecture, to user interfaces 684, computer interface 686, ethernet interface 688, TELCO interface 690, HDTV interface 692, and TV interface 694, for example.

Claims

1. An apparatus, comprising: broadband service circuitry having a plurality of inputs and an output, said plurality of inputs being capable of transferring information to and from a plurality of different infrastructures corresponding to different communications systems; and a core system having an input coupled to said output of said broadband service circuitry wherein said output of said broadband service circuitry provides data to said core system that is compatible with said core system regardless of which one of said plurality of different infrastructures said information originated from, said core system including an application protocol interface for providing an output having a predetermined signal protocol for use with interfacing to a plurality of application specific products.

2. The apparatus of claim 1 further including at least one application specific variant coupled to said output of said core system for providing an interface between said core system and a corresponding product.

3. The apparatus of claim 1 wherein said broadband service circuitry includes: at least one antenna for transmitting and receiving signals; and an RF subsystem for upconverting internal signals to a transmission frequency and for downconverting internal signal to an intermediate frequency.

4. The apparatus of claim 1 wherein said core system includes a multimedia operating system including: said application protocol interface; means, coupled to said application protocol interface, for performing a plurality of core functions including user, signaling and management functions; means, coupled to said application protocol interface, for performing security functions; and a real-time operating system coupled to said application protocol interface.

5. The apparatus of claim 1 wherein said broadband circuitry includes: a transmit path for transmitting information to a LEO satellite; a first receive path for receiving information from a LEO satellite; and a second receive path for receiving information from a GEO satellite.

6. A method for handling information from a plurality of systems, the method comprising the steps of: receiving information from one of a plurality of different infrastructures corresponding to different communications systems; converting said information to data having a predetermined format regardless of which one of said plurality of infrastructures said information originated from; processing said data; and providing said processed data at an output.

7. The method of claim 6 wherein said step of processing data includes performing a plurality of core functions including user, signaling and management functions.

8. A customer premises equipment (CPE) for use with a satellite communications system, comprising: capture information circuitry coupled to receive and transmit data to LEO satellites and to receive data from at least one GEO satellite; a core processor coupled to said capture information circuitry, said core processor performing a plurality of core functions including user, signaling and management functions, said core processor including an application protocol interface for interfacing to a plurality of application specific products.

9. The CPE of claim 8 further including at least one application specific variant coupled to said core system for providing an interface between said core system and a corresponding product.