Apparatus, method and article of manufacture for transmitting data over a satellite

[0002] This application is related to U.S. patent application Ser. No. 08/746,901, filed Nov. 18, 1996, entitled System, Method and Article of Manufacture For Selecting a Gateway of a Hybrid Communication System Architecture, to Elliot, which is incorporated by reference in its entirety.

[0003] This application claims the benefit of U.S. Provisional Application No. 60/071,755, filed Jan. 16, 1998.

[0004] Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, or the patent disclosure as it appears in the Patent and Trademark Office.

[0005] This invention generally relates to improvements in computer systems, and, more specifically, to utilizing satellite broadcast technology as a bridge between telephony operations and the Internet.

[0006] Traditionally, data has been delivered to network-connected desktop personal computers either by broadcasting or unicasting, while the need for multicasting data has been unsatisfied. Broadcasting is a form of addressing wherein the destination address specifies all destinations; all destinations indiscriminately receive the data whether or not the data is needed by the destination computer. Where data is not needed at a particular network-connected personal computer, the transmission of the data is an inefficient use of resources. This can be particularly disabling to a network that does not have sufficient bandwidth capacity for all of the data traffic. Broadcasting is less efficient in direct relation to the proportion of users in the community of the broadcast that do not need the broadcast data.

[0007] In contrast, unicasting is a form of addressing where the destination address specifies a single destination. Unicasting eliminates the unnecessary transmission of data to destinations that have no need for the data, but is still inefficient because the data will be replicated on the network for each individual destination. For example, when data is transmitted to 20 personal computers connected to a server, 20 transmissions of the data will be made each with a different individual destination address.

[0008] Where data needs to be transmitted to a limited set of all network-connected personal computers, transmission-using broadcasting or unicasting falls short of efficient resource use. Multicasting offers more efficient resource use. Multicasting is a form of addressing wherein a source sends data to a server and the server sends one copy of the data to each of the destination computers. This form of addressing is particularly beneficial where the link between the source and the server has limited capacity or high cost because only one copy of the data that is intended for multiple recipients is transmitted to the server. Multicasting makes the most efficient use of an expensive link or a link that has insufficient capacity for transmission to multiple destinations by reducing the number of transmissions across the critical link to one, rather than requiring that multiple transmissions be made for each destination address.

[0009] One arena where multicasting is implemented is the Internet. Multimedia applications involve text, graphics, voice, video and hypertext operations. Multimedia applications typically require large amounts of data in comparison to traditional computer applications. The Internet has increasingly become the communication network of choice for the consumer marketplace. Multimedia applications exist on the Internet, but the throughput of the Internet limits the usefulness of multimedia applications because multimedia applications are highly interactive and require higher throughput than the Internet can provide. The limitations on bandwidth make the Internet more suitable and efficient for low bandwidth applications such as E-mail and smaller multimedia applications.

[0010] The Multicast backbone (MBONE) is a virtual network on top of the Internet which supports routing of Internet Protocol (IP) multicast packets, intended for multimedia transmission. MBONE enables public access to desktop video communications. However, the quality is poor, with only 3-5 frames per second instead of the 30 frames per second of commercial television. Therefore, transmission of multimedia data via the Internet is too slow, even using multicasting.

[0011] Two independent technologies have emerged that provide greater speed and throughput (Internet Protocol (IP) Multicast and Digital Video Broadcast) that together have the potential to provide for transmission of multimedia information over a network. IP Multicast is an important advance in IP networking that has been under development since the early 1990's but is only now receiving broad (and growing) practical industry backing through the commercial availability of network infrastructure elements.

[0012] An extension of standard IP, IP Multicast allows applications to send one copy of information to a group address, and have the information transmitted to each recipient of the group requiring receipt of the information. IP Multicast is more efficient than point-to-point unicast because the source need send only once, and more efficient than broadcast since only interested nodes are impacted by transmission of the information. IP Multicast thus scales well as the number of participant and collaborations expand, and it integrates well with other new IP protocols and services, such as Quality of Service requests to support real-time multimedia.

