[This is preliminary documentation and subject to change.]
In some cases, scheduling when broadcast data is transmitted can be trivial. In the case of a stock ticker service, for example, the data is transmitted as soon as it arrives. In many cases, however, scheduling is an extremely complex task, particularly if bandwidth is limited. Trade-offs may need to be made balancing value, urgency, precision, and data size. For example, if a data file is large, you may have to send it less often, sacrificing speedy delivery and the amount of error correction data that can be sent. Tools to facilitate this process will be extremely useful. Some considerations regarding creating such tools follow.
When the decision is made to broadcast a specific content file, relevant information must be placed in the content lookup database. This information includes the data service over which the broadcast is to occur, any authentication information required to secure bandwidth on that data service, the time or times of broadcast, the amount of bandwidth required for the broadcast, and any other information needed to ensure that the broadcast goes out over the right channel at the right time.
A scheduling system should also take into account any dependencies recorded in the content lookup database, allowing an operator to schedule these dependencies at the same time. For example, if a television show required some enhancements to be preloaded, the scheduling system should transmit such enhancements before the show.
Because scheduling is a common and repetitive task, as much as possible of the relevant scheduling information should be stored in a scheduling database. Applications running on the head end can retrieve this information automatically to support scheduling of individual content files.
The following diagram illustrates the components of this kind of scheduling process.