Frame protocol and scheduling system

Frame Protocol and Scheduling System

Technical field

The present invention mainly relates to broadcasting systems. More specifically, the present invention relates to a system and method for scheduling data streaming from a broadcast server to one or more client devices. The data stream is scheduled for transmission based on a weighted priority of quality including service metrics. The transmission stream is arranged according to a frame protocol that supports private data, shared data, and control data. Index the shared data transmission stream according to a flexibly defined application-specific directory.

Background technique

As society becomes increasingly mobile, mobile computing devices are experiencing a wave of popularity and growth. Cellular phones, wireless PDAs (personal digital assistants), wireless laptop computers and other mobile communication devices are making an impressive attack on mainstream customers. However, constraining this growth and limiting customer satisfaction is the lack of cheap, small, battery-efficient wireless communication systems with a truly adequate high coverage area. Cellular data transmission phone-based solutions are far from high-efficiency and impose a (relative) cost and size burden that makes them unusable. Likewise, other attempts to solve these problems have proved equally unsuitable. For example, a few entities have tried to utilize mobile devices that receive information through frequency modulated (FM) subcarriers. The FM subcarrier (also known as "SCA", Subsidiary Communications Authorization) utilizes the available frequencies above the FM stereo within the available modulation bandwidth of the FM station. Subcarriers are generally leased by broadcasting stations and are subject to FCC (Federal Communications Commission (United States)) or other national regulations.

Some examples of FM subcarrier systems include the QUOTREK system owned and maintained by Data Broadcast Corporation (DBC) for providing stock price quotes for handheld mobile devices. However, the QUOTREK system is a single-purpose system limited to receiving stock quotes. This system has various other limitations that make it unusable as a mobile computing device. Similarly, Seiko Corporation implements an FM subcarrier system in which short messages can be transmitted to a wrist-worn device. However, the hardware and communication schemes used are relatively primitive, resulting in excessive redundancy in message transmission. These and other shortcomings make the Seiko system unacceptable. Similarly, some paging systems are based on FM subcarriers, such as Radio Data System (RDS) or Mobile Broadcasting System (MBS) systems. However, those systems involve short messages that are transmitted in a broadcast mode with a limited data rate. Unfortunately, an acceptable mobile device solution has not yet been discovered by those skilled in the art.

Summary of the invention

In short, the present invention relates to systems and methods for scheduling transmissions. The data stream is transmitted from the broadcast server to one or more client devices. The service provides serialized data to the scheduler in the broadcast server. The serialized data can correspond to shared data, private data, or control data. Schedule data streams for transmission based on weighted priorities including quality of service metrics. The transmission frames are arranged according to a frame protocol that includes a flexible directory indexing system for shared data. The shared data packet is formatted based on criteria known to the specific broadcast service and the corresponding application residing on the client device. The client device receives the directory at the transport layer and informs the application of the data that will be available in the next frame. The application submits a prioritized request to the transport layer, requesting data in the next frame. The data is retrieved by the transport layer for each application, and the data is parallelized by the handler. The time slots in the transmission frame partition are assigned pseudo-randomly for private data, so that each subscriber has a unique set of private data time slots. Encrypt private data in accordance with the prevention of unauthorized reception.

A more complete understanding of the present invention and its improvements can be obtained with reference to the following briefly summarized drawings, the following detailed description of illustrative embodiments of the present invention, and the appended claims.

Description of the drawings

Figure 1 is a schematic diagram illustrating the operating environment; Figure 2 is a schematic diagram illustrating the functional components of an electronic device; Figure 3 is a schematic diagram illustrating a watch device including an electronic system; Figure 4A is a block diagram of a broadcasting and dispatching system; Figure 4B is A block diagram of an example computing device; Figures 4C and 4D are schematic diagrams illustrating the frame transmission sequence; Figure 5 is a schematic diagram illustrating the frame header including a TOC; Figure 6 is a schematic diagram illustrating the TOC range descriptor; Figure 7 is a schematic diagram illustrating the TOC A schematic diagram of a slot descriptor; Figure 8 is a schematic diagram illustrating a private message;

Fig. 9 is a process flowchart of server-side frame scheduling; Fig. 10 is a process flowchart of client-side transport layer processing; and Fig. 11 is a process flowchart of an exemplary conflict detection process arranged in accordance with the present invention.

detailed description

The invention is described in the context of a communication system including wireless client devices. In the described embodiment, the client device may be a watch-type device specifically configured to receive communication signals, as will be described in more detail below. As will become apparent from the detailed description below, the client device receives broadcast transmissions from one or more broadcast towers. The broadcast transmission is provided in accordance with the frame protocol, as will be described further. Use a table of contents to arrange the frame structure for shared data so that wireless devices with limited memory can receive messages.

Although described here in a watch-based system environment, it is obvious that the teachings of this application have the same capabilities applicable to any other mobile or non-mobile devices, such as portable and desktop computers, personal digital assistants (PDAs), cellular phones, alarm clocks, Key chains, refrigerator magnets, wall clocks, etc. The use of the watch is for illustrative purposes, just to simplify the discussion that follows, and it can be used interchangeably with "mobile device" and/or "client device". The terms "customer" and "subscriber" are interchangeable terms that describe the users of a service. Each client (or subscriber) may have more than one client device, where each client device is associated with the client (or subscriber).

The "computer-readable medium" may be any available medium that can be accessed by the client/server device. By way of example, and not limitation, computer-readable media may include computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented by any method or technology for information storage, such as computer-readable instructions, data structures, program modules, or other data. . Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital versatile disk (DVD) or other optical storage, cassette, tape, disk storage or other magnetic storage devices, or other Any other medium that can be used to store desired information and that can be accessed by client/server devices. Communication media generally include computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and include any information delivery media. The term "modulated data signal" refers to a signal that has its characteristic set (characteristics set) or change it in such a way as to encode the information in this signal. By way of example, and not limitation, communication media include wired media, such as a wired network or direct-wired connection, and wireless media, such as sound, RF (Radio Frequency), infrared, and other wireless media. Any combination of the above is included within the scope of computer readable media.

The complete operating environment for the frame protocol will be discussed later with reference to Figures 1-3.

Operating Environment Figure 1 shows a typical operating environment (100) of the present invention. As shown in the figure, the FM transceiver or broadcast is transmitted to various electronic devices through the communication channel (110). Example electronic devices with FM receivers or transceivers may include desktop computers, watches, portable computers, wireless cellular phones (cell phones), and personal digital assistants (PDAs). These electronic devices are arranged to receive information from this FM broadcast. FM broadcast can be one of many types, including but not limited to: standard FM transmission, subcarrier FM transmission, or any other type of FM transmission, as may be desired.