[0013] However, despite the advantages of IP Multicast, its terrestrial implementation may be slow because all routers between the sender and the receivers must be IP Multicast enabled. Even then, network bandwidth may be limited for some considerable time. The demand of consumers for digital satellite TV systems has driven the development of Direct Broadcast Satellite (DBS) systems that can broadcast directly to small, low cost receiver equipment. The standard likely to become dominant on a global basis is Digital Video Broadcast (DVB) which was developed by the European Broadcasting Union.

[0014] DVB specifies standards for the digital broadcast of video, sound and data across satellite (DVB-S), cable (DVB-C) and SMATV (DVB-CS) data link layers. DVB specifies common conformance standards at several levels including channel coding (Reed-Soloman forward error correction), transport layer (MPEG-2 Systems Transport bitstream) and elementary stream layers (MPEG-2 for video encoding and MPEG-1 for audio encoding). An elemental stream is a single, digitally coded component of a multimedia channel (e.g. a single coded video or audio stream). MPEG-2 elemental stream encoding thus provides good VHS quality video at 1.5-2 Megabits and studio production quality video at approximately 6-8 Megabits.

[0015] MPEG-2 transport enables video, audio and data to be multiplexed onto the physical channel of choice, with DVB specifying the remaining system elements for each transport media being used. For example, with satellite communications, DVB specifies the physical channel (single 38 Megabits satellite transponder), signal/noise ratio and channel coding (e.g. 2 bit/symbol QPSK modulation).

[0016] Satellite communications offer sufficient bandwidth for remote multimedia applications. However, satellite connections for the typical computer user are practically non-existent and expensive and do not allow for use of economical open client/server technologies. A client/server architecture is an economical, proven and common form of distributed system wherein software is split between server tasks and client tasks. A client sends requests to a server, according to some protocol, asking for information or action, and the server responds. There may be either one centralized server or several distributed ones. This model allows clients and servers to be placed independently on nodes in a network, possibly on different hardware and operating systems appropriate to their function, e.g. fast server with an inexpensive client.

[0017] There is a rapidly increasing market demand for network based application services that enable the efficient operation of computer applications which are one-to-many in their information flow and which require high network bandwidth. Major advances in digital transmission, encoding and internetworking technology and the advent of direct broadcast satellite have matched this. This market need, combined with the emerging technological capability, has prompted development in accordance with a preferred embodiment. The engineering challenge was to develop a system solution that makes optimum use of emerging digital broadcast technology such as DVB/MPEG while seamlessly integrating into an emerging IP Multicast standard for data technology. With such an emergent service, the architecture of any solution must also be scaleable from an early system for deployment as part of an individual customer solution, through to a multi-customer service platform capable of simultaneously supporting multiple large business customers.

[0018] There are two basic models for delivery of information to end users: (a) information can be requested by the end user of a central source (pull model), or (b) information can be sent from the central source to the end user (push model). Established LAN and WAN technologies, applications and services are very efficient at supporting the pull model of information flow. However, as advanced information technology becomes critical to organizations, there is a rapidly increasing market demand for information technology and network services that efficiently enable push oriented, one-to-many information flow.

[0019] In addition, even when data compression is used, the increasingly multimedia nature of applications requires high bandwidth support of a one-to-many information flow. And even many non-multimedia applications require high bandwidth for the timely transfer of large files of information. The concept of multicasting was originally developed to provide application and inter-network services in response to a demand for high bandwidth one-to-many services. Multicasting utilizes the natural broadcast capabilities of a satellite infrastructure, while smoothly integrating with existing and emerging terrestrial data network services and pull oriented application services.

[0020] A solution to the problems of transmitting multimedia and supporting call processing across the economical Internet while utilizing the high throughput of orbital satellites would integrate the Internet and satellites into a hybrid telecommunications system using client/server technologies.

[0021] The present invention relates to the integration of satellite transmission facilities with the Internet and telephony systems, and more specifically, to a system, method and article of manufacture for using the Internet and satellite transmissions as the communication backbone of a distributed client/server communication system architecture while maintaining a rich array of call processing features.

