Patent Application
20050262253
This invention relates generally to the field of distributed multimedia streaming and more particularly to media content distribution for high bit rate streaming from distributed components
High bit rate multimedia streaming, particularly high bit rate video streaming has evolved from handling thousands of simultaneous subscriber to millions of subscribers. The conventional system architecture based on a single powerful machine or a cluster system with central control can no longer meet the massive demands.
A scalable distributed multimedia streaming system employs at least one media station having a media director and a plurality of media engines. Each media engine incorporates media content storage, communications channels for retrieving media content over the network and communications channels for streaming media content over the network. The media director has a controller adapted for directing retrieval over the network of media content by a selected media engine, tracking content stored on the media engines and redirecting a content requested from a media console connected to the media station to a selected one of the media engines storing content corresponding to the request for streaming. Multiple media stations are employed to expand the network using a media location registry communicating with the media director in each media station. The media location registry is a central repository for storing the location of all media content in the media stations. Downloaded content can then be presented by the media stations to the media consoles connected to them through a network and intercommunication between the media stations for transfer of content can also be accomplished through the network.
These and other features and advantages of the present invention will be better understood by reference to the following detailed description when considered in connection with the accompanying drawings wherein:
a is a diagram of the hardware interaction and process for streaming data to a subscriber's media console;
b is a flow diagram of the process for streaming data as shown in
A media content distribution system incorporating the present invention employs a self-sufficient streaming unit designated a media station covering a set of subscribers. Media stations in a typical application are installed in a CO of a broadband network to which the subscribers are connected. The placement of media stations is determined according to the number of subscribers to be covered, network topology and available bandwidth of the network.
As shown in
Each media program (a movie, a documentary, a TV program, a music clip, etc.) is partitioned into smaller segments. Such partitioning provides a small granularity for media data units and makes data movement, replications, staging and management much easier and more efficient.
The MAM determines when and where to distribute a program. The CM publishes the program at the time specified by the MAM and the MLR identifies the location of the data for distribution
For streaming content to subscribers, the media director in each of the media stations employs a load balancing scheme to keep track of the task load of the media engines in the media station. Load balance is achieved by directing streaming requests according to current system states and load distribution. An example of the communications sequence for data transfer under the command of the media director is shown in
A flow diagram of the sequence described with respect to
As a portion of the load balancing scheme, a rapid replication scheme is used to copy a segment from one media engine to another. When a media engine exceeds its capacity of streaming, a highly demanded segment can be replicated to another media engine and further requests for that segment are directed to the new media engine. The extra delay observed by the streaming request that triggered the replication is less than 30 milliseconds in exemplary embodiments.
The communications sequence is shown in
A stream swapping method is used to exchange two streams of the same segment, one on a first media engine ME2 that has a complete copy of the segment and a second on a second media engine ME1 which is currently receiving the same segment. Where the subscriber attempts a fast-forward while streaming from ME1 with the incomplete segment, the media director swaps the fast-forwarding stream from ME1 to ME2 (with the complete segment). The stream using the same segment running at normal rate is swapped from the first media engine to the second media engine thereby avoiding a failure of the fast forwarding operation.
The media engines in the media station are symmetrical with respect to input and output thereby allowing data to be taken into the media engine substantially as rapidly as streaming data is sent out. As shown in
Data in a segment is partitioned into “datalet”, which is the minimum disk I/O unit and buffer allocation unit. For each outgoing stream (stream that is being sent to an MC), a number of buffers 604 connected to a bus 606 from the drive units are used to pre-fetch datalets for the stream. Datalets are distributed to the disk drives in a media engine (for the embodiment shown in
The I/O operations on each disk are optimized by performing the operations in the sequence of their disk addresses so the seek time is minimized. A disk controller 608 operating in concert with an I/O controller module 610 provides sequencing control.
The network interfaces of the media engines are full-duplex Gigabit Ethernet, which provide up to gigabit/second bandwidth in either direction, incoming into a media engine or output from a media engine. The incoming data is buffered in the same fashion as the output data, and the incoming data is written to the disk in the same pattern as the data is read from disk.
Therefore, the media station can be used as a high bit rate, massive storage repository. This architecture is specifically beneficial in live broadcast transmission where the program segments are transferred to the media stations in real time and streamed to the media consoles.
For content which is not yet present, or not complete, on the media stations but available on the system, a request from a subscriber results in transfer of the content as shown in
From a hardware standpoint in a representative embodiment, the Media Station comprises one or more chassis each having multiple individual blades as shown in
In the embodiment shown, the Media Station is a level of abstraction, with its state represented by its MD. Therefore, the MS need not be an entity in the management structure of a network management system (NMS) 806 employed for hardware control.
Network management is a first level of management for the media station(s) and provides a full set of management functionalities and GUI. System load and other operational parameters such as temperature and fan speed are monitored. Automatic alarms can be configured to send email or call to the system operator.
Chassis management is the second level and provides blade presence detection, automatic blade power up, remote blade power up and power down, managed blade power up to avoid current surge during disk drive spin up, chassis id reading and chassis control fail-over.
Blade self-management and monitoring is the third level and allows temperature, fan speed, and power supply voltage monitoring and alarm through SNMP to the NMS, self-health monitoring including critical threads monitoring, storage level monitoring, load monitoring, etc. All alarm thresholds can be set remotely by NMS. For software related failures, software restart or OS reboot will be attempted automatically, and the event will be reported to NMS.
As shown in
All blades in a chassis are equipped with a control unit or Chassis Blade Controller (CBC) 906. For the exemplary embodiment, each CBC consists of an Intel 8501 chip implementing the control logic and an FPGA configured to act as the control target. The 8501 chip also communicates with the main board 908 through a UART interface 910. The main board can issue control commands or relay control commands received from NMS through the network to the CBC.
For the exemplary embodiment, blades located in slot 5 and 6 are the control blades. One active and one standby determined by the arbitration logic at power up. When the chassis is being powered up, the blades in slots 5 and slot 6 arbitrate and one becomes the active controller or media director. The CBC on the active control blade scans the back-plane and powers up the blades in a controlled sequence with a pre-determined interval to avoid current surge caused by disk drive spin up on the individual blades.
The CBC on the active control blade then scans all slots on the backplane and detects the presence and status of each blade. The standby control blade monitors the status of the active control blade. When the active control blade gives up the control, the standby automatically takes over and become the active control blade.
During normal operation, the CBC on the active control blade periodically scans the backplane. If a new blade is plugged in, it will be automatically powered up.
The active control blade register itself with NMS, and can take commands from NMS for controlling other blades in the chassis, such as checking their presence and status, power up/down or power cycle a blade, etc. The non-controlling blades also register themselves to NMS and can take commands from NMS to reboot or power down.
From the management point of view, each blade is a standalone computer. Besides its application functionalities, each blade has management software to monitor the health of the application software, system load and performance, as well as hardware related parameters such as CPU temperature, fan speed, and power supply voltage. The blade management software functionality is shown in
The streaming application threads 1002 put their health and load information into a shared memory area periodically. The management monitor thread 1004 scans the area to analyze the status of the threads and the system. In addition to periodically reporting the state information to NMS through a SNMP agent 1006, appropriate actions as known in the art are taken when an abnormal state is detected.
As previously described, a service token based authentication scheme is employed as the precursor for any data transfer requested by a subscriber's media console.
A media console possesses two numbers, MC_ID and MC_Key. Those numbers can be burned into a chip in the box, be on a Smartcard, or be on any form of non-volatile memory in the box. When a subscriber signs up for the service, the Subscriber Management system records the numbers and associates them with the user account. MC_ID and MC_Key will be subsequently passed to the Authentication Server.
A media console 206 when it powers up, after obtaining IP, sends an authentication request 1202 [which for the embodiment disclosed comprises MC_ID, {MC_ID, MC_IP, Other info, salt, checksum}_MC_Key] to the Authentication Server 1102. Note: {x}_k denotes that the message x is encrypted by k.
The Authentication Server finds the record of the media console using MC_ID, decrypts the message, and generates a session key, MC_SK, and an access_token for the media console. For an exemplary embodiment access_token={MC_SK, service code, timestamp, checksum}_MS_SK, where MS_SK is a secret key established previously between the authentication servier and the media station that serves the media console; “service code” indicates what services the token can be used for. The Authentication Server calculates the “seed key” for MC_SK. The Authentication Server replies 1204 to the media console with [{access_token, MS_IP, salt, checksum}_MC_Key]. The MC decrypts the message with MC_Key and obtains mc_token and the IP address of the Media Director that it should contact. The mc_token will be kept until the media console shuts down, or the Authentication Server sends a new one. The media console sends 1206 mc_token to the application Server in the media station when requesting a media program, or the EPG server for browsing the EPG.
The implementation of the access tokens and encryption of the content provided over the system in an exemplary embodiment employs SecureMedia's Encryptonite System for secure content delivery and access right control.
Having now described the invention in detail as required by the patent statutes, those skilled in the art will recognize modifications and substitutions to the specific embodiments disclosed herein. Such modifications are within the scope and intent of the present invention as defined in the following claims.