The FM subcarrier is often referred to as SCA, such as the term defined by the Federal Communications Commission (FCC) for "Subsidiary Communication Authorization". The FM subcarrier utilizes bandwidth that is not otherwise used in the FM stereo band of the relevant FM station. In the United States of America, the FCC requires the modulation bandwidth to be approximately within the FM radio modulation bandwidth from 53KHz to 100KHz.

An example electronic device is shown in FIG. 1, which may include an electronic system arranged to operate in accordance with an interactive model. This electronic system can use a wireless interface, such as the FM transmission system described above. Each electronic system receives a stream of messages through a communication channel.

Each broadcast transmission corresponds to the transmission of one or more frames. Each frame can include multiple messages, some of which are public broadcast (ie, "global" or "shared" messages), and the other messages are client-specific messages (ie, "personal" or "private" messages) . Each client located in the designated service area can receive shared data, while a single client can decode private data. As mentioned earlier, a subscriber (or customer) may have more than one client device, where each client device may be able to receive transmissions accessible to this subscriber.

The electronic device (for example, a wireless watch device) receives the packet for this client device. Groups are organized in groups according to logical slot (or channel) entry numbers. The time slot is associated with the broadcasting service of a station corresponding to a channel. Each electronic device can be configured to receive different channel groups. The packets associated with each of those channels are received, processed, and stored in this client device. The stored packets are retrieved by the application program residing on this client device. Each application on this client device is associated with a specific service, which is associated with a broadcast server and a specific channel. Example channels include: time channel, message channel, contact channel, calendar channel, weather channel, stock channel, news channel, and game channel.

Illustrative Electronic System Figure 2 is a schematic diagram illustrating the functional components of the electronic device (200) arranged in accordance with the present invention. The electronic device (200) has a processor (260), a memory (262), a display (228) and a user interface (232). The memory (262) generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., ROM, flash memory, etc.). The electronic device (200) includes an operating system (264), such as Microsoft's Windows CE operating system or another operating system, which resides in the memory (262) and executes on the processor (260). The user interface (232) can be a series of buttons, a scroll wheel, a digital dial (such as on a typical telephone), or another type of user interface tool. The display (228) may be a liquid crystal display or any other type of display as previously described. In an example, the display (228) may be a touch-sensitive display acting as an input device.

One or more application programs (266) are loaded into the memory (262) and run on the operating system (264). Examples of application programs include telephone dialing programs, e-mail programs, scheduling/calendar programs, PIM (Personal Information Management) programs, Internet browser programs, and the like. The electronic device (200) also includes a non-volatile memory (268) located in the memory (262). The non-volatile memory (268) can be used to store unchanging information. If the electronic device is turned off, the unchanging information should not be lost. Information that can be used by the application (266) and stored in the memory (268), such as messages used by e-mail or other e-mail applications, contact information used by PIM, appointment information used by the scheduler, for instant Instant messaging in instant messaging applications, text messaging in text messaging applications, and so on.

The electronic device (200) has a power source (270), which can be implemented as one or more batteries. The power source (270) may also include an external power source, such as an AC (alternating current) adapter, or a powered docking cradle for replenishing or recharging the battery.

The electronic device (200) is also shown with two types of external notification mechanisms: LED (240) and audio interface (274). These devices can be directly connected to the power source (270), so when activated, they remain on for a duration controlled by the notification mechanism even when the processor (260) and other components may be turned off to save battery energy. The LED (240) can be programmed to remain on indefinitely until the user takes action to indicate that the device enters a powered-on status. The audio interface (274) is used to provide audible signals to the user and to receive audible signals from the user. For example, the audio interface (274) can be connected to a speaker to provide audible output, and to a microphone to receive audible input, such as to facilitate telephone conversations or as a user interface using voice recognition.

The electronic device (200) also includes a radio interface layer (272), which performs the function of receiving and/or transmitting radio frequency communications. The radio interface layer (272) provides a convenient wireless connection between the electronic device (200) and the outside world through a communication carrier or service provider. The transmission to and from the radio interface layer (272) is implemented under the control of the operating system (264). In other words, communications received by the radio interface layer (272) can be distributed to applications (266) through the operating system (264), and vice versa.

Illustrative Watch-Based Electronic System Figure 3 illustrates a typical watch device (300) that includes an electronic system (310) configured to operate in accordance with the present invention. The watch device (300) includes a strap (304), and the strap includes an antenna (302). The antenna can be attached to the strap or integrally formed in the strap. The antenna (302) is connected to the electronic system (310) contained in the watch. The electronic system (310) may be contained in a glass frame as shown in FIG. 3, or in some other part of the watch device (not shown).

The electronic system (310) is arranged as either a receiver or a transceiver type device. As shown in the figure, the electronic system includes a transceiver (320), a microcomputer device (MCU330) and an analog radio (340). The antenna is connected to and controlled by the transceiver (420). The transaction (transaction) between the MCU (330) and the radio component is transmitted through an MCU-digital transceiver interface. The components of the watch device (300) are housed in a watch-sized package and operate on battery power.

The transceiver (320) usually includes a digital signal processor (DSP 324), which performs control, scheduling, and post-processing tasks for the transceiver, and a real time device (RTD 326), which includes a digital radio (digital radio). ), system timing and real-time event dispatch. The DSP (324) is connected to the MCU (330), and the MCU (330) administers the transceiver tasks.

A task of DSP can be for such purposes as subcarrier phase recovery (phae recovery), baud recovery (baud recovery) and/or tracking, compensation for fading effects, demodulation, deinterleaving, channel state estimation and error correction, and processing Data received. The post-processing task of the packet occurs when the entire packet has been received. The DSP (324) analyzes the transmitted data packets to determine the signal timing of the station relative to the local clock of the RTD (326). Synchronize the local clock with the clock signal of the transmitter to maintain the integrity of signal sampling. The receiver is periodically synchronized with the transmitter symbol to minimize misreading of the received data.

The digital part of the RTD (326) may include a system time base generator, such as a crystal oscillator that provides the system clock for the MCU (330) and DSP (324). The time base also provides baud and sampling timing for transmission and reception operations, start/stop control of radio operations, and control of the time to the MCU (330) and DSP (324) clock pauses. The RTD also performs radio operations and can also perform additional operations. The radio (340) is arranged to receive fragments of data arranged in packets.

The operating environments shown in FIGS. 2 and 3 are only examples of suitable operating environments, and are not intended to imply any limitations on the scope of use or the functions of the present invention. Other well-known computing systems, environments and/or configurations that may be suitable for use with the present invention include, but are not limited to, personal computers, server computers, handheld or laptop devices, multi-processor systems, microprocessor-based systems , Programmable consumer electronic devices, network PCs, minicomputers, large computers, distributed computing environments including any of the above systems or devices, etc.

The broadcast service arranges for each broadcast transmission tower to provide a communication signal, which is configured to be received by wireless client devices in a service area. The service area is a geographic area served by one or more broadcast towers (see Figure 1). The FM broadcast tower transmits a signal when controlled by the broadcast server device, as shown in FIG. 4A. The broadcast server device (ie, the "generator") can communicate with the scheduler through a network communication link.