[0022] According to a broad aspect of a preferred embodiment of the invention, telephone calls, data and other multimedia information are routed through a switched network which includes transfer of information across the Internet and a satellite broadcast facility. A hybrid telecommunications system includes a switched communication network. A packet transmission network is coupled to the switched communications network. A call router is coupled to the switched communications network and the packet transmission network. A gateway server in communication with the call router provides file transfer services to a user connected to the switched communications network including routing over the Internet and satellite broadcasting facilities. The identity of the user is optionally authenticated by an authentication server.

[0023] In a further aspect of a preferred embodiment of the invention, an exterior packet filter is coupled to the call router and the gateway server. The exterior packet filter is configured to accept communications originating from a predetermined set of addresses.

[0024] In still another aspect of the invention, the gateway server is configured to route any messages larger than a certain size to a satellite broadcast facility if the messages are traveling more than 1000 miles.

[0025] In yet another aspect of the invention, a production token ring network is in communication with the gateway server. The production token ring network is optionally coupled to an interior packet filter configured to accept only communications originating from a predetermined set of addresses.

[0026] FIG. 1 illustrates the general topology of a Transmitting Facility and a Receiving Facility communicating via a network in accordance with a preferred embodiment;

[0027] FIG. 2A illustrates the general topology of a Transmitting Facility;

[0028] FIG. 2B illustrates the general topology of a Broadcast Operation Center;

[0029] FIG. 3 illustrates the topology of a Content Provider Facility and a Broadcasting Operation Center including an Input Gateway, an Information Store and Output Gateways;

[0030] FIG. 4 illustrates Output Gateways communicating with an uplink Facility of the Transmitting Facility;

[0031] FIG. 5 illustrates an uplink technical core;

[0032] FIG. 6 illustrates a Receiving Facility;

[0033] FIG. 7 illustrates a layered system architecture;

[0034] FIG. 8 illustrates an application services layer; and

[0035] FIG. 9 illustrates a functional decomposition of architectural layers.

[0036] To assist in clarifying the technical subject matter of this application, a few terms are defined at the outset.

[0037] FIG. 1 illustrates the general topology of a Transmitting Facility and a Receiving Facility communicating via a network in accordance with a preferred embodiment. The flow of data starts at a Content Source 100. The content may be in any one of a number of digital forms, including data files and real-time data streams. Data in every form and format is enabling. The data streams may be audio or video originating from local sources or international sources. The content is transmitted to a Transmitting Facility 110 via any one of a number of methods, including network, Internet, Intranet, or radio broadcast. The data is forwarded to a satellite transmitter 120, received and forwarded to an orbiting satellite 130, received by a satellite receiver 140 and forwarded to a Receiving Facility 150 and transmitted to one or a plurality of destinations 160. In the alternative, the path of transmission between the Transmitting Facility 110 and the Receiving Facility 150 may be via the Internet 170.

[0038] The Transmitting Facility 110 includes a Content Provider Facility and a Broadcast Operation Center. The Receiving Facility 150 includes a Downlink Gateway, Local Program Menu Database and Application Services Facility. The flow of data via the satellite links 120, 130, 140 is unidirectional, from the Transmitting Facility 110 to the Receiving Facility 150. The flow of data via the Internet 170 is unidirectional from the Transmitting Facility 110 to the Receiving Facility 150, however, data indicating the success or lack of success of all content transmissions is forwarded to the Transmitting Facility 110 via the Internet or Public Switched Telephone Network or ISDN at data transmission speeds ranging from 28.8 kilobytes per second to 1.5 megabytes per second.

[0039] FIG. 2A illustrates the general topology of a Transmitting Facility in accordance with a preferred embodiment. A Transmitting Facility includes three major functions. The Content Provider Facility 200, the Broadcast Operation Center 210, and the Uplink Facilities 220. Data is generated at the Content Provider Facility 200, is transmitted to the Broadcast Operation Center 210, and is transmitted to the Uplink Facility 220.

[0040] FIG. 2B illustrates the general topology of a Broadcast Operation Center in accordance with a preferred embodiment. Data enters the Broadcast Operation Center through the Input Gateways 230, which includes a File Gateway, a Schedule Gateway and a Stream Gateway. Data Streams are forwarded to Output Gateways 250, which includes a Repair Server, a Playout Server, and shares the Stream Gateway with the Input Gateway 230. The Stream Gateway is shared by the Input Gateways 230 and the Output Gateways 250 to accommodate the urgent transmission requirements of stream data. Data Files are transmitted to an Information Store 240 and forwarded to the Output Gateways 250.

