[go: up one dir, main page]

WO1997048198A9 - Procede et systeme de protocole de radiodiffusion en recouvrement - Google Patents

Procede et systeme de protocole de radiodiffusion en recouvrement

Info

Publication number
WO1997048198A9
WO1997048198A9 PCT/US1997/010425 US9710425W WO9748198A9 WO 1997048198 A9 WO1997048198 A9 WO 1997048198A9 US 9710425 W US9710425 W US 9710425W WO 9748198 A9 WO9748198 A9 WO 9748198A9
Authority
WO
WIPO (PCT)
Prior art keywords
stream
primary data
data
data stream
broadcast
Prior art date
Application number
PCT/US1997/010425
Other languages
English (en)
Other versions
WO1997048198A3 (fr
WO1997048198A2 (fr
Filing date
Publication date
Application filed filed Critical
Priority to AU39575/97A priority Critical patent/AU3957597A/en
Publication of WO1997048198A2 publication Critical patent/WO1997048198A2/fr
Publication of WO1997048198A9 publication Critical patent/WO1997048198A9/fr
Publication of WO1997048198A3 publication Critical patent/WO1997048198A3/fr

Links

Definitions

  • This invention relates to transmission of data over preexisting data channels and is especially applicable to apparatus and systems which transmit and receive broadcast data in unused spaces of these channels.
  • Such systems can be of point-to-point in nature (such as that found in Internet infrastructure) or any other network topology.
  • Networks deliver data through channels that are implemented with a wide variety of media and technologies.
  • Networks can take on many forms but will always be comprised of at least three essential components: a transmitter, a medium, and a receiver.
  • these networks are designed to use the available data-carrying capacity (also known as "bandwidth") in an efficient manner.
  • bandwidth also known as "bandwidth”
  • Installed networks are often designed with excess carrying capability.
  • Other networks may not have excess carrying capacity but remain inefficient due to usage patterns or transmission technologies.
  • Much of the information sent through such a system is demand- driven, i.e., it is pulled through the network. It is largely the lack of pushed data that prevents one from using periods of inactivity. Ideally, one would send pulled data when it is available and transmit pushed data when no pulled data is ready.
  • the problem with such an approach is that, currently, there is little demand for transmitting pushed data. This is primarily due to the fact that most users are only interested in data which they have requested directly, while pushed-data is typically not generated for a specific user or in response to a real-time query. In fact, the most efficient use of pushed-data would be to send broadcast data to many users.
  • broadcast data can be sent no more efficiently than individual point-to-point data.
  • Broadcast data on these networks are simply sent much like any other data except it is sent repeatedly to multiple users.
  • True broadcast typically can only occur on "bus-topology” networks, i.e., networks in which a signal placed on the network is available to all receivers. This is the case for networks that utilize such technologies as Ethernet and wireless, for instance.
  • ISDN both of which are virtual-circuit based technologies, i.e., a dedicated "virtual circuit" is established between the two ends of the channel.
  • a circuit can actually correspond very closely to a real physical circuit since both POTS and ISDN have a separate twisted-pair between each customer and the central office switch.
  • true broadcast is not built into the system.
  • ISPs that provide service through cable-modems, for instance, will be able to provide broadcast data for very little additional cost.
  • the problems of bandwidth under-utilization and low-cost broadcast ability on traditional POTS/ISDN infrastructure are of particular relevance to the present invention. These problems are interrelated in as much as low-cost broadcast ability could be used to better utilize total available bandwidth.
  • the present invention seeks to solve both problems, as well as to provide a complete system in which newly- available broadcast capacity becomes an attractive supplement to the pull-only data currently available. This last feature is important because, though the current trend in networks will increase the availability of bus- topology networks, the attendant broadcast ability will go under-utilized unless a system is created to make broadcast data more usable and attractive.
  • broadcast data is made feasible over traditional circuit-based networks as well as over non-bus topology networks through the introduction of a novel data format and protocol.
  • This protocol is referred to herein as a "broadcast overlay" because it enables a secondary broadcast stream to be "overlaid” or embedded within a primary data stream.
  • the format and protocol thus enables the insertion of broadcast data in periods of inactivity with little or no negative impact on the delivery of primary point-to-point data.
  • an existing underlying transmission protocol such as (SL)IP, PPP or HDLC
  • Yet another object of this invention is to overlay data packets conforming to a overlay protocol on top of pre-existing protocol streams, but preferably only during at least some periods of underlying protocol inactivity
  • the invention thus realizes the benefits of a broadcast medium, namely maximizing data distribution at minimum per-user costs
  • the invention provides a transmission method wherein a broadcast stream is superimposed over a set of one or more primary data streams by embedding delay-insensitive data packets of the broadcast stream during periods of inactivity in each primary data stream
  • the delay-insensitive data packets comprising the broadcast stream may be transmitted out-of-sequence relative to each other and out-of-band relative to the primary data stream.
  • At least some of the delay-insensitive data packets are assigned acceptable error-tolerance levels, and a given delay-insensitive data packet has an optimum size and frequency of retransmission determined by a statistical decomposition of a data-time behavior of the primary data stream.
  • the method has particular applicability in providing broadcast content (e.g., advertising streams) to World Wide Web clients connected to an Internet service provider.
  • broadcast content e.g., advertising streams
  • ISP Internet service provider
  • the method begins by transmitting a primary data stream from the data center to the user, the primary data stream comprising a plurality of data packets conforming to a first given protocol and characterized as having periods of inactivity.
  • the given protocol may be, among others, PPP, SLIP and/or HDLC.
  • the method embeds into the primary stream a secondary "broadcast" stream comprising a plurality of delay- insensitive data packets conforming to a second given protocol - the overlay protocol of this invention.
  • the secondary stream is embedded into the primary data stream without substantially affecting latency of data packets comprising the primary data stream.
  • the secondary stream is then reconstituted at the user's client machine.
  • the secondary “broadcast” stream is embedded into the primary stream by embedding the delay-insensitive broadcast data packets during the periods of inactivity in the primary data stream.
  • the delay-insensitive data packets comprising the secondary stream may be transmitted in the primary stream out of sequence or particular data packets may be transmitted multiple times within the primary stream.
  • the secondary broadcast stream embedded in the inactivity periods of the primary data stream is "interrupted” as necessary so that the primary data stream itself is not delayed. This may be achieved by defining the overlay protocol so as to exclude a given flag sequence of the primary data stream. In this way, the embedding of the secondary stream is interrupted upon occurrence of the given flag sequence. Where the primary data stream is . transmitted via a protocol that does not include flag sequences, interruption of the broadcast stream (without impacting the latency of the primary data stream) may be achieved by defining a start sequence in the overlay protocol that is restricted from occurring in a header of the primary stream.
  • the primary data stream includes information retrieved from a web site connected to the Internet service provider and the secondary broadcast stream includes a stream of content (e.g., product/service advertisements) that is then displayed on a display interface of the client machine.
  • content e.g., product/service advertisements
  • the invention also describes a transmission system located at a service provider for transmitting data over a set of one or more connections to a set of one or more clients, respectively, the service provider connected to a plurality of servers.
  • the transmission system comprises first means responsive to a request from a client for communicating with one of the servers and receiving information to be transmitted to the client.
  • a second means responsive to the first means is provided for transmitting the information to the client in a primary data stream, the primary data stream comprising a plurality of data packets conforming to a given protocol and characterized as having periods of inactivity.
  • the system further includes a third means responsive to the second means for embedding into the primary data stream a secondary broadcast stream as the primary data stream is transmitted to the client.
  • the secondary stream comprises a plurality of delay-insensitive or "interruptible" data packets conforming to an "overlay" protocol.
  • the secondary broadcast stream is embedded into the primary stream without substantially affecting latency of the delay-sensitive data packets comprising the primary stream.
  • the transmission system is an ISP delivery system, in which case the request is an HTTP request, the server is a web site and the information is a web page.
  • the secondary broadcast stream includes a plurality of advertisements.
  • Figure 1 is a block schematic diagram of a section of a transmission network in which the present invention is implemented
  • FIG. 2 is a diagram illustrating a representative packet format of the overlay protocol (OP) of the present invention
  • Figure 3 is a diagram illustrating a known HDLC packet format
  • Figure 4 is a diagram illustrating a sample HDLC packet stream
  • Figure 5 is a diagram illustrating a sample OP packet stream according to the present invention.
  • Figure 6 is a diagram illustrating a sample broadcast overlay protocol stream which is created by overlaying the OP packet stream of Figure 5 onto the HDLC packet stream of Figure 4;
  • Figure 7 illustrates a simplified technique for generating the broadcast overlay protocol stream of Figure 6
  • Figure 8 illustrates a simplified technique for embedding a secondary broadcast stream into multiple user data streams
  • Figure 9 illustrates an implementation of the broadcast overlay protocol in an Internet service provider (ISP) delivery system to utilize the downtime in a typical Internet browsing session to download broadcast content
  • Figure 10 depicts a Web browser of a client machine displaying broadcast data supplied to the client machine using the inventive protocol;
  • ISP Internet service provider
  • Figure 11 is a simplified block diagram of band extractor which is used according to the present invention to determine the frequency of re-transmission of a given broadcast data packet through a statistical decomposition of a data-time behavior of the primary data stream;
  • FIG 12 is a block diagram representing various functional "layers" of a client-side system supported at a user's machine.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Figure 1 illustrates a representative system architecture in which the present invention is implemented.
  • the system comprises three (3) major classes of entities: a "user” 10, a "data-center” 12 and a "broadcast-client” (or server) 14.
  • a user 10 may be a client machine (e.g., a personal computer) connected to a computer network in a known manner.
  • the network may be any known computer network such as the Internet, an intranet, a wide area network (WAN) or local area network (LAN). In the illustrative embodiment, the network is the Internet.
  • WAN wide area network
  • LAN local area network
  • a “data-center” 12 is the set of machines and related equipment whose responsibility is to supply a set of "users" with access to the network, such as the Internet, as depicted in Figure 1 , and broadcast data.
  • a representative data center 12 is an Internet Service Provider (ISP).
  • the data-center 12 typically provides services to "broadcast clients” 14 which allows it to submit and control broadcast data as well as to submit "remote jobs" and collect information from users.
  • a machine that is used as a broadcast client 14 may also be a user and vice-versa.
  • Figure 1 shows these components as separate entities for the sake of simplicity.
  • a broadcast client may support a server 17 supporting HTML documents, sometimes referred to herein as a web site.
  • the data-center 12 comprises several major components: the broadcast server 16, a response server 18, a mux/demux 20, and the Internet gateway 22.
  • the Internet gateway 22 allows users to send and receive IP packets to and from the Internet 24, and this component performs ancillary functions such as routing and IP address assignment. This is the primary service provided by ISP (Internet Service Provider) data-centers.
  • the client machine is any personal computer or workstation, such an Intel x86-based processor running an operating system (such as Microsoft Windows '95/NT), and supporting a conventional Web browser (such as Netscape Navigator 3.0 or higher or Microsoft Explorer 3.0 or higher).
  • the Web browser provides a graphical user interface for supporting the retrieval and display of Web documents via the Internet's World Wide Web multimedia information retrieval system.
  • the data-center 12 supplies SLIP/PPP-like service to the user in a conventional manner.
  • the data center also allows a broadcast data stream to be sent and user- responses to be received, both out-of-band relative to the data in the IP or any of the PPP protocols.
  • Such data can be sent out-of-band and still remain compatible with protocols like PPP, HDLC and SLIP, by carefully avoiding the use of the so-called "flag codes" associated with the start and end of packets in these protocols, as will be seen.
  • This out-of-band information is encoded with a novel protocol introduced in this invention.
  • This protocol called Overlay Protocol (or OP)
  • OP Overlay Protocol
  • This protocol differs from other protocols as it is designed to be highly error- tolerant and useful even when OP packet integrity cannot be guaranteed.
  • This protocol is not designed to be a standalone protocol, but rather is to be used with other preexisting protocols, such as (SL)IP, PPP, or HDLC, without having to modify these protocols.
  • the OP protocol is designed so that its own packets can be interrupted by the underlying protocol with the minimum amount of latency to insure that underlying protocol transmission performance is not impacted.
  • OP packets are overlaid on top of preexisting protocol streams and are only transmitted during periods of underlying protocol inactivity.
  • Figure 2 shows the packet format defined by the OP protocol. It contains a FLAG field 30, an OBJECT* field 32, a PACKET# field 34, a TYPE field 36, the DATA field 38, an FCS field 40, an ERRTOL field 42, an LEN field 44 and a FLAG field 46.
  • the FLAG fields 30 and 46 define the start and end of the given packet.
  • the OBJECT# and PACKET# fields provide object and packet definitions.
  • the TYPE field is a special field that facilitates defining the error tolerance level of the data packet.
  • the OP data packets may have a defined error tolerance, which is specified by the ERRTOL field.
  • the error tolerance level is the variable length field ERRTOL whose length (defined by the LEN field) depends on the OP TYPE field 36.
  • the error tolerance levels are preferably encoded so that only certain values are valid, for example, the value 10,000 is associated with an error tolerance of 1%, the value 20,000 is associated with an error tolerance of 2%, and so on. This is done so that the error tolerance level can be extracted with a high degree of confidence for its data integrity.
  • ERRTOL is typically set to zero.
  • ERRTOL can be set to the user-defined tolerance levels.
  • Figure 3 shows the format of a conventional HDLC packet. This is included as an example of an underlying protocol on which the OP packets are overlaid according to this invention.
  • the OP packets do not replace or preempt any of the underlying protocol's data. Instead, such packets are only transmitted during periods of inactivity in a way that minimally impacts the preexisting data stream.
  • the following example illustrates this concept:
  • Figure 4 represents a typical HDLC packet stream. Notice that this stream contains periods of inactivity 50 during which no information is being transmitted.
  • Figure 5 represents a typical OP packet stream according to the present invention. It is preferred (although not required) that the OP stream is continuously broadcasting information, i.e., there are no periods of inactivity.
  • the packets are not necessarily in order and that particular packets may be transmitted multiple times. Thus, for example, packet OP3 is transmitted both before and after the first transmission of packet OP4, which itself is transmitted twice. The packet OP3 is also transmitted a third time, between the second transmission of packet OP4 and the first transmission of packet OP5.
  • this illustration is merely representative.
  • the sample OP packet stream of Figure 5 is overlaid on the underlying protocol stream of Figure 4.
  • the resulting broadcast overlay protocol stream (which is a single stream) is illustrated in Figure 6.
  • the stream in Figure 6 is thus created by superimposing (or “overlaying") the OP packet stream on top of the HDLC packet stream during (at least some) periods of HDLC inactivity.
  • the inventive transmission method does not delay or hold-off HDLC packet transmission to allow an OP packet to be transmitted in its entirety.
  • the OP packet stream is interruptible by the underlying packet stream.
  • Figure 7 illustrates a convenient mechanism for embedding the OP packet stream (sometimes referred to as a secondary or “broadcast” stream) into the underlying packet stream (sometimes referred to as the primary or “user” data stream since this is the stream that includes the data requested by the user).
  • a Virtual OR operator 52 takes the primary data stream 54 as one input and the single broadcast data stream 56 as a second input and generates an output data stream 58 with the embedded broadcast information.
  • the broadcast information may comprise any type of content including, without limitation, graphics, text, animation, video, sounds, programs and combinations of the above, as well as appropriate formatting information for controlling a Web browser (or other GUI) to display or otherwise output the broadcast information.
  • One convenient implementation is a display of scrollable animated or static advertisements and/or videos in a dedicated content window or enlarged scrollbar area of a Web browser display interface.
  • the "Virtual OR" operator is an extremely simple
  • VOR is the Virtual-OR operator
  • BDS(t) is the broadcast data stream at time "t”
  • UDS(t) is the user data stream at time "t”.
  • this operator is “stateless” and does not require storage (memory) to be implemented. Because the VOR operator can be implemented economically, this technique scales very easily and inexpensively. Thus, an ISP for example may increase the audience of the broadcast stream for little or no additional incremental cost.
  • Figure 8 illustrates the simple scalability of this system wherein multiple user streams 60 (at least some of which are different) receive the same broadcast stream 62 through the use of a plurality of VOR operators 64. This technique is advantageous in an ISP delivery system implemented at the data center.
  • each of the user data streams corresponds to an individual user of a Web browser at a client machine.
  • Each such user is making requests to Web servers over the WWW using an underlying protocol transmission.
  • the "inactivity" periods of these underlying protocol transmissions are then exploited according to the present invention by embedding the same broadcast stream content into those underlying transmissions.
  • the communications protocol of the present invention provides significant benefits.
  • One particular use is an Internet application to exploit the "downtime" in a typical Internet browsing session.
  • the present invention enables an ISP to broadcast "push" content to its customers (i.e., clients) without interrupting the normal flow of Internet communication.
  • content for distribution is loaded onto and administered from a broadcast server (see Figure 1) at the ISP site.
  • Software running at the data- center identifies the downtime in communication between the ISP and the user.
  • the broadcast data is then sent to the user using the inventive overlay protocol.
  • the protocol works in conjunction with the IP protocol without interrupting the IP transmissions.
  • the ISP broadcast data is then rendered at the user's computer, e.g., in a unique content window as illustrated in Figure 10.
  • the software at the data- center may collect individual usage information and then analyze this information to optimally target advertisements for the user.
  • a large amount of the simplicity found in this data overlaying system is due to the fact that the overlaid OP packets may be interrupted at any time. To actually implement this feature, it is necessary to detect when an OP packet has been interrupted. One way to do this would be to mark the interruption of an OP packet with a sequence that identifies the end of OP and the start of underlying protocol transmission. Assuming this sequence was one byte long (the shortest practical sequence), one would have to delay and buffer the transmission of the underlying protocol for the length of this one-byte sequence.
  • This buffering introduces some additional latency and resource requirements that are not always desirable.
  • Other, more preferred techniques may be implemented to interrupt the OP packet stream.
  • One preferred approach is to define the OP protocol in such a way as to eliminate all occurrences of the flag-sequence of the underlying protocol in the OP data stream. In this way, the interruption of OP protocol data transmission is recognized upon the reception of the underlying protocol's flag-sequence.
  • Certain protocols do not dictate the packet be bracketed by flag sequences but instead merely prefixed with the sequence.
  • HDLC allows the trailing flag-sequence to be omitted when it is followed immediately by another HDLC packet. This presents a potential problem in that, with such protocols, it is not easy (and sometimes quite difficult) to distinguish between OP data and a packet that has not been preceded by a closing flag-sequence.
  • the present invention solves this latter problem.
  • the protocol upon the resumption of OP transmission in systems that overlay on top of protocols that do not require bracketed packets, the protocol requires that an OP start sequence be embedded immediately after the end of underlying protocol's frame. This OP start sequence must then be such that it cannot occur legally in the header of the underlying protocol's frame. The requirement to transmit this start sequence does not require the system to buffer the OP packet, nor does it introduce any latency in the transmission of underlying protocol. The reason for this is that there is still no requirement to delay the transmission of the OP packet since the protocol permits sending of partial frames. In other words, since there is freedom to start and stop the OP transmission anywhere it is most convenient, transmission may start without penalty after the start- sequence has been sent.
  • the 'aa' sequence in this case is variable and is actually the value of the OP data stream that bb replaces.
  • the second byte of the OP start-sequence holds the actual flag value and the first byte holds the value that the second byte replaces.
  • This technique is convenient because HDLC allows any value to occur in the address field of its frame. While the control field (the next field) only allows the value 0x03, the reception of the escape sequence 0x7D is not legal within the context of the HDLC's control field.
  • the OP protocol dictates that what follows be interpreted (preferably) as underlying protocol data.
  • the reception of the underlying protocol's flag-sequence can occur at anytime including during the OP start-sequence. It should be appreciated that the novel format of the OP protocol thus allows it to adapt to nearly any underlying protocol. However, the flexibility of the protocol is not just limited to its adaptability to other protocols.
  • OP does not impose a minimum or maximum receive unit (MRU), nor does it impose a sequence in which packets must be ordered.
  • MRU minimum or maximum receive unit
  • This novel feature allows the present invention to transmit the broadcast data in whichever way it is most appropriate. This adds tremendously to the value and utility of the invention by allowing the transmission behavior to be tailored specifically to the transmitted data and channel(s). This adaptability of transmission to the data and channel conditions greatly increases the effective throughput of a broadcast stream by tailoring transmission parameters to best match conditions and thus increasing the likelihood of successful reception of packets.
  • the present invention takes two approaches to the problem of interference (due either to noise or underlying protocol activity). This feature of the present invention is now described. The first is to define the error-tolerance level of OP data packets; the second is to perform what is referred to as adaptive-directed, statistical-decomposition (ADSD) of the channel.
  • ADSD adaptive-directed, statistical-decomposition
  • the error-tolerance level of a packet can be set so that even in cases of errors in the packet, the given packet may still be used.
  • the error tolerance level is the variable length field whose length depends on the OP TYPE field.
  • the error-tolerance level is specifically encoded into the OP ERRTOL field so that only certain out of a great many values are valid. This is done so that the error tolerance level can be extracted with a high-level of confidence. If this were not done, it would be possible that an error itself was responsible for changing the error tolerance level of a packet.
  • only certain types of packets can legally have a non-zero error tolerance. For example a packet containing an executable is not permitted to have an encoded non-zero ERRTOL value.
  • the error tolerance of the packet can be defined to be non-zero for a variety of reasons.
  • the data contained in the packet may be encoded in a way that allows errors to be detected and corrected. Alternatively, the data can be deemed to be error tolerant. This is especially useful in the case of progressive transmission of media in which errors in the higher-frequency components can be tolerated. It is even possible to low-pass filter packets in which errors have been detected in order to minimize the effects of noise in the data. This approach could be applied to both low-frequency and high-frequency components of transmitted media.
  • Adaptive-directed, statistical-decomposition is another approach that is implemented in this invention (in addition to defining individual packet error tolerance) to deal with interference.
  • This function is performed by a band extractor (preferably implemented in software) that is illustrated in Figure 11.
  • the band extractor includes a number of functional components, a DT-space data collector 70, an autocorrelation function 72, an exponential weighted averager 74 and a DF band selector 76.
  • the band extractor facilitates a statistical decomposition of a "data-time" behavior of the primary data stream which is then used to determine the frequency of re-transmission of given data packets constituting the broadcast data stream. This operation will now be described.
  • ADSD analyzes interference (whatever its source) as a complex periodic signal that can be decomposed into a collection of statistically- relevant components. For instance, in the example above, the line noise created by the clock-slip between the two switches would be analyzed by the ADSD module of this invention and decomposed into statistically- significant noise components (in this example, there is only one statistically significant noise component at 0.5Hz).
  • Time-domain behavior of the interference is not as important as data-time-domain behavior or DT-space (or Data-Time space).
  • the DT-space data collector 70 is used to sample the real signal in the time-units of the protocol of interest. This is a relatively straightforward process for low-level protocols such as RS-232, where the projection into DT-space is mostly a matter of scaling the time-axis by the transmission rate. For higher-level protocols which contain complex frames, the projection into DT-space can be approximated by the collector 70 by scaling the time-axis by the frame- size.
  • an autocorrelation may be performed of the DT-space signal by the autocorrelation function 72 to estimate what is happening in the DF-space.
  • the result of the autocorrelation can be taken and passed through the exponential weighting averaging function 74. Peaks represent recent significant periodicity in the interruption of the data signal, wherein dips represent few interruptions at the given periodicity.
  • the broadcast data is sent during this time since it represents the periodicity at which there is the least chance of being interrupted.
  • the optimum size and frequency of re-transmission of broadcast data packets is preferably determined by the statistical decomposition of the data-time behavior of the primary data stream into which the broadcast data packets are to be embedded.
  • the information culled from the band extractor shown in Figure 11 is collected by the broadcast data stream transmitter, which then uses this data to determine how to break up the broadcast packets (which thus determines their optimum size) and how often to re-transmit them
  • An implementation of this function is now described It begins by collecting a "successful" packet transmission rate as a function S(f,l,r,T) of data sampling frequency "f , package length "I", number of retries "r” and total sampling period "T” This step is performed by the collector 70
  • a spectrum estimation is then done from the S(f,l,r,T) data set using the autocorrelation function 72 (or some other suitable algorithm that may suit the operating environment)
  • the routine then extracts the optimal successful packet transmission rate for the given transmission media
  • the optimal successful transmission
  • the band extractor works optimally on a single data channel, so for every data channel to the user a separate band extractor task must be running This could result in a large amount of computation done at the data-center if this information were to be gathered at the broadcast site
  • the band extractor is located at the user site (as embedded software) to significantly reduce the amount of computational power needed at the data-center
  • the computational power needed for the band extractor is minimized by using the autocorrelation function instead of a more expensive Fourier-transform (which might be used as well if desired)
  • the band extractor further minimizes the amount of computation by collecting the result of the autocorrelation function block and placing it into bins of decreasing size along the time (lag) axis
  • the exponential averaging is done with the aid of look-up tables and the band selector is based on a simple heuristics and histogram mechanism supported in the DF band selector 76.
  • the invention envisions that the user (i.e., the client machine) indicates which packets it has successfully received so that the data-center may, through a simple histogram mechanism, determine the relative priorities of the packets.
  • the combination of these two mechanisms ensures that there is enough information present to make an intelligent decision on which packets should be given higher priority and how often they should be transmitted.
  • the data-center is also able to direct each of the band extractors running at the user sites to divide up the entire data frequency space into specific bands. This is used to minimize the amount of data that is received by the data-center since the band extractors only extract information that the data-center has requested.
  • ADSD directed- adaptive
  • the client machine includes a processor, an operating system, a Web browser for displaying content comprising the broadcast stream.
  • the system comprises multiple layers, each of which provides novel and useful features which facilitate the providing of an integrated data broadcast environment.
  • the lowest layer 80 defines the hardware interaction between communication devices in a way that facilitates multiplexed (i.e., broadcast) communications.
  • This layer can be implemented with a combination of hardware, firmware and software solutions ranging from simple analog electronics devices, reprogramming telecommunications switches, high level protocols or any combination thereof.
  • the next layer 82 supports the underlying communication devices different modes of operation (e.g., quiescent, interactive, broadcast, etc.), and enables the upper layers to recognize and set these modes.
  • the next layer 84 on reception, separates the new data stream from the standard (i.e., the currently transmitted) information as well as overlays new data, on transmission, in a way to minimize (eliminate) latency to the preexisting data streams and impact on transmission performance of this stream. This operation has been described in detail above.
  • Layer 84 comprising a filter 85 which processes the overlay protocol and data format. The filter monitors the incoming data stream and separates raw broadcast information from the other packet information. This raw data is processed and buffered in such a way that recovery of useful broadcast information can be made from partial broadcast packets by higher-level software.
  • next layer 86 processes raw packets to make them easily usable by higher layers, as well as to expose hooks (application programming interfaces or "APIs") that enable implementation of protocol features such as security and progressive transmission.
  • the next layer 88 authenticates and provides access to data services (which may be optionally) supplied by this system. This layer also exposes hooks that enable the creation of "virtual" IP communications.
  • the next layer 90 (also optional) provides higher level functionality to facilitate applet implementation by providing APIs for scheduling tasks for events and idle time.
  • the next layer 92 supplies APIs and libraries for higher level applications to insure they are "safe” as well as well-behaved (e.g., easily uninstallable).
  • the highest level 94 supplies APIs to control and enumerate broadcast streams and high- level functions associated with systems management (e.g., power- management, alarms and task scheduling).
  • the present invention provides a novel protocol and transmission method.
  • a secondary "broadcast" stream is overlaid on a set of one or more underlying packet stream(s).
  • the technique does not delay or hold-off underlying packet transmission to allow an OP packet to be transmitted in its entirety.
  • the third benefit may not be immediately apparent in the two- stream example given above, but it becomes apparent when examining the multi-stream case.
  • the holding-off and delaying of the HDLC packets e.g., in order to embed a secondary stream according to this invention, either imposes severe performance penalties on HDLC packet transmission or requires a high-level of per-user resources.
  • the reason for this is that, in order to insure that every OP packet is received by each of the users (the primary reason for delaying HDLC packets), upper level protocols would be required to stop the production of HDLC packets; alternatively, an indefinite number of HDLC packets and OP packets would have to be buffered.
  • the present invention simply allows a single OP packet stream to be generated and superimposed on an arbitrarily large set of preexisting data streams.
  • OPCP OP Control Protocol
  • the technique of this invention allows for full broadcast-mode transmission, even though the underlying physical medium may not be traditionally thought of as a broadcast medium.
  • This invention allows for a single broadcast data stream to be generated and, with minimal additional resource and cost-per-user, this stream is then sent to a large number of users.
  • the technique realizes all of the benefits of a broadcast medium -- to maximize data distribution and minimize peruser costs.
  • the low per-user costs results from the absence of a complex buffering system, the absence of large amounts of memory for buffering user data, and a truly single broadcast stream system.
  • the invention also enhances the usability and value of aforementioned broadcast data by enabling application security, progressive-transmission, robust media, error tolerance, intelligent caching and site-emulation.
  • Such features can be used independently of the data protocol/format and related features mentioned above. These features stand by themselves as broadcast data may be made available independent of the first part of this invention.
  • the preferred embodiment of this invention includes the first feature when used with a non-bus network, and also contains the other features that enhance the usability of broadcast data regardless of its origin.
  • the present invention includes a security module, but in addition to this module, this invention inherently offers a higher level security than is currently afforded over a similar network which provides only point-to- point services. The reason for this is due to the topology of embodiments of this invention which reduces the number of possible security "points-of-failure" between the user and secure objects.
  • the invention reduces these security loci preferably by moving the secure objects from a client site to the site of the data-center itself.
  • Making these security objects "pushed-data" (i.e., broadcast) combined with the technology introduced by this invention makes it preferable to move said objects from the client (where they have been traditionally stored) to the data-center. This is dictated by security issues as well as the reduction of cost to the client associated with offloading this work to the data-center, as well as the low cost to the data-center using the present invention.
  • this invention In addition to offloading data transmission responsibilities from the client site, this invention also enables the client to offload computation to the user's machine or data-center machine.
  • the user's machine is the preferred location to offload computation, however, as one of the primary benefits of the present invention is to minimize the amount of computation needed to support broadcast mode transmission.
  • One of the preferred implementations of the invention is a computer program product in a computer-readable media, for example, a software application (a set of instructions or program code) in one or more code modules which may, for example, be resident in the random access memory of a computer.
  • the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network.
  • the present invention may be implemented as a computer program product for use in a computer.

Abstract

Cette invention concerne un procédé de transmission dans lequel un train de données radiodiffusé est superposé sur un ensemble constitué d'un ou plusieurs trains de données primaires, en utilisant les périodes d'inactivité dans chaque train de données primaires pour y intégrer des paquets de données insensibles au retard provenant du train de données radiodiffusé. Ces paquets de données insensibles au retard provenant du train de données radiodiffusé peuvent être transmis hors-séquence les uns par rapport aux autres ou hors bande par rapport au train de données primaires. Des niveaux de tolérance d'erreur acceptables sont conférés à au minimum un certain nombre de paquets de données insensibles au retard, et un format optimal et une fréquence de retransmission sont attribuées à un paquet de données insensible au retard déterminé, le format et la fréquence étant établis par décomposition statistique d'une relation données-temps du train de données primaires. Le procédé est particulièrement adapté pour fournir un contenu radiodiffusé (par exemple, trains de données publicitaires) à des clients du 'World Wide Web' raccordés à un fournisseur d'accès Internet.
PCT/US1997/010425 1996-06-13 1997-06-13 Procede et systeme de protocole de radiodiffusion en recouvrement WO1997048198A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU39575/97A AU3957597A (en) 1996-06-13 1997-06-13 Broadcast overlay protocol method and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US1968096P 1996-06-13 1996-06-13
US60/019,680 1996-06-13

Publications (3)

Publication Number Publication Date
WO1997048198A2 WO1997048198A2 (fr) 1997-12-18
WO1997048198A9 true WO1997048198A9 (fr) 1998-03-12
WO1997048198A3 WO1997048198A3 (fr) 1998-05-14

Family

ID=21794489

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/010425 WO1997048198A2 (fr) 1996-06-13 1997-06-13 Procede et systeme de protocole de radiodiffusion en recouvrement

Country Status (2)

Country Link
AU (1) AU3957597A (fr)
WO (1) WO1997048198A2 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6442598B1 (en) * 1997-10-27 2002-08-27 Microsoft Corporation System and method for delivering web content over a broadcast medium
ATE475169T1 (de) 1997-11-12 2010-08-15 Palus A1 Llc Automatischer übergang einer benutzerschnittstelle von einem programm zu einem anderen programm während dass erste noch verarbeitet
WO2000052608A1 (fr) * 1999-03-04 2000-09-08 Tel.Net Media Pty. Ltd. Systeme et appareil publicitaires dynamiques
DE19939366B4 (de) * 1999-08-19 2006-08-31 Siemens Ag Netzseitige Einrichtung und Verfahren zur Übertragung von Daten in einem Funk-Kommunikationssystem
US7826408B1 (en) 2005-03-14 2010-11-02 Ozmo, Inc. Apparatus and method for integrating short-range wireless personal area networks for a wireless local area network infrastructure
WO2006099588A2 (fr) * 2005-03-14 2006-09-21 H-Stream Wireless Procede et appareil pour le fonctionnement d'un reseau personnel utilisant un protocole de recouvrement qui ameliore la coexistence avec un reseau local sans fil
US8891497B1 (en) 2006-03-14 2014-11-18 Atmel Corporation Method and apparatus for coordinating a wireless PAN network and a wireless LAN network

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04262630A (ja) * 1991-02-15 1992-09-18 Fujitsu Ltd 衛星通信方式
ES2113362T3 (es) * 1991-12-24 1998-05-01 Alsthom Cge Alcatel Metodo de transmision de datos en el que se usa una pluralidad de leyes de codificacion para transmision de una corriente de bits principal y otra auxiliar.
US5550803A (en) * 1995-03-17 1996-08-27 Advanced Micro Devices, Inc. Method and system for increasing network information carried in a data packet via packet tagging

Similar Documents

Publication Publication Date Title
CN101027862B (zh) 对通信流量分级的多信道通信
US6195680B1 (en) Client-based dynamic switching of streaming servers for fault-tolerance and load balancing
US7328266B2 (en) Internet provider subscriber communications system
US7013322B2 (en) System and method for rewriting a media resource request and/or response between origin server and client
EP1238512B1 (fr) Systeme et procede de transmission de donnees vocales sur des protocoles de reseaux
EP1247193B1 (fr) Canalisation multidiffusion de donnees
US8649395B2 (en) Protocol stack using shared memory
US20040243715A1 (en) Content delivery server and terminal apparatus
US20020040404A1 (en) System and method for performing broadcast-enabled disk drive replication in a distributed data delivery network
US20020049861A1 (en) Cable modem system and method for supporting packet PDU compression
US20020046405A1 (en) System and method for determining optimal server in a distributed network for serving content streams
US20040008717A1 (en) Fault tolerant correlation engine method and system for telecommunications networks
NZ316616A (en) System and method for distributing multi-media presentations in a computer network
TW200520473A (en) Method, system and article for dynamic real-time stream aggregation in a network
Ehley et al. Evaluation of multimedia synchronization techniques
WO2003038638A1 (fr) Systeme et procede d'arbitrage pour une distribution de contenu locale et nationale
CA2411991A1 (fr) Transmission de signaux video numeriques sur un reseau ip
WO2000048366A1 (fr) Protection de largeur de bande pour l'emission de voix-donnees sur un systeme ip
CN1204212A (zh) 用置顶盒提供个人计算机通信和因特网业务的设备和方法
US20020188745A1 (en) Stacked stream for providing content to multiple types of client devices
AU2001238298A1 (en) System and method for combining requests for data bandwidth by a data provider for transmission of data over an asynchronous communication medium
CN101854286A (zh) 基于用户数据报协议的数据流发送、接收方法及装置
EP1346571B1 (fr) Synchronisation du transfert de donnees en masse vers des dispositifs nodaux terminaux dans un reseau multimedia
WO1997009827A1 (fr) Systeme de distribution
WO1997048198A9 (fr) Procede et systeme de protocole de radiodiffusion en recouvrement