HYBRID EPG SERVER WITH SERVICE DISPATCHER TO BUILD A DISPATCHER REDUNDANCY CHAIN IN CLUSTERED IPTV EPG SERVICE

• US 20090019161A1
• Filed: 07/12/2007
• Published: 01/15/2009
• Est. Priority Date: 07/12/2007
• Status: Abandoned Application

• Current Assignee: UTStarcom Incorporated (UTStarcom Holdings Corp.)
• Original Assignee: UTStarcom Incorporated (UTStarcom Holdings Corp.)
• Inventors: Li, Qiang, Ma, Chen, Wang, Naxin, Zhu, Huiyou
• Application Number:
  US11/776,766
• Publication Number:
  US 20090019161A1
• Time in Patent Office: Days
• US Class Current: 709/226
• CPC Class Codes: H04N 21/26283 for associating distribution time parameters to content, e.g. to generate electronic program guide data
• CPC Class Codes: H04N 21/2665 Gathering content from different sources, e.g. Internet and satellite
• CPC Class Codes: H04N 21/64322 IP
• CPC Class Codes: H04N 21/6581 Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application
• CPC Class Codes: H04N 7/17318 Direct or substantially direct transmission and handling of requests

Abstract

An EPG service architecture incorporates multiple EPG servers connected in a cluster with each EPG server having an EPG service module and a dispatcher. Each dispatcher has the capability for state determination as an active or standby dispatcher. A plurality of STBs interface with the EPG server cluster and issue requests for EPG service which are routed by the active dispatcher. The routing is accomplished by redirection of the request to an EPG service module selected from the multiple EPG servers in the cluster. Each EPG service module includes the capability for service connection to the STB upon receiving the redirection from the active dispatcher. Upon a determination that the current active dispatcher is not operating, the standby dispatchers vote for a replacement which then assumes the active dispatcher role.

Claims

1. An EPG service architecture comprising:

a plurality of EPG servers connected in a cluster with each EPG server having

an EPG service module; and

a dispatcher, each dispatcher having means for state determination as an active dispatcher;

a plurality of STBs interfaced with the EPG server cluster and issuing requests for EPG service;

said active dispatcher having means for routing each request.

2. The EPG service architecture of claim 1 wherein the means for routing comprises means for redirection of the request to an EPG service module selected from the plurality of EPG servers and each EPG service module includes means for service connection to the STB upon receiving the redirection from the active dispatcher.

3. The EPG service architecture of claim 1 wherein the means for state determination includes

means for an initiate mode having

means to send out a probe to gather other dispatcher status;

means to enter into ‘

in Action’

mode and assume control as the active dispatcher of no other dispatcher is running; and

,

means to enter into a standby mode if an “

alive”

signal is received from a currently active dispatcher.

4. The EPG service architecture of claim 3 further comprising

means for looking up a connection hash table and route incoming service request to an appropriate EPG server,

means for synchronizing the connection hash table by mulicasting to the other dispatchers listening in standby and,

means for issuing an “

alive”

signal reflecting its active state, all responsive to the means to enter into the “

in action”

mode.

5. Tne EPG service architecture of claim 4 wherein the means to enter into a standby mode further comprises:

means for listening for predetermined periods for an “

alive”

broadcast;

means to send a probe to detect the status of the currently active dispatcher;

means to handle multicast request from primary dispatcher for connection hash tably sync and return to the means for listening responsive to receipt of an alive broadcast by the listening means;

means for a race state responsive to lack of receipt of an alive broadcast by the listening means.

6. The EPG service architecture of claim 5 wherein the “

alive”

broadcast is in the form a TCP based heartbeat.

7. The EPG service architecture of claim 5 wherein the means for a race state comprises means to determine if the dispatcher has received a probe;

means responsive to receipt of a probe to delay its probe transmissions for random interval and return to the send probe state; and

means to return to the standby state if the dispatcher has not received a probe.

8. A method for EPG service control comprising the steps of:

providing a plurality of EPG servers connected in a cluster with each EPG server having an EPG service module and a dispatcher;

for each dispatcher,

entering into an initiate mode including

sending out a probe to gather other dispatcher status;

entering into ‘

In Action’

mode and assuming control as the active dispatcher if no other dispatcher is running; and

,

entering into a standby mode if an “

alive”

signal is received from a currently active dispatcher.

9. The method of claim 8 further comprising the steps of:

looking up a connection hash table and routing incoming service request to an appropriate EPG server,

synchronizing a connection hash table by multicasting to the other dispatchers listening in standby and,

issuing an “

alive”

signal reflecting its active state, all responsive to the step of entering into the “

In Action”

mode.

10. The method of claim 8 further comprising the steps of:

listening for predetermined periods for an “

alive”

broadcast;

sending a probe to detect the status of the currently active dispatcher;

receiving a multicast request from primary dispatcher for connection hash table sync and

returning to the step of listening responsive to receipt of an alive broadcast;

entering a race state responsive a lack of receipt of an alive broadcast in the listening step;

all responsive to entering into the standby mode.

11. The method of claim 10 further within entering into the race state comprises the steps of:

determining if the dispatcher has received a probe;

delaying probe transmissions for a random interval and return to the send probe state responsive to receipt of a probe; and

returning to the standby state if the dispatcher has not received a probe.

12. The method of claim 8 wherein the step of looking up a connection hash table and routing incoming service request to an appropriate EPG server further comprises the steps of:

if the request is from currently active STB, forward the request to a pre-assigned server for service continuation;

alternatively, if the request is from an unknown STB, looking up the least busy server based on current server connection counter, forwarding the STB request to that server and flagging the STB as active; and

,

intercepting the TCP FIN flag for each connected EPG service session and updating the connection hash table for the current server connection counter.