[0041] FIG. 3 illustrates the topology of a Content Provider Facility and a Broadcasting Operation Center including an Input Gateway, an Information Store and Output Gateways in accordance with a preferred embodiment. Data Streams 300 and Data Files 305 are received from external sources by a Content Provider Gateway 310. Data Streams 300 are assumed to be RTP/UDP unicast or multicast. Authentication and protection mechanisms, such as IPSEC, may be used. Data Files 305 are transmitted via a store-and-forward manner and using conventional file transfer and may be secured through use of IPSEC, SSL, or S-HTTP. The Content Provider Gateway 310 packages the data in packets for transmission to the Broadcast Operation Center. The Content Provider Facility will encrypt all data at the application level.

[0042] Data Streams 300 have a high priority as a function of the urgent or real-time nature of the data, and are transmitted to an Output Gateway 330 in the Broadcast Operation Center to speed passage of the data. Data Files 305 have lower priority than Data Streams 300 and are managed by the Broadcast Operation Center on a scheduled basis. The Content Provider Gateway 310 communicates to the Broadcast Operation Center via a network using TCP/IP protocol. The communication link between the Content Provider Gateway 310 in the Content Provider Facility and a Schedule Gateway 315 in the Broadcast Operation Center is a secure SSL or S-HTTP protocol.

[0043] The Content Provider Gateway 310 and the Schedule Gateway 315 exchange information on the scheduling of transmission of Data Files 305. More specifically, transmission of Data Files 305 is scheduled, revised and queried by the Schedule Gateway 315. The Content Provider Gateway 310 transmits scheduled Data Files 305 to the Schedule Gateway 315 via a network connection using Unicast, and either File Transfer Protocol (FTP) or IPSEC. A File Gateway 320 writes the Data Files 305 to a File Store 325, which is a data storage medium, and forwards the Data Files 305 to the Output Gateways 330 at the direction of a Subscription Manager 335. The Subscription Manager 335 transmits scheduling information to the Output Gateways 330.

[0044] FIG. 4 illustrates the Output Gateways communicating with the Uplink Facility of the Transmitting Facility in accordance with a preferred embodiment. A Content Provider Gateway 400 transmits data streams to a Stream Gateway 410, circumventing the store-and-forward function that data files are subject to.

[0045] The Stream Gateway 410 functions as an FTP Proxy Gateway, which is an IP circuit gateway. A Subscription Manager 420 will transmit to the Stream Gateway 410, a Playout Gateway 430, and a Repair Gateway 440, information that uniquely identifies data that passes through each of the respective gateways, which enables the respective gateways to multiplex authentication and session information such as a unique identifier, the destination uplink, timing, multicast address, checksum, and format information into the data stream. Simultaneous delivery of data streams and data files at the destination can be coordinated by multiplexing authentication and session information in the data streams and data files accordingly.

[0046] The Stream Gateway 410 and the Playout Gateway 430 monitor the timeliness of data to the Uplink Gateways. The Playout Gateway 430 and the Repair Gateway 440 will retrieve data files from a File Store 450 as indicated by the Subscription Manager 420.

[0047] The Output Gateways will transmit data to the Uplink Gateway that is appropriate as indicated by the multiplexed session information, which is either an Internet Multicast Gateway 460, a Fixed Service Satellite (FSS) Uplink Gateway 470, or a Digital Broadcast Satellite (DBS) Uplink Gateway 480. Examples of DBS services are Direct TV and ASkyB. The Uplink Gateways will convert protocols and generate frames as appropriately indicated by the session information and the needs of the respective uplink facilities. Data is transmitted by the Stream Gateway 410 to the Uplink Gateways via RTP.