The scheduler is configured as a tool for selecting one or more services. In one example, the user of the client device interacts with a scheduling interface to select services such as news, service prices, weather, and other features such as personal calendars, address books, and so on. The scheduling interface may be a web-based interface that includes the provision of subscriptions for customized broadcast services. The selected service is delivered to the scheduler and queued for future transmissions. At a specified time (or time interval), the scheduler retrieves serialized data from one or more selected services (for example, SVC1-SVC N). The scheduler prioritizes the scheduling of transmissions, as will be described in more detail later. The scheduled transmission is sent to the broadcast server to start a data transmission sequence for the selected service. The broadcast server continuously formats the serialized data into a message stream for one or more wireless client devices; queues the data for transmission; and transmits the queued data to the FM broadcast tower for transmission. The scheduler can be integrated with the broadcast server or as an independent component.

Each broadcast transmission corresponds to the transmission of a frame according to the frame protocol. Each frame includes a frame header and multiple data streams. The frame header describes the transmission environment related to the parameters, such as the frame number identifier, transmission time, time zone identifier, service area identifier, and other environmental information. The frame header also describes one or more directories for sharing data within the frame.

Streams can be classified into shared data (that is, broadcast streams) or private data (that is, personal data), and private data is related to a specific user (subscriber). Each frame includes a directory indicating where the shared data stream is positioned within the next frame to be transmitted.

Instance Scheduler An instance scheduler can be implemented as a computing device. The broadcast server can also be implemented as a computing device. A typical computing device (400) is shown in FIG. 4B.

In a basic configuration, the computing device 400 generally includes at least one processor unit (402) and system memory (404). Depending on the exact configuration and type of computing device, the system memory 404 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.), or some combination of the two. The system memory 404 generally includes an operating system (405), one or more program modules (406), and may include program data (407). This basic configuration is shown in FIG. 4B by those components within the dashed line 408.

The computing device 400 may also have additional components or functions. For example, the computing device 400 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is shown in FIG. 4B by removable storage 409 and non-removable storage 410. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for information storage, such as computer readable instructions, data structures, program modules, or other data. The system memory 404, the removable storage 409, and the non-removable storage 410 are all examples of computer storage media. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, data universal disk (DVD) or other optical storage, cassette, tape, disk storage or other magnetic storage device, or any Other media that can be used to store desired information and that can be accessed by the computing device 400. The computing device 400 may also have an input device 412, such as a keyboard, a mouse, a pen, a voice input device, a touch input device, and so on. Output devices 414, such as displays, speakers, printers, etc., may also be included. All these devices are well known in the art and need not be discussed in detail here.

The computing device 400 also includes a communication connection 416, which allows the device to communicate with other computing devices 418, such as through a network. The communication connection 418 is an example of a communication medium. Communication media generally include computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and include any information delivery media. The term "modulated data signal" refers to a signal that has one or more characteristics of its characteristic set, or changes it in such a way as to encode the information in this signal. By way of example, and not limitation, communication media include wired media, such as a wired network or direct wire connection, and wireless media, such as sound, RF (Radio Frequency), infrared, and other wireless media. The term computer readable media as used herein includes both storage media and communication media.

Transmission format Figure 4A also shows an example frame transmission. Each frame is broken into multiple segments (M). The first part of each segment includes synchronization (Sync) symbols. This frame is allocated on M segments (S0-SM), thus improving data integrity. The receiver in the client device establishes a timing function for receiving data signals with synchronization symbols. Each frame includes multiple (N) packets. The transmission sequence of various packets and segments can be modified so that the frames are interleaved or contiguous.

FIG. 4C is a schematic diagram showing an example frame transmission sequence in which each frame includes 16 segment groups transmitted as interleaved segments. Each segment includes 1280 packets, so the entire frame includes 20,480 segments. For the example shown in FIG. 4C, each packet (Px) of a given segment (Sx) is transmitted before the packet of the next segment is transmitted. The transmission sequence for this example frame is: (S0P0, SOP1,..., SOP1279); (S1P0, S1P1,..., S1P1279);...; (S15P0, S15P1,..., S15P1279). According to the example shown in Figure 4C, a new frame transmission starts after completing 20,480 segments of the previous frame.

Figure 4D is a schematic diagram showing another example frame transmission sequence in which each frame is divided into 80 grouped blocks from one of 16 segment groups. For the example shown in FIG. 6, the packets (Px) of a given segment (Sx) are transmitted in a sequence interleaved with the packets of the next segment. Each transport block consists of 80 packets from a specific segment. The transmission sequence of this frame is shown as: (S0P0, S0P1,..., S0P80); (S1P0, S1P1,..., S1P159); ... and so on. According to the example shown in FIG. 4D, the frame reception of all 20,480 segments is interleaved, so the frame is completed on a rolling basis.

The frame protocol structure and interaction organize client devices in a series of layers similar to the OSI (Open Systems Interconnection) network model. These layers include the physical layer, link layer, network layer, transport layer, and application layer. The physical layer receives the FM subcarriers that transmit information and provides symbols for the link layer. The link layer divides symbols into segments, and handles viterbi encoding, data bleaching and interleaving functions. The network layer receives fragments and establishes logical groupings. The network layer also handles CRC (Cyclic Redundancy Check), encryption and Reed-Solomon (Reed-Solomon) encoding. The transport layer decodes the logical grouping to receive the directory, and includes data processing programs to handle the communication with the application layer. The application layer includes a series of applications that reside on the client device and is associated with the subscription of the broadcast service.

The frame structure includes multiple packets, which will be described below with reference to FIG. 5. For the example shown here, each frame includes 20,480 segments broken into 16 segment groups (for example, see Figure 4C), each segment group has 1280 segments, in which each segment includes 68 Symbols, and each symbol represents a packet data bit. Each symbol is transmitted at 12 kbit/s (thousand bits/second), so each frame transmission starts approximately every 2 minutes. The fragments are mapped into logical groups, so 20,480 fragments are mapped into 1280 logical groups, or 128 bytes composed of 16 fragments. The position of a packet within a stream is called a time slot.

The frame header appears in a predetermined time slot of each transmission frame (for example, the first packet of the frame transmission), so the client device can retrieve the frame header packet in a predictable manner. The frame header group includes fields for frame number, time stamp, time zone offset, region definition (region definition), and table of contents (TOC) location definition. The TOC location definition field identifies the slot location where one or more directories appear in the frame transmission sequence. Each successive frame transmission includes another header, which can reference a different number of directories. In addition to the frame header grouping, the grouping can be flexibly defined by the identified service and the corresponding application residing on the client device.