[0048] FIG. 5 illustrates the uplink technical core in accordance with a preferred embodiment. Data Files are transmitted by the Output Gateways of the Broadcast Operation Center of the Transmitting Facility via a Digital Network Interface 500, Data streams are transmitted via an Analog Network Interface 505, analog data is transmitted via video tape recorder 510, or Data is transmitted via a local content feed 515 into a 270 megabit per second network backbone 520. A record of each transmission is made to a video tape recorder server 525. The data is encoded to MPEG standards using an MPEG encoder 530 and encrypted using an encryptor 535.

[0049] The data is encrypted according to Conditional Access (CA) protocol at CA gate 540 and multiplexed by multiplexer 545 with authentication and session information, such as a unique identifier, the destination uplink, timing, multicast address, checksum, and format information, into the data stream. The multiplexed data is mixed with 4-6 television content 550, audio 555, and data 560. Forward Error Correction (FEC) is added to the data 565. The data 565 is transmitted and modulated according to Quadrature Phase Shift Keying (QPSK) specifications 570, a radio frequency (RF) exciter 575 intervenes in the data transmission, and a RF power amplifier 580 amplifies the data signal.

[0050] FIG. 6 illustrates the Receiving Facility in accordance with a preferred embodiment. The Receiving Facility includes four primary components: a Local Program Menu Database 605, Application Services 610 one or more client computers 615, and a Downlink Gateway 620. Data that is received by the satellite receiver 140, FIG. 1, is transmitted to a Satellite Downlink Gateway 600. The satellite receiver 140 is connected to the Satellite Downlink Gateway 600 via a coaxial cable, which is a type of cable with a solid central conductor surrounded by an insulator that is surrounded by a cylindrical shield woven from fine wires. The shield is usually connected to electrical ground to reduce electrical interference. The Satellite Downlink Gateway 600 removes from the data the satellite protocols and frames that were added to the data by the uplink facilities before satellite transmission, yielding the data multiplexed with the authentication and session information. The Satellite Downlink Gateway 600 includes one or more Receiver Cards 625 that include a tuner, tuner control and satellite decoders.

[0051] The data is transmitted by the Receiver Card(s) 625 to a NDIS 630 and a WINSOCK 635 layers of software or through a MPEG-2 compliant 640 and a MCI compliant 645 layers of software. Then the data is reformed into IP packets for transmission on a local area network, or not reformed, as indicated by the multiplexed destination information in the data 650. The data is transmitted either directly to the client computer 615 using a multicast IP protocol, or indirectly to one or more client computers 615 through the Application Services 610 via a File Capture Service 655 using a file retrieval mechanism where the data is files or a Video Replay Service 660 using a multicast video stream replay mechanism where the data is a stream.

[0052] The Local Program Menu Database 605 controls which data is transmitted at what time based on authentication and session information multiplexed into the data between the Satellite Downlink Gateway 600, the Application Services 610 and one or more client computers 615.

[0053] FIG. 7 illustrates the layered system architecture in accordance with a preferred embodiment. Stream data is managed at the highest level by video storage and retrieval services 700 that is supported by lower level real time transport 710 of the stream data. In comparison, data files are managed by caching and proxy services 720 that is in turn supported by Web Transport 730 Internet Protocols. All data services are supported by IP Multicast Services 740, which are ultimately supported by satellite bitpipes 750.

[0054] FIG. 8 illustrates the application services layer in accordance with a preferred embodiment. In an application of stream data, the Content Provider 800 inserts stream data 810 into the delivery subnetwork 820. In comparison, in an application of file data, the Content Provider 830 inserts file data into the delivery subnetwork 820 where the data may be stored for a period of time and then forwarded through the delivery subnetwork 820.

[0055] FIG. 9 illustrates the functional decomposition of architectural layers in accordance with a preferred embodiment. At an Application level 900 of the system function, a content provider 901 performs content insertion 910 into an Internetwork 911, the data is transmitted through the Internetwork 911 to a destination computer 920. At the Internetwork 911 level, the incoming data is routed by router 930 either to the subnetwork or the Internet 940. Upon passage through either route, it is lastly routed by router 950 to the destination computer 920. At the Subnetwork 951 level, the incoming data is received by a conditional access (CA) device 960, and transmitted to a multiplexer (MUX) 970 in preparation for satellite transmission, then it is transmitted through a satellite 980 to an Integrated Receiver Decoder (IRD) 990, and transmitted to a conditional access (CA) device 995 and then transmitted to the router 950, and lastly to the destination computer 920.

[0056] The source code for a downstream router in accordance with a preferred embodiment is provided below as an aid in teaching one of ordinary skill in the art to make and use the invention.

[0057] version 11.0

[0058] service udp-small-servers

[0059] service tcp-small-servers

[0060] !

[0061] hostname 2509A

[0062] !

[0063] !

[0064] enable password sky

[0065] ip multicast-routing

[0066] ip dvmrp route-limit 7000

[0067] !

[0068] interface Tunnel0

[0069] ip unnumbered Serial0

[0070] tunnel source 166.34.120.225

[0071] tunnel destination 166.35.252.52

[0072] !

[0073] interface Ethernet0

[0074] ip address 166.34.120.33 255.255.255.224

[0075] ip pim dense-mode

[0076] !

[0077] interface Serial0

[0078] ip address 166.34.120.225 255.255.255.224

[0079] ip pim dense-mode

[0080] bandwidth 2000

[0081] no cdp enable

[0082] !

[0083] interface Serial1

[0084] no ip address

[0085] shutdown

[0086] !

[0087] router ospf 200

[0088] redistribute static subnets

[0089] network 166.34.0.0 0.0.255.255 area 0.0.0.0

[0090] !

[0091] ip domain-name rch.mci.com

[0092] ip name-server 166.35.191.120

[0093] ip classless

[0094] ip route 0.0.0.0 0.0.0.0 166.34.120.226

[0095] ip route 166.34.120.128 255.255.255.224 Tunnel0

[0096] ip ospf name-lookup

[0097] ip mroute 166.34.120.128 255.255.255.224 166.34.120.32

[0098] no logging console

[0099] access-list 100 permit icmp any any

[0100] access-list 100 deny ip any host 224.0.0.5

[0101] access-list 100 permit ip host 166.34.120.226 any

[0102] !

[0103] !

[0104] line con 0

[0105] password sky

[0106] line 1 8

[0107] transport input all

[0108] line aux 0

[0109] transport input all

[0110] line vty 0 1

[0111] password sky

[0112] login

[0113] length 18

[0114] line vty24

[0115] password sky

[0116] login

[0117] !

[0118] ntp source Serial0

[0119] end

[0120] The source code for a downstream router in accordance with a preferred embodiment is provided below as an aid in teaching one of ordinary skill in the art to make and use the invention.

[0121] version 11.1

[0122] service udp-small-servers

[0123] service tcp-small-servers

[0124] !

[0125] hostname 2509B

[0126] !

[0127] enable password sky

[0128] !

[0129] ip multicast-routing

[0130] ip dvmrp route-limit 7000

[0131] !

[0132] interface Ethernet0

[0133] ip address 166.34.119.162 255.255.255.240

[0134] ip pim dense-mode

[0135] !

[0136] interface Serial0

[0137] ip address 166.34.120.226 255.255.255.224

[0138] ip pim dense-mode

[0139] bandwidth 2000

[0140] clockrate 2000000

[0141] !

[0142] interface Serial1

[0143] no ip address

[0144] bandwidth 1500

[0145] shutdown

[0146] clockrate 2000000

[0147] !

[0148] router ospf 200

[0149] network 166.34.0.0 0.0.255.255 area 0

[0150] !

[0151] ip domain-name rch.mci.com

[0152] ip name-server 166.35.191.120

[0153] ip classless

[0154] no logging console

[0155] access-list 100 permit icmp any any

[0156] !

[0157] line con 0

[0158] password sky

[0159] line 1 8

[0160] line aux 0

[0161] line vty 0

[0162] password sky

[0163] login

[0164] length 18

[0165] line vty 1 4

[0166] password sky

[0167] login

[0168] !

[0169] ntp clock-period 17180064

[0170] ntp source Ethernet0

[0171] end

[0172] While the invention is described in terms of preferred embodiments in a specific system environment, those skilled in the art will recognize that the invention can be practiced, with modification, in other and different hardware and software environments within the spirit and scope of the appended claims.