In some examples, the frame header is not received from a transmission, and certain parameters can be estimated based on the most recently received frame header. In one example, this frame number can be estimated based on the current time and the most recently known frame number. In another example, the current time is estimated based on the time associated with the most recently received frame header. For the purpose of the discussion here, the terms "frame number" and "current time" are also referred to as estimated frame number and estimated time.

The frame number is a continuous number that starts at zero and increases with each subsequent frame transmission. In fact, the frame number is not repeated in the subsequent transmission sequence. For example, when a new frame transmission occurs every 2 minutes, a 4-byte frame number will not appear in approximately 15.000 years. The frame number can be used as a seed for encryption and other security protection.

The time stamp is in universal time format (UTC) and specifies the universal time when the frame transmission starts. The broadcast server will adjust the transmission time stamp to account for the network waiting time for transmission on the server side. The client device must compensate for frame broadcast and processing time. The client device can use the time stamp as a tool for synchronizing the current time of the client device in the current broadcast area.

The time zone offset represents the time zone of the geographic area where the frame is transmitted. Each frame transmission occurs in a specific geographic area. In one example, the region is defined relative to the Greenwich Mean Time (GMT) indicator.

The region definition includes a region ID (identifier), a code name, and a frequency list. An instance area ID is a 16-bit value that uniquely identifies the current broadcast area, so that customers can manage roaming, round-trip and travel scenarios. The client device may include a base geographic area identifier. The client device can identify the area ID and selectively filter out stations based on the base area. The code name is a string that provides a textual description of the current broadcast area for display and/or information purposes. The frequency list corresponds to the radio frequencies available in the current broadcast (or service) area. Typical scenarios in each geographic area include very few radio stations, although large cities such as New York may include many radio stations. The value of each item in a station list can be expressed according to a baseline frequency offset. A typical station list item may include items corresponding to a 100kHz offset ranging from the 88MHz baseline transmission frequency up to 108MHz (FM broadcast spectrum). Thus, a station list value of 113 corresponds to an offset of 11.3 MHz from 88 MHz, or a frequency of 99.3 MHz. A dedicated value (such as 0xFF) can be used to indicate that the station list will continue in the next frame of transmission (for areas with no more than 16 stations).

The client device uses the station information to assign itself a specific frequency using a station assignment process. Unassigned client devices scan the entire frequency range (for example, 88MHz-108MHz) to find frames. After recognizing a frame, the client device receives the list of stations and uses the station assignment process to select a station (for example, a base station). The client device then starts to receive packets from the selected station. Once the client device has made a station assignment, the list of stations can be ignored in subsequent frames until the client device loses signal or the server changes the list (for example, a flag is set in the directory to indicate a change in the header) until.

The failover situation occurs when a station becomes unavailable in a geographic area. For example, the number of broadcast towers in a service area is variable, and a particular broadcast tower may become unavailable. The failover situation may be that a broadcasting tower goes offline unexpectedly, or some other failure situation. When a failover situation occurs, or when another station becomes available, the station list acts as a tool for discovering available stations in the current geographic area given by the area ID.

The frame number (or estimated frame number) and group number can also be used to determine the initialization vector of an encryption algorithm. The encryption process uses a service key and initialization vector to encrypt and decrypt packets. For example, a 128-bit service key is required to encrypt and decrypt shared data service packets. The client device has a service key for each registered broadcast service. The data stream for the registered broadcast service can be decrypted by the 128-bit service key.

The broadcast server (ie, the scheduler) adds a frame number for each subsequent frame transmission. A typical frame number field is 4 bytes long. The client device extracts the frame number from the frame header and estimates the frame number to determine whether the frame is a replay attack. The replay attack corresponds to an unrecognized broadcast constructed by an attacker. The attacker records multiple frames from the original frame transmission and broadcasts the frame with the same frame number at a later time.

The attacker can try to change the replay attack by changing the frame number in the frame to an acceptable value. However, when the frame number is used as a seed to calculate the initial value in the feedback mode packet encryption, the attacker's change of the replay attack is invalid. Since the original frame broadcast frame transmission includes packet encryption using frame numbers, the attacker's modified replay attack will not include correct encryption, and the client device will discard the packet when it is invalid. In this way, the frame number can be used as a tool for encrypting packets.

The TOC location definition specifies the number of directories present in the frame transmission and the location of the directories within the frame. The position of the directory identified in the frame header may appear at a changed position within the transmission sequence, as specified by the frame header. The TOC position definition establishes a variable-size structure consistent with the frame. The TOC position can be kept as a list or an array. Each element in the list or array includes a reference (for example, an index) to a logical grouping in which the table of contents can be found in the transmitted frame. The TOC location definition may also include the format type, error correction mode, and error correction setting value of the TOC. An example format type is a class descriptor that is associated with the capabilities of the device by types such as PDA, pocket PC, set-top box (XBOX), etc. Another example format type is a class descriptor associated with a protocol version number and device capabilities.

Table of Contents (TOC) Each table of contents identifies the shared data stream that will appear in the next frame of transmission. The client device schedules the reception of the shared data stream based on prioritization. Because many client devices have limited resources, prioritization can be determined by user interaction, or by predetermined choices associated with subscriptions to broadcast services.

Each TOC group is positioned on a specific logical group, as described in the TOC location definition as described earlier. The TOC packet includes a set of flags and the TOC range descriptor shown in FIG. 5. The flag can be in the 8-bit range, and the TOC range descriptor can be an array (or list) of up to 32 items. The TOC range descriptor is the outermost descriptor of the TOC packet, and is simply called a collection of range descriptors (for example, TOCRanges[]). Each TOC range descriptor (for example, TOC Range0) has an initial position and a TOC slot designator (for example, TOC slots[]). The initial position of the range descriptor can be an 11-bit value indicating the packet offset of the start of the range within the transmitted frame. The TOC slot indicator can be an array (or list) describing the slot group within the range (for example, TOC slot 0:TOC slot N).

An example of the TOC range descriptor in the frame is shown in FIG. 6. A data stream is transmitted over time within a frame. Range 0 is defined by an initial position (position 1) and three time slots numbered time slots 0 to 2. Time slot 0 (R0) includes 4 logical groups, time slot 1 (R0) includes two logical groups, and time slot 2 (R0) includes 4 logical groups. Receive range 1 after a gap in the transmission. The transmission gap can be used by services instead of shared data streams such as private data streams, or some other secondary services. Range 1 is defined by an initial position (position 2) and four time slots numbered time slots 0 to 3. Time slot 0 (R1) includes 8 logical groups, time slot 1 and 2 (R1) each include two logical groups, and time slot 3 (R1) includes 4 logical groups. As noted by this example, each range can have a different starting position, as specified by the TOC range descriptor, and a different number of associated time slots. Each slot does not need the same size for each range and can vary within their range, and their range is identified by the TOC slot descriptor for a given range.

The TOC slot descriptor may include the following fields: service ID (identifier), flow locator, packet count, error correction setting value, and frame reservation. The service ID can specify a specific broadcast service by a 16-bit value indicating the stream type. The stream locator can be a 16-bit opaque value, used by application-level data processing programs. The packet count can be a 2-bit value indicating the number of points contained in the time slot. The error correction setting value can be a 3-bit value that identifies the type of error correction method used by the stream. The frame reservation can be a 3-bit value, which means that the scheduler will guarantee how long time slot assignments will be valid for a given service ID according to the number of frames.

Shared data and data processing programs Shared data is associated with data streams that want to be suitable for multiple customers. Every client accessing shared data must have valid access in the form of encryption keys, appropriate client applications, and control data. Shared data is managed through a set of processing programs, which translate application layer semantics into grouping requests and message reassembly (message reassembly).

The application on the client device is registered at the transport layer. The transport layer maintains a data processing program for each registered application, and retrieves the TOC from the logical grouping received from the network layer. The transport layer informs the registered application that the data stream will be available in the next frame transmission as identified by the service ID. Each application applies a series of metrics to determine the priority of the received data stream, which is submitted to the transport layer at the client device. Prioritization is performed independently by each application on the client device, based on any criteria such as better data, error correction requirements, and basic and increased priority levels. The transport layer checks all requests, decides which request will be accepted, and translates the accepted request into group requests to the network layer. The network layer retrieves the relevant packet in the next frame transmission and passes the packet to the relevant registered application through the data processing program.

The feed corresponds to a complete data stream, which can be processed by the corresponding application on the client device and associated with a specific broadcast service. The shared data stream is arranged in frame transmission according to the type associated with the supply. The client device includes a data processing program for each application residing in the device, so this data processing program is associated with a specific broadcast service. The client device identifies this specific broadcast service based on the service ID received from the TOC slot descriptor. The example data processing procedures described below include compact, sparse, and long types. However, the data processing program can be changed and/or additional data processing programs can be added without affecting the frame protocol. Each application and matching broadcast service can define the behavior of processing specific types of data as identified in the TOC slot descriptor.

The compact data type has a one-to-one relationship between packets and messages, so the entire message is contained in a single packet. The compact data type does not require any header information. The compact data processing program uses the stream locator from the TOC slot descriptor to determine the starting position of the first compact message in the slot. A subsequent packet of messages follows this starting position, one packet offset at a time. The packet count in the TOC slot descriptor indicates the total number of compact messages associated with the broadcast service. An example of a compact message is the stock quote of a stock channel broadcast service. The broadcast service of the stock channel may have a series of subscribed stock quotes indexed by the application on the client device (for example, MSFT, IBM, ORCL, etc.). For this type of data flow, the flow locator identifies the starting position of the stock quote message on the stock information application for the client device. Each subsequent stock quote is an independent message, followed in sequence after the start position identified by the stream locator.

The sparse data type is a data stream that is distributed among multiple packets. The application on the client device requests data from the transport layer, based on the information retrieved from the TOC (eg, service ID). Sparse data can span multiple groups, generally less than six to ensure data integrity and quality of service. In the sparse data stream, each packet is called a fragment, in which each message has at least one fragment. The header of each packet is retrieved by the corresponding application on the client device, identifying the number of segments that constitute a complete message and the segment number of the current packet in this message. The stream locator in the TOC range descriptor indicates the position of the first segment (or packet) in the sparse data stream. Each independent packet is treated as an offset from the position of the first packet.

An example of a sparse data stream message is a news story in a news channel broadcast service. The broadcast service for the news channel may require multiple information packets to transmit all the text associated with this news story to the client device. This news story is interrupted into multiple packets that may not fit in a single transmission frame, where each packet includes a packet (or segment) number and a service ID. The number identifies a specific packet (or The location of the segment), the service ID identifies this news stream.

An example TOC slot descriptor for sparse data types is shown in Figure 7. This TOC slot descriptor provides the client device with the service ID (service ID) associated with a specific application, the flow locator (flow locator) in the data flow, and the number of packets following (packet count). In the example shown in FIG. 7, four packets have been given to the broadcast server, and the broadcast server has selected to send the last two packets of message #569 and the two packets of message #570. Assuming that four packets were applied to this broadcast server last time, it chose to send the first half of #568 and #569. The client collects all groups of messages before parallelizing the content for the application layer.

The long data type is a data stream in which a complete message is distributed among a large number of packets, such as the transmission of a file. The long data type has a one-to-one relationship with the service ID and message number. For a long data stream, error correction codes are added at the end of the data stream to ensure data integrity through the communication channel. In the TOC slot descriptor, the stream locator is used to indicate the sequence number that extends the range of the packet over multiple slots. For example, a long data stream may need to send 6K of data. However, the scheduler process on the server can assign 4 time slots in each frame for long data streams, where each time slot includes 8 packets. The long data processing program breaks 6K data into 8 packet blocks, and assigns a sequence number to each block starting with 0.

Private data Data intended to be sent to a specific subscriber is considered private. Private data can be assigned to each subscriber-identified device (for example, more than one device), or a single subscriber device. Private data is provided as a message, which can traverse multiple packets, and each packet constitutes a segment of the entire message. Private data can also be referred to as private or personal messages. Personal messages do not have a service ID, and do not use the directory as described earlier about shared messages.

A private message includes a header, which includes a message ID (identifier), fragments in message, fragment index, private packets per frame, and data. The server establishes a 10-bit message ID to identify the message and avoid duplication. Each private message is organized into multiple groups identified by segmented 6-bit values in the message. Each packet is indexed by a 6-bit value of the segment index, indicating the position of the current packet in the total number of packets suitable for private messages. Each frame field of the private packet corresponds to a 2-bit field, indicating the number of packets that the client should request. The data field is the actual data bytes that are parallelized after all the segments have been received for private data.

In order to prevent unauthorized reception of private messages, an encryption key is used to encrypt the private messages, and each client is assigned a set of intra-frame positions where the private message will be placed. The combination of the subscriber ID (used by all devices belonging to a single subscriber) and the current frame number is used to determine the position arithmetic. A hash function is applied to determine specific locations within the frame (e.g. time slots) where the client's private messages will be located. Both the server and the client know the subscriber ID and do not need to exchange any information, so there is no need for any direct interaction to reach the location of the private message in the transmission frame.

The private message has a waiting time that should not exceed a single frame time (for example, two minutes). Because there will rarely be a situation where a single subscriber does not compete for a specific location, the server uses a gradually increasing priority to ensure that all subscribers receive data fairly. By skipping frames somewhat randomly, the degraded situation of repeated conflicts with higher priority competitors is avoided.

By default, each frame is divided into partitions. The client will request 1 to n packets according to the number of private packets that the server has instructed to transmit. Each requested packet will be mapped to a pseudo-randomly assigned time slot and partition. Each subscriber should have a unique set of time slot/partition assignments for each transmission frame, so private messages cannot be reconstructed by unauthorized users. The same or different amounts can be used to determine the size of the partition. A specific client can have their time slot assignments located in one partition, or located in different partitions, based on pseudo-random assignment methods.

In one example, the time slot and partition assignments are determined by the following algorithm: 1) Using a unique ID and time slot index, calculate a hash value for partition assignment.

2) The hash value used for partition assignment is intercepted according to the total number of partitions in the frame transmission to define the initial position for the unique ID.

3) The frame number is added to the intercepted hash value, so each device cycles through all the partitions.

4) Pick the start and end positions of the partition.

5) Using the unique ID, frame number, and slot index, calculate a hash value for slot assignment in the partition.

6) Collapse the hash value used for time slot assignment, so the collapsed value is suitable for the size of the selected partition.

7) Add the start position of the partition to the folded hash value to determine the packet number for the requested slot.

8) Repeat steps 1 to 7 for indexes 0, 1, 2, and 3.

The following pseudo code shows an example algorithm for partition and time slot determination. This algorithm pseudo-randomly uses the unique ID, frame number, and the number of partitions present in the transmission frame to select the partition and slot location. This algorithm is divided into four parts (ComputePacketSlot, Hash, HashArray, and Collapse), as follows: [Program Code P 27-29] is used An example of a private message for a specific customer is shown in Figure 8. The frame is divided into partitions (for example, five partitions-the same or different sizes). Each private data packet associated with a customer (or subscriber) is pseudo-randomly assigned to one of the partitions using a first hash function. Each private data packet associated with this client (or subscriber) is assigned to a pseudo-randomly selected slot location within the corresponding partition. The slot position is determined by a second hash function. As shown in Figure 8, the slot and partition assignments are determined by the frame number, unique ID, and the number of packets requested (in the case of one packet per slot).

Each client device has a unique 128-bit key, called the "device key". The device key is preferably a permanent key that cannot be changed, such as a laser burned in the chip in a manufacturing plant, so it cannot be changed. The device key is used to encrypt activation messages. The device key is also used to encrypt messages addressed to a specific client device (as opposed to all devices registered with the same subscriber).

Each subscriber has a unique 128-bit key called a "subscription key" (or "control key"). The subscription key is generated when a user subscribes to a private messaging service. During device activation, the subscription key is sent to the client device encrypted with the device key.

All subsequent personal messages for this subscriber are encrypted using this subscription key. Each broadcast service has a unique 128-bit key, which is called a "service key". To simplify configuration and use, services are grouped by tier. All services in a class share the same encryption key. When a user subscribes to a service, he receives this key encrypted with the subscription key as a personal message. The service key can be changed periodically, such as once per billing cycle, so those users who have paid for this service receive the service key.

A special algorithm is used to derive a value from a key. This algorithm exists in using this key to encrypt a known string (for example, "hello world") and extract the required number of bits. This derived value is named "key signature" and is used for multiple purposes, as described below.

The signature of the device key is used as a device identifier. The user enters this identifier to the website when registering a device. This key generation process ensures that only keys with unique signatures are used. The signature of the device key is used as a seed for calculating the slot position of the activation message in the frame (this happens before the device has been activated-it has not yet received the subscription key).

The signature of the device key is also used as a seed crystal for calculating the activation station for this device. In one example, the unique identifier corresponds to a unique serial number (unique serial number) associated with the client device. An example unique code may be a 128-bit code in which 32 bits of the unique code are used as an offset to determine the tower assignment from the list of available towers in the service area. For example, offset = N mod n, where N corresponds to 32 bits from a unique code, and where n is the number of stations available in the service area.

The signature (signature ID, or unique ID) of the subscription key is used as a seed for calculating the slot position of the personal message in the frame after the activation has been received. The subscription key signature is also used as a seed crystal for calculating the assigned station for this device (in which this device listens for personal messages).

The broadcast server is arranged to encode private messages for transmission to a specific client in a similar manner as described above. The broadcast server knows the unique control key for each client device. Each personal message is encoded in accordance with the unique control key and unique identifier for the client device. The block encryption algorithm uses two values. One is fixed (key) and the other is variable (initial vector or "IV"). Use the frame number and the group number to calculate the IV. Because the frame number is guaranteed to increase for each frame, the IV will always be different. In one example, the broadcast server calculates a 128-bit code, which is the same as the 128-bit code calculated by the client device. Use the self-assignment process described above to determine the automatic assignment and personal message channel of the broadcast tower.

The default mode for retrieving personal messages is to try to obtain four (4) packets per frame. This is a battery life-consuming operation, but reduces the waiting time in key scenarios, such as signing or device reset. The Private Packet Per Frame field in each private data packet can be used by the service to indicate the number of packets that the client should try to retrieve in subsequent frames. Recognize that this does not guarantee that the server will actually populate as many packets or the client will successfully receive as many packets; rather, it is adopted as more than one prompt.

Encrypt groups based on the above-mentioned various keys for each client. In one example, encryption is done by calculating a hash using the subscription key corresponding to the customer (or subscriber). This hash is included in the packet transmission. The client device ignores the private message packet when the hash transmitted in the private message packet does not match the hash calculated by the client device. In order to correctly interpret the private information, the private message payload is required to be encrypted with the client's key (subscription key). Pseudo-random time slot and partition assignment, together with encryption, prevent unauthorized reception of private messages. Davies-Meyer, MD5, SHA1 or any other suitable hashing program can be used.

The control data client device cannot retrieve the broadcast service until the application on the client device is registered for use. As mentioned earlier, a set of encryption keys, applications, and processing programs exist on the client device to allow correct operation. Initially, the client device can retrieve the smallest information in the form of control data or messages. Control messages provide a tool to transmit operational information to customers.

The activation and deactivation control messages can be used to retrieve the encryption key for each subscription service, or to cancel the subscription from the client device. The local area assignment is transmitted to the client device in the form of a control message, as is the default broadcast channel assignment.

Broadcast server frame scheduling As previously described with respect to FIGS. 4A to 4D, the broadcast server is arranged to select the data to be transmitted in each frame. The selection of data for a given data frame is based on the priority levels assigned by each broadcast service and the quality of service metrics applied by the frame scheduler.

The scheduler uses priority scheduling to balance the load on the communication, so that the transmission bandwidth is fully utilized. The data stream can be of different data types such as private data, shared data, and control data. Private data is directed to a single user, while shared data is broadcast to the group of client devices as previously described. Control data can be transferred to a single client device or a group of client devices, and transfer bookkeeping and configuration information.

The scheduler is a distributed model in which the handlers for shared services, private messaging services, and TOC managers provide part of the scheduling functions. The scheduler assigns the packet to the time slot based on the next frame transmission based on a priority algorithm, as will be described with reference to FIG. 9.

The shared data and private data service handlers are registered to the TOC manager, and the TOC manager sequentially registers with the scheduler. Before assembling a transmission frame, the scheduler submits a request to the TOC manager to generate a time slot (generate a time slot). The TOC manager will update the information to reflect the last transmission sequence (Review Slots). The check slot assignment is described in more detail below.

Slot assignments are maintained for multiple transmission sequences, so the client device can rely on the slot location specified for specific information. The frame reserved field of the slot descriptor specifies the number of transmission sequences, and the slot assignment for these transmission sequences will remain unchanged. After the TOC manager completes this transmission sequence, it will reduce the frame reserved field of each slot descriptor. All time slots with a corresponding frame reserved field with a value of zero are reclaimed as available by the TOC manager. However, the permanent slot assignment can be overridden by a private message, as will be described in more detail later.

After checking the slot assignment and reclaiming the available slots, the TOC manager submits a request (Reg. Update Slots) to the registered shared data service handler to update the slot. The shared data service handler processes this request so that the locator field for the assigned time slot descriptor is updated (update locator). The TOC slot descriptor field associated with the assigned slot is updated to reflect the change in the locator field and returns to the TOC manager.

An example locator update will be described below with reference to FIG. 7. Messages #568-#570 are associated with a shared message service as identified by service ID 1024. For message #568, all messages include two packets. For message #569, all messages include four packets. For message #570, all messages include two packets. A prior needs request (see discussion below) results in a time slot assigned to a service identified by a service ID 1024 with a length of four packets (packet count = 4). In the first transmission sequence, the TOC slot descriptor includes a first service ID of one thousand and twenty-four (1024), a first stream locator of eighteen (18), and a first packet count of four (4). After the first transmission sequence, the shared data processing program updates the TOC time slot descriptor, so that the TOC time slot descriptor in the second transmission sequence includes the second service ID of one thousand and twenty-four (1024), the second stream The locator is twenty-two (22) and the second group count is four (4). Message #569 is an example of a shared data stream divided into two segments (two separate transmissions).

After updating the TOC time slot descriptor, the TOC manager submits a message requesting needs (Req.Needs) to the registered shared data service handler. The shared data service handler checks the transmission history associated with the shared data service and determines the number of time slots and packets requested for the next transmission frame. The shared data service handler also prioritizes its own needs requests and determines the needs request for the next frame transmission. Requests for needs include a priority of the request, and a desired number of packets associated with time slots (for example, 1, 2, 4, 8, 16 packets for time slots). As discussed earlier, each application or shared data service is free to determine its own priority for message transmission. Need requests (Needs) are provided to the TOC manager.

Next, the TOC manager requests coverage from the private data service handler (Req.Override). Each private data service handler determines its needs for the next frame transmission. The private data service processing program determines the time slot assignment based on the pseudo-random assignment method described above. The private data service handler will request to reserve multiple private data packet time slots in the next transmission frame. In some cases, the message will be an urgent way that requires immediate transmission, or the private message has been waiting for a long time without being transmitted. In this example, the private data service handler may require this message to be sent in the next transmission frame, by generating an override request to the TOC manager, indicating that the private data message must be sent in the next frame transmission.

The TOC manager checks all need requests from shared data service handlers and all cover requests from private data service handlers. After checking all requests, the TOC manager allocates time slots for the assignment of sharing data in the next frame transmission. The time slot allocation is loosely based on the priority level requested by the service handler, and adjusted by the scheduler based on the quality of service and other metrics. After completing the time slot allocation, the TOC manager sends a message to the shared data service processing program (Req. Generate Packets) to request packets for the shared data time slot allocated in the next frame transmission.

In response to a request to generate a packet, the shared data service handler fills the assigned slot (Fill Slots) with the packet identified by the TOC slot descriptor. The packet is encrypted by the shared service handler so that only those client devices that subscribe to a specific broadcast service can successfully decrypt the message. After all the time slots allocated to the shared service have been filled, the TOC manager reserves the packet for the next transmission frame and updates the TOC for the current frame. As mentioned earlier, TOC is a forward-looking index, which identifies the shared data that will be available for transmission in the next frame). The TOC manager returns the filled shared data slot and the list for the current transmission frame to the scheduler.

The scheduler sends a message to the private data message processing program to request private data packets (req. Generate Private Packtes). The private data message processing program provides message packets to the designated time slot (as previously determined using the pseudo-random method). The scheduler then completes the assembly of the frame and provides the completed frame to the broadcast server for transmission.

Since private data is added to unused time slots after shared data, it is possible to repeatedly schedule private data outside of the next frame transmission. The Overrider feature helps prevent private data streams from being pre-occupied by a slot assignment that is away from a sticky slot assignment from a shared data stream by aggressively allocating. Two types of time slot assignments can be produced as a result of one coverage (early and late time slot coverage). Early time slot coverage occurs when a time slot coverage request is received before the TOC is configured, so that the time slot assignment is preempted by private message coverage (before the time slot is allocated to the shared data service). Late slot coverage occurs when a slot coverage request is received after the TOC of an allocated slot has been transmitted.

As mentioned earlier, the TOC slot descriptor includes a frame reserved field that specifies the number of consecutive frame transmissions associated with a particular shared data service. The frame reserved field forms a contract between the scheduler and the shared data service. Late time slot coverage violates this contract, because this time slot should not generally be allocated to any other service until this time slot becomes available again in the future. The TOC is not updated to identify this coverage. Because the private data is transmitted in an encrypted format, the time slot indexed by the TOC will be ignored by the incorrect client device and accepted by the desired client device with the correct decryption key.

As indicated by Figure 9, each service registered with the TOC manager can determine its own prioritization. Since multiple services are competing for the time slot in the next transmission frame, the TOC manager finally decides which service to allocate the time slot in the next frame transmission.

A variety of parameters are used to determine the priority weights used for streams to maximize the use of available bandwidth and provide sufficient quality of service for client devices. The criteria used to determine the priority of a particular service include: data expiration time, time stamp, length of service queue, number of subscribers to the service, quality of service, and priority for pre-assigned slots (preference for pre-assigned slots) The maximum number of time slots that can be retrieved by a client device in a frame, and other rules as may be required to provide a satisfactory user experience.

The data expiration time can be associated with a specific service in which the data becomes out of date after certain time intervals. Examples of time-sensitive services include: stock reports, traffic reports, weather announcements, headline news, and astrology. Stock quotes will only be valid for a few minutes during trading hours, but will be valid for a full day after the stock market is closed. Traffic information may only be useful for up to half an hour. Headline news can be valid for a few hours, while astrology is valid throughout the day. The priority used for time-sensitive data types is higher than those that are less time-sensitive.

The time stamp is combined with the data expiration time, and combined with the number of retransmissions associated with a message. The service with the least number of transfers will have increased priority as the data expiration time approaches.

In a single transmission, a long message cannot be retrieved by the client device, and multiple transmissions are required to complete the transmission. By assigning a higher priority to the long transmission sequence, this long transmission sequence will be cleared out of the queue after a few (or more) consecutive transmissions. Otherwise, the long transmission sequence may be broken after a very long frame. Use the length of the service queue to handle variable data flows.

The number of subscribers subscribing to a service also involves priority. For example, a service with a very high number of subscribers will have a higher priority than a service with very few subscribers.

The quality of service requires that each service has a time slot for transmitting messages. For example, a service with a very low number of subscribers can be pushed back in time so that it is transmitted too little. Such a low popularity service must be able to have a time slot to send the minimum number of points to maintain a high quality of service.

Some client devices will have limited memory and therefore can only receive a limited number of message packets. The scheduler should not send an excessive number of message packets for each service, because the client device cannot retrieve all the packets. Assign priority to message packets so that the group of message packets is sent within the amount that the client can retrieve.

The scheduler prefers to keep sticky assignments with each service, so client devices that have lost the list can try to receive messages from the most recently known time slot assignment. However, the sticky assignment can be overridden by a high priority message. The aforementioned frame reserved field in the TOC slot descriptor reflects the assignment of stickiness.

Each service type has a priority level, which is assigned according to a weighting function (Ps). For example, service (S) has a priority level (Ps) given by Ps=f(Vs, Ws), where Vs is the value set of the criterion for service S, and Ws is the weighted set assigned to the criterion. The scheduler can adjust the weighting value for each service to provide the maximum quality of service. Give an example weighting function such as: Ps=Σi(Vsi×Vi).]]> Customer Transport Layer Processing The following describes the customer transport layer processing with reference to Figure 10. As mentioned earlier, client devices can only receive a limited amount of information at any given time. Client devices have a series of resident applications that compete for data streams from the network. Each application freely defines the packet formatting associated with that application. The transport layer does not know the semantics required by the application, and instead only cares about receiving and paying for logical groupings from the network layer. However, because multiple applications compete for packets, the transport layer must prioritize data requests from each application.

The application registers with the transport layer so that the handler for the application is activated (or connected). The transport layer receives logical packets from the network layer. The transport layer will extract the frame header to find the location of the directory related to the logical grouping.

Extract a directory from the logical grouping and notify the registered application that the available grouping will be found in the next frame transmission. The registered applications then determine their own priority level associated with a data request from the network based on their own metrics. Registered applications send prioritized data requests to the transport layer through corresponding processing procedures. The transport layer receives all priority requests and decides which packet will be retrieved from the next frame transmission. The additional directory can be retrieved until the transport layer has enough requests to fully utilize the receiving capabilities of the client device, or until the end of the transmission frame is received. The transport layer then generates a packet request to the network layer.

As mentioned earlier, the client device will schedule the reception of shared data streams based on prioritization. Since many client devices have limited resources (for example, limited memory), it is impossible to receive all possible data requests in the same frame of transmission. The client device prioritizes the request based on user interaction and/or by a predetermined selection associated with the subscription of the broadcast service. In one example, a client device can be configured by the user to monitor stock prices on one channel, and some lower priority content on other channels (for example, daily astrology). The stock price changes rapidly during the working hours of the transaction. Since the stock report is time-sensitive (stock prices change rapidly), the stock channel can have an increased priority level during the working hours of the transaction, and a lower priority after the end of the transaction.

In the next frame transmission, the logical packets are transferred from the network layer to the application handlers, which assemble the message flow. In one embodiment, the handler identifies the completed message and transmits the completed message to the application for further processing. In another example, the handler recognizes that the message has not been completed in an excessive amount of time, and discards the message as invalid. The application receives and processes messages when requested. Some messages require processing because of encryption or formatting specified by the specific needs of the matching broadcast service.

An example message transmission was described previously with reference to FIG. 7. In the first example of frame transmission, the application matching the service ID 1024 receives a compact message #568. For this example, the handler does not require additional processing because the entire message is received in a single time slot in this transmission frame. In the second example frame transmission, the application matching the service ID 1024 receives the segment of message #569 identified by the stream locators 22 and 23. The handler recognizes that these received specific packets are associated with logical packets 3 and 4 of a 4-packet transmission. The application will request to receive packets 1 and 2 in the next frame transmission. In one example, the second segment of this message is received and the complete message is assembled by the handler and delivered to the application. In another example, the second segment is not received in a timely manner; the message becomes out of time and the incomplete message is discarded.

The transport layer acts as a scheduler, which balances the available data streams with prioritized requests generated by each application. In this way, scheduling-based clients are distributed on both the server side and the client side. The server side determines the frequency of transmission of subscriber services, private messages, and control data, while the client side determines which of the available data to retrieve. Since the private message packet has no header and is not referenced by a directory, the private message packet is transferred from the network layer to the application layer.

Collision detection relies on the pseudo-random time slot assignment method described above to avoid personal message collisions. However, errors may occur during frame transmission, as are other problems that cause collisions. In one example, a late time slot is assigned to a personal message covering a directory entry for broadcast data. For this example, the client retrieves a packet corresponding to the time slot assignment identified in the directory and detects that the received packet is a conflict. The broadcast data packet from that particular time slot is discarded (or ignored) because it cannot be decrypted without error.

Fig. 11 is a processing flow chart of an example conflict detection process, which is arranged in accordance with the present invention. Processing starts at block 1101 and proceeds to block 1102.

At block 1102, a decryption process is applied to the received packet. The decryption process can be any suitable decryption method. In one example, the message is encrypted with an encryption key, in which the client has a matching key for decryption. Processing continues from block 1102 to block 1103, in which the client device applies a CRC check process to the decrypted packet. Continuing to decision block 1104, the client device evaluates the result of the CRC check. When the CRC is valid, processing continues from decision block 1104 to block 1110. Alternatively, when the CRC is invalid, the processing continues from the decision block 1104 to the block 1105.

At block 1105, an error correction method is applied to the packet. Error correction can be any reasonable error correction method. An example error correction method is Reed-Solomon. Processing continues from block 1105 to block 1106, in which the client device decrypts the error-corrected packet. Continuing to block 1107, the client device applies a CRC check to the error-corrected decrypted packet. Continuing to decision block 1108, the client device evaluates the result of the CRC check. When the CRC is valid, processing continues from decision block 1108 to block 1110. Alternatively, when the CRC is invalid, the processing continues from the decision block 1108 to the block 1109.

At block 1109, the client device has identified that the received packet is a conflict. An invalid packet may be the result of noise in the environment that has corrupted a packet, an invalid packet transmission, or a packet slot assignment that does not match the directory from a previous transmission. This time slot may have been assigned to a different client device with a different decryption key. In one example, the slot assignment is a late slot coverage, as described previously.

The above description, examples and data provide a complete description of the manufacture and use of the composition of the present invention. Since many embodiments of the present invention can be produced without departing from the spirit and scope of the present invention, the present invention resides in the claims hereinafter appended.