Abstract:
A system and method of the present disclosure provides a block, or region, based error diffusion process for reducing artifacts in images. The system and method allows for the generation and the control of the spatial frequency of a masking signal, e.g., noise, in a way that it can be easily passed through the compression process. The system and method provides for selecting a block size of pixels of the image, adding a masking signal to the image, determining a quantization error for at least one block in the image, and distributing the quantization error to neighboring blocks in the image to mask artifacts in the image. An output image is then encoded with a compression function.

Description:
CROSS REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims the benefit under 35 U.S.C. §119 of a provisional application 60/925,792 filed in the United States on Apr. 23, 2007. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    The present embodiments generally relate to gateway devices that may be used to provide services for multi-dwelling units (MDUs), and more particularly, to mechanisms for detecting and mitigating failure conditions associated with such gateway devices. 
         [0004]    2. Background Information 
         [0005]    Systems for providing services such as satellite television service have been deployed that utilize a structure that is complementary to the needs of multi-user operation in a single location such as multiple dwelling buildings or apartments. The arrangement of the system used for an installation such as an MDU installation often includes client devices connected through a local network to a central device, or gateway device, that is connected to the service provider&#39;s network. Failures within a given gateway device due to hardware or software may occur and result in degradation of system performance and service calls from users. 
         [0006]    One approach to detecting and mitigating software module failures within a given gateway device involves the use of watchdog monitors. Such watchdog monitors may be, for example, set on a per-thread basis to monitor one or more threads of execution and to indicate thread failure (i.e., micro-level failure detection). In many cases, more complex software modules are comprised of multiple threads of execution as well as third-party object modules that are not monitored, and that may also use the services of a transmission control protocol/internet protocol (TCP/IP) stack. In these more complex modules, the per-thread watchdog monitor approach may not be sufficient to detect a failure of the overall software module or loss of software function point(s). 
         [0007]    Accordingly, there is a need for improved mechanisms for detecting and mitigating failure conditions associated with gateway devices. The present embodiments described herein address this and/or other issues and provides a macro-level capability to detect hardware and software module failures across one or more gateway devices. 
       SUMMARY OF THE INVENTION 
       [0008]    In accordance with an aspect of the present disclosure, a method for detecting a failure in a gateway device is disclosed. According to an exemplary embodiment, the method includes the steps of: receiving a first announcement regarding service associated with operation of a network, determining a classification of the first announcement, initializing a timing interval based on the classification of the first announcement, and providing an error message if a second announcement of a same classification as the first announcement is not received before the timing interval expires. 
         [0009]    In accordance with another aspect of the present disclosure, a gateway device is disclosed. According to an exemplary embodiment, the gateway device includes a network interface for receiving a first announcement regarding service associated with operation of the network, and a processor for determining a classification of the first announcement, initializing a timing interval based on the classification of the first announcement, and providing an error message if a second announcement of a same classification as the first announcement is not received before the timing interval expires. 
         [0010]    In accordance with another aspect of the present disclosure, a further device is disclosed. According to an exemplary embodiment, the device includes means for receiving a first network announcement regarding service associated with operation of the network, and means for determining a source of the first network announcement and a type of the first network announcement, initializing a timing interval, and providing an error message if a second announcement from the source of the first network announcement and of the same type as the first network announcement is not received before the timing interval expires. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]    The above-mentioned and other features and advantages of this present embodiments, and the manner of attaining them, will become more apparent and the disclosure will be better understood by reference to the following description of embodiments taken in conjunction with the accompanying drawings, wherein: 
           [0012]      FIG. 1  is a block diagram illustrating an exemplary system using embodiments of the present disclosure; 
           [0013]      FIG. 2  is a block diagram illustrating a relevant portion of one of the gateway devices of  FIG. 1 ; 
           [0014]      FIG. 3  is a block diagram illustrating an exemplary embodiment of one of the gateway devices of  FIG. 1 ; and 
           [0015]      FIG. 4  represents a portion of a flow chart illustrating an exemplary method using embodiments of the present disclosure. 
           [0016]      FIG. 5  represents another portion of a flow chart illustrating an exemplary method using embodiments of the present disclosure. 
           [0017]      FIG. 6  represents another portion of a flow chart illustrating an exemplary method using embodiments of the present disclosure. 
       
    
    
       [0018]    The exemplifications set out herein illustrate preferred embodiments of the disclosure, and such exemplifications are not to be construed as limiting the scope of the embodiments in any manner. 
       DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0019]    The embodiments described above are primarily directed towards installation systems found in multiple dwelling units. The embodiments may also be used and applied in any network information distribution system utilizing a head-end or gateway interface providing content over a data network to client devices, settop boxes, or receiving circuits. For example, the embodiments described may be modified using techniques known to one skilled in the art to work in an airplane or motorbus passenger entertainment distribution system. 
         [0020]    Referring now to the drawings, and more particularly to  FIG. 1 , an exemplary system  100  using embodiments of the present disclosure is shown. As indicated in  FIG. 1 , exemplary system  100  comprises one or more system to headends (not shown), gateway devices  10 , a main distribution frame (MDF)  20 , a network such as internet  30 , a network operating center (NOC)  40 , intermediate distribution frames (IDFs)  50 , and client devices (not shown). According to an exemplary embodiment,  FIG. 1  represents a typical system that may be employed in an MDU using an Ethernet network or other type of network, such as coaxial cable, digital subscriber line (DSL), powerline networking, or wireless technologies. 
         [0021]    In  FIG. 1 , each gateway device  10  is operatively coupled to and communicates with a system headend (i.e., service provider), such as the headend of a satellite, terrestrial, cable, internet and/or other type of broadcast system. According to an exemplary embodiment, each gateway device  10  receives multiple signals including audio and/or video content from the system headend(s), converts the signal format of the received signals and then sends appropriate data streams in a format, such as the internet protocol (IP) format, through the network via MDF  20  and IDFs  50  to the client devices (e.g., set-top boxes, televisions, etc.) based on requests made by users in the respective dwelling units. As is known in the art, MDF  20  and IDFs  50  operate as switching and routing devices. The number of gateway devices  10 , MDFs  20  and IDFs  50  included in a given MDU installation may vary based on design choice. Each IDF  50  may for example service client devices present on a given floor and/or other defined portion of an MDU. Although system  100  is shown and described herein as being an Ethernet switched network using a specific network format, those skilled in the art will appreciate that the principles of the present disclosure may also be applied to other types of networks such as networks using coaxial cable, digital subscriber line (DSL), powerline networking, and/or wireless technologies, and a number of possible network formats. 
         [0022]    It is important to note that more than one gateway device  10  may be connected to the same system service provider head-end. Multiple gateway devices  10  may be needed in order to receive and distribute all of the available content from the service provider due to design constraints of the size or capability of a single gateway device  10 . Further, the gateway devices  10  may include the ability to connect and communicate between each other independent of, or in conjunction with, the local network connection made to MDFs  20 . 
         [0023]    As indicated in  FIG. 1 , MDF  20  is operatively coupled to and communicates with NOC  40  via internet  30  or other suitable network connection. According to an exemplary embodiment, MDF  20  is operative to receive notification messages related to the operational status of gateway devices  10 , and transmit such notification messages to NOC  40 . In the event that one of these notification messages indicates an operational problem (e.g., hardware and/or software module failure, etc.) with one of the gateway devices  10 , appropriate action (e.g., service call, new software download, re-boot failed gateway device without operator intervention, etc.) may be taken to identify and resolve the problem. According to principles of the present disclosure, each gateway device  10  is operative to detect operational problems present with itself and/or other gateway devices  10  and to provide such notification messages to NOC  40  via MDF  20  and internet  30 . In this manner, the present disclosure is advantageously able to detect and mitigate failure conditions in a gateway device  10  used for example in an MDU network. 
         [0024]    Referring to  FIG. 2 , a block diagram illustrating a relevant portion of one of the gateway devices  10  of  FIG. 1  is shown. Gateway device  10  of  FIG. 2  includes an I/O block  12 , processor  14 , and memory  16 . For clarity of description, certain conventional elements associated with gateway device  10  such as certain control signals, power signals and/or other elements may not be shown in  FIG. 2 . 
         [0025]    I/O block  12  is operative to perform I/O functions of gateway device  10 . According to an exemplary embodiment, I/O block  12  is operative to receive signals such as audio, video and/or data signals in analog and/or digital format from one or more headend signal sources such as satellite, terrestrial, cable, Internet and/or other signal sources. I/O block  12  is also operative to output signals to the one or more headend signal sources. I/O block  12  is also operative to transmit and receive signals to and from MDF  20 . In an exemplary embodiment I/O block  12  includes a signal interface for receiving broadcast signals contain audio and video content and a network interface for transmitting and receiving signals in the form of data signals on a local network including MDF  20 . The data signals may include signals representing audio and video content processed by the gateway devices  10  and network announcements generated by gateway devices  10 . 
         [0026]    Processor  14  is operative to perform various signal processing and control functions of gateway device  10 . According to an exemplary embodiment, processor  14  is operative to process the audio, video and/or data signals received by I/O block  12  so as to place those signals in a format that is suitable for transmission to and processing by the client devices. 
         [0027]    Processor  14  is also operative to execute software code that enables the detection and mitigation of operational problems (e.g., hardware and/or software module failure, etc.) associated with one or more gateway devices  10  (including itself) according to principles of the present disclosure. In a preferred embodiment, processor  14  is a microprocessor operative to execute software code that determines a classification of an announcement after receiving information regarding the announcement. Processor  14  further executes code that initializes a timing interval based on the classification of the announcement, and provides an error message if information regarding a second announcement of a same classification as the earlier received announcement is not received before the timing interval expires. Further details regarding this aspect of processor  14  will be provided later herein. Processor  14  is also operative to perform and/or enable other functions of gateway device  10  including, but not limited to, processing user inputs made via a user input device (not shown), generating outputs including notification messages, reading and writing data from and to memory  16 , and/or other operations. 
         [0028]    Memory  16  is coupled to processor  14  and performs data storage functions of gateway device  10 . According to an exemplary embodiment, memory  16  stores data including, but not limited to, software code, one or more data tables, pre-defined notification messages, user setup data, and/or other data. 
         [0029]    The gateway devices  10  may be configured to receive a number of different types of broadcast signals including a plurality of satellite signals. Gateway devices  10  may also be configured to produce a plurality of network data signals containing audio and video content provided in the broadcast signals, and to provide the network data signals over the network connecting the gateway devices  10  to client devices. 
         [0030]    Referring now to  FIG. 3 , a block diagram of an exemplary satellite gateway device  300  is shown. Satellite gateway device  300  is similar to gateway device  10  as described in  FIG. 1 . As illustrated, the satellite gateway device  300  includes a power supply  340 , two front-ends  341   a  and  341   b  and a back-end  352 . The power supply  340  may be any one of a number of industry-standard AC or DC power supplies configurable to enable the front-ends  341   a, b  and the back-end  352  to perform the functions described below. 
         [0031]    The satellite gateway device  300  may also include two front-ends  341   a, b . In one embodiment, each of the front-ends  341   a, b  may be configured to receive two signals provided from the 1:2 splitters  326   a - 26   d . For example, the front-end  341   a  may receive two signals from the 1:2 splitter  326   a  and the front-end  341   b  may receive two signals from the 1:2 splitter  326   b.    
         [0032]    The front-ends  341   a, b  may then further sub-divide the signals using 1:4 splitters  342   a ,  342   b ,  342   c , and  342   d . Once subdivided, the signals may pass into four banks  344   a ,  344   b ,  344   c , and  344   d  of dual tuner links. Each of the dual tuner links within the banks  344   a - 344   d  may be configured to tune to two services within the signals received by that individual dual tuner link to produce one or more transport streams. Each of the dual tuner links  344   a ,  344 , b ,  344   c , and  344   d  transmits the transport streams to one of the low-voltage differential signaling (“LVDS”) drivers  348   a ,  348   b ,  348   c , and  348   d . The LVDS drivers  348   a - 348   d  may be configured to amplify the transport signals for transmission to the back-end  352 . In alternate embodiments, different forms of differential drivers and/or amplifiers may be employed in place of the LVDS drivers  348   a - 348   d . Other embodiments may employ serialization of all of the transport signals together for routing to the back end  352 . 
         [0033]    As illustrated, the front-ends  341   a, b  may also include microprocessors  46   a  and  46   b . In one embodiment, the microprocessors  346   a, b  control and/or relay commands to the banks  344   a - 344   d  of dual tuner links and the 1:4 splitters  342   a - 342   d . The microprocessors  346   a, b  may comprise, for instance, ST10 microprocessors produced by ST Microelectronics. In other embodiments, a different processor may be used or the control may be derived from processors in the back end  352 . The microprocessors  346   a, b  may be coupled to LVDS receiver and transmitter modules  350   a  and  350   b . The LVDS receiver/transmitter modules  350   a, b  facilitate communications between the microprocessors  346   a, b  and components on the back-end  352 , as will be described further below. 
         [0034]    Turning next to the back-end  352 , the back-end  352  includes LVDS receivers  354   a ,  354   b ,  354   c , and  354   d  which are configured to receive transport stream signals transmitted by the LVDS drivers  348   a - 348   d . The back-end  352  also includes LVDS receiver/transmitter modules  356   a  and  356   b  which are configured to communicate with the LVDS receiver/transmitter modules  350   a, b.    
         [0035]    As illustrated, the LVDS receivers  354   a - 354   d  and the LVDS receiver/transmitters  356   a, b  are configured to communicate with controllers or transport processors  358   a  and  358   b . In one embodiment, the transport processors  358   a, b  are configured to receive the transport streams produced by the dual tuner links in the front-ends  341   a, b . The transport processors  358   a, b  may also be configured to repacketize the transport streams into Internet protocol (IP) packets which can be multicast over the local network described earlier. For example, the transport processors  358   a, b  may repackage broadcast protocol packets into IP protocol packets and then multicast these IP packets on an IP address to one or more of the client devices 
         [0036]    The transport processors  358   a, b  may also be coupled to a bus  362 , such as a 32 bit, 66 MHz peripheral component interconnect (“PCI”) bus.  Through the bus  362 , the transport processors  358   a, b  may communicate with another controller or network processor  370 , an Ethernet interface  384 , and/or an expansion slot  366 . The network processor  370  may be configured to receive requests for services from the local network and to direct the transport processors  358   a, b  to multicast the requested services. Additionally, the network processor  370  may also manage the operations and distribution of data signals containing audio and video content by receiving the requests from the client devices, maintaining a list of currently deployed services, and matching or allocating the receiving resources for providing these services to the STBs  22   a - 22   n . The network processor may also be manage network status through the receiving, monitoring, and/or processing of network related announcements provided the gateway devices  10 . In one embodiment, the network processor is an IXP425 produced by Intel and executes software code that determines a classification of a network announcement after receiving information regarding the announcement. Processor  14  further executes code that initializes a timing interval based on the classification of the announcement, and provides an error message if information regarding a second network announcement of a same classification as the earlier received announcement is not received before the timing interval expires. While not illustrated, the network processor  370  may also be configured to transmit status data to a front panel of the satellite gateway device  300  or to support debugging or monitoring of the satellite gateway device  300  through debug ports. 
         [0037]    As illustrated, the transport processors  358   a, b  are coupled to the Ethernet interface  368  via the bus  362 . In one embodiment, the Ethernet interface  368  is a gigabit Ethernet interface that provides either a copper wire or fiber-optic interface to the local network. In other embodiments, other interfaces such as those used in digital home network applications may be used. In addition, the bus  362  may also be coupled to an expansion slot, such as a PCI expansion slot to enable the upgrade or expansion of the satellite gateway device  300 . 
         [0038]    The transport processors  358   a, b  may also be coupled to a host bus  64 . In one embodiment, the host bus  364  is a 16-bit data bus that connects the transport processors  358   a, b  to a modem  372 , which may be configured to communicate over the public service telephone network (PSTN)  28 . In alternate embodiments, the modem  372  may also be coupled to the bus  362 . 
         [0039]    The network processor  370  may also contain a memory for storing information regarding various aspects of the operation of the satellite gateway device  300 . The memory may reside within the network processor  370  or may be located externally, although not shown. The memory may be used to store status information, such as information about timers and network announcements, as well as tuning information for the receiving resources. 
         [0040]    It is important to note that transport processors  358   a,b , network processor  370 , and microprocessors  346   a, b  may be included in one larger controller or processing unit capable of performing any or all of the control functions necessary for operation of the satellite gateway device  300 . Some or all of the control functions may also be distributed to other blocks and not affect the primary operation within satellite gateway device  300 . 
         [0041]    Referring to  FIGS. 4 to 6 , a flowchart illustrating an exemplary method using embodiments of the present disclosure is shown. For purposes of example and explanation, the method of  FIGS. 4 to 6  will be described with reference to system  100  of  FIG. 1  and the elements of gateway device  10  of  FIG. 2 . The method of  FIGS. 4 to 6  may equally be described with reference to the elements of satellite gateway  20  of  FIG. 1 . Also for purposes of example and explanation, the steps of  FIGS. 4 to 6  will be primarily described with reference to only one gateway device  10 . In practice, however, it is anticipated that each gateway device  10  in a given MDU installation will to separately and independently perform the steps of  FIGS. 4 to 6 . The steps of  FIGS. 4 to 6  are exemplary only, and are not intended to limit the present embodiments in any manner. 
         [0042]    At step  410 , the method starts. According to an exemplary embodiment, the method starts at step  410  only if the feature for detecting and mitigating operational problems (e.g., hardware and/or software module failure, etc.) associated with one or more gateway devices  10  is enabled. For purposes of example explanation, it is assumed that this feature is initially enabled. 
         [0043]    At step  420 , gateway device  10  clears a table and all timers. According to an exemplary embodiment, each gateway device  10  stores a table in memory  16  that is used for the detection and mitigation of operational problems (e.g., hardware and/or software module failure, etc.) associated with one or more gateway devices  10  (including itself). According to this exemplary embodiment, each gateway device  10  periodically transmits and re-transmits announcements according to a pre-defined protocol, such as the Session Announcement Protocol (SAP) which carries the Session Description Protocol (SDP). Both the SAP and SDP are known in the art. There are various types or classifications of announcements including announcements related to network availability, proxy modem host availability, client device software availability, or other types of application-related matters. For each unique SAP packet SDP payload received by gateway device  10 , the aforementioned table in memory  16  stores: (i) the IP address of the sending gateway device  10  (i.e., a gateway device  10  identifier), (ii) the type or classification of SAP announcement, (iii) the media title (which corresponds to item (ii)), and (iv) the time of packet arrival. For each gateway device  10  and type or classification of announcement, processor  14  maintains a corresponding timer. At step  420 , processor  14  clears the aforementioned table in memory  16  and all of its corresponding internal timers that are used for the detection and mitigation of operational problems. These internal timers are part of a failure detection module of processor  14 . 
         [0044]    At step  430 , gateway device  10  listens for all types of announcements. According to an exemplary embodiment, gateway device  10  monitors SAP announcements issued by itself, as well as by any or all other active gateway devices  10 , under the control of processor  14  at step  430 . Gateway device  10  may for example monitor a particular IP address under the control of processor  14  in order to listen for the announcements at step  430 . 
         [0045]    At step  440 , a determination is made as to whether an announcement is received by gateway device  10 . According to an exemplary embodiment, processor  14  detects whether an announcement is received from another gateway device  10  or itself, to thereby make the determination at step  440 . If the determination at step  440  is positive, process flow advances to “C” (see  FIG. 5 ), as will be described later herein. Alternatively, if the determination at step  440  is negative, process flow advances to step  450  where a determination is made as to whether any timer is expired. According to an exemplary embodiment, processor  14  checks its internal timers (i.e., the ones cleared at step  420 ) to make the determination at step  450 . As indicated in  FIG. 4 , process flow also advances to step  450  from “D” (see  FIG. 5 ), as will be described later herein. 
         [0046]    It is important to note that a number of methods of maintaining or monitoring a time interval may be possible in place of using an internal timer in processor  14 . For example, the timer may be an external clock circuit connected to a crystal, a sampling circuit that samples an existing continuous time signal, or a software algorithm that runs on processor  14 . 
         [0047]    If the determination at step  450  is positive, process flow advances to “E” (see  FIG. 6 ), as will be described later herein. Alternatively, if the determination at step  450  is negative, process flow advances to step  460  where a determination is made as to whether a table reset is requested. According to an exemplary embodiment, the table in memory  16  referred to in step  420  may be manually reset from time to time by a network administrator or other authorized individual, and/or may be automatically reset based on a user setting. Accordingly, processor  14  makes the determination at step  460  by detecting whether this table needs to be reset. 
         [0048]    If the determination at step  460  is positive, process flow loops back to step  420  as indicated by “A”. Alternatively, if the determination at step  460  is negative, process flow advances to step  470  where a determination is made as to whether the feature for detecting and mitigating operational problems (e.g., hardware and/or software module failure, etc.) associated with one or more gateway devices  10  (including itself) is enabled. According to an exemplary embodiment, this feature of the present disclosure may be manually turned on (i.e., enabled) and off (i.e., disabled) by a network administrator or other authorized individual. Accordingly, processor  14  makes the determination at step  470  by detecting whether this feature is enabled. If the determination at step  470  is positive, process flow loops back to step  430  as indicated by “B”. Alternatively, if the determination at step  470  is negative, process flow advances to step  480  where the method ends. 
         [0049]    Referring now to  FIG. 5 , “C” (i.e., a positive determination at step  440  of  FIG. 4 ) advances to step  510  where a determination is made as to whether the announcement received at step  440  represents a new type or classification of announcement from a particular gateway device  10 . According to an exemplary embodiment, processor  14  makes the determination at step  510  by examining entries of the aforementioned table in memory  16 . As previously indicated above, announcements related to network availability, proxy modem host availability, client device software availability, or other types of application-related matters may represent different types or classifications of announcements. 
         [0050]    If the determination at step  510  is positive, process flow advances to step  520  where gateway device  10  creates a new table entry and initializes a corresponding timer for the particular gateway device  10  and type or classification of announcement. According to an exemplary embodiment, processor  14  performs step  520  by creating a new table entry in memory  16  and initializing a corresponding timer internally. From step  520 , process flow advances to step  530  where gateway device  10  sends a notification message under the control of processor  14  to NOC  40  (via MDF  20  and internet  30 ) to indicate that a new table entry has been created and that a corresponding timer has been initialized. 
         [0051]    Referring back to step  510 , if the determination there is negative, process flow advances to step  550  where a determination is made as to whether a corresponding timer is expired. According to an exemplary embodiment, processor  14  makes the determination at step  550  by detecting whether its internal timer corresponding to the particular gateway device  10  and type or classification of announcement received at step  440  is expired. 
         [0052]    If the determination at step  550  is positive, process flow advances to step  530  where gateway device  10  sends an error notification message under the control of processor  14  to NOC  40  (via MDF  20  and internet  30 ) to indicate that a timer corresponding to the particular gateway device  10  and type or classification of announcement has expired. In other words, if the determination at step  550  is positive, the error notification message sent at step  530  also indicates that gateway device  10  has not received a second or subsequent announcement of the same type or classification as a previously received announcement from a particular gateway device  10  before the corresponding timer expired. Accordingly, this error notification message notifies NOC  40  of a potential operational problem associated with the applicable gateway device  10 , and allows for corrective action to be taken. 
         [0053]    From step  530  or if the determination at step  550  is negative, process flow advances to step  540  where gateway device  10  starts or resets the corresponding timer. According to an exemplary embodiment, processor  14  performs step  540  by starting or resetting the corresponding timer. From step  540 , process flow loops back to step  450  (see  FIG. 4 ) as represented by “D”. 
         [0054]    Referring now to  FIG. 6 , “E” (i.e., a positive determination at step  450  of  FIG. 4 ) advances to step  610  where a determination is made as to whether the last notification message was the first notification message sent for a to particular gateway device  10  and type or classification of announcement, or whether a time period, such as 10 minutes, has passed since the last notification message was sent for the particular gateway device  10  and type or classification of announcement. According to an exemplary embodiment, processor  14  makes the determination at step  610  using internally maintained timing information. 
         [0055]    It is important to note that each type or classification of announcement may use a different time period, further enhancing the operation of the present disclosure. For example, a network availability announcement typically has a repetition time period of approximately two seconds while a network time announcement has a repetition time period of approximately twelve hours. 
         [0056]    If the determination at step  610  is positive, process flow advances to step  620  where gateway device  10  sends a notification message under the control of processor  14  to NOC  40  (via MDF  20  and internet  30 ) to indicate the condition determined at step  610 . From step  620  or if the determination at step  610  is negative, process flow advances to step  630  where a determination is made as to whether all expired table entries in memory  16  have been handled. According to an exemplary embodiment, processor  14  makes the determination at step  630  using internally maintained status information. 
         [0057]    If the determination at step  630  is positive, process flow loops back to step  430  (see  FIG. 4 ), as indicated by “B”. Alternatively, if the determination at step  630  is negative, process flow advances to step  640  where the next expired table entry is handled. From step  640 , process flow loops back to step  610 . 
         [0058]    As described above, the flowchart of  FIGS. 4 to 6  provides mechanisms for detecting and mitigating failure conditions associated with gateway devices  10 . In summary, each active gateway device  10  periodically re-transmits its announcements. A failure detection module of processor  14  includes a set of timers, namely one timer for each combination of gateway device  10  and unique announcement type/media title (e.g., [GW 1  id, announcement type  1 ], [GW 1  id, announcement type  2 ] . . . [GW 3  id, announcement type  1 ], [GW 3  id, announcement type  2 ] . . . ). According to principles of the present embodiments, when a new announcement type/media title is received from a particular gateway device  10 , an entry corresponding to the particular gateway device  10  and announcement type/media title is placed in the table in memory  16  and a timer for the entry is started. If the timer expires before another announcement of that type/media title is received from the particular gateway device  10 , action is taken (e.g., notification message is sent to NOC  40 , initiate a service call, new software download, re-boot failed gateway device without operator intervention, etc.) to indicate/resolve the problem. The notification messages may include service information including the IP address of the failed gateway device  10  as well as the failed service. Once a timer expires, the system notification may be periodically resent until the announcement from the particular gateway device  10  is again received or the failure detection module is reset or administratively disabled. 
         [0059]    The failure of a gateway device  10  to receive another gateway device&#39;s  10  announcement(s) can indicate a failure of the sending gateway device&#39;s  10  hardware (e.g., power supply, network interface, etc.) or a failure of one or more of its software modules responsible for the service that it provides. The failure of a gateway device  10  to receive its own announcement(s) can indicate a failure of one or more of its software modules responsible for the service that it provides. In an installation of three or more gateway devices  10 , the system notification messages are redundant, thereby enhancing the reliability of such notifications. For example, two operational gateway devices  10  can detect a loss of one of more announcements from a failed third gateway device  10 , and each gateway device  10  will send a notification message indicating this fact to NOC  40 . 
         [0060]    It is also important to note that the present embodiments primarily cover failure detection for gateway devices  10 , but may also be used in conjunction with failure mitigation. Further, the disclosed embodiments describe using SAP announcements in detection and mitigation schemes. 
         [0061]    SAP announcements are user datagram packets (UDP) containing a SAP (Request for Comment (RFC) 2974) payload, itself containing a SDP (RFC 2327) payload, and transmitted by each active gateway device  10  on a well-known multicast IP address. Each class of SAP announcement advertises a service offering and provides details on its capabilities and how to access the service. For example, current SAP announcements include network availability, proxy modem host availability, client device software availability, and network time. 
         [0062]    The embodiments of the present disclosure describe provide several advantages with respect to operation of a system requiring a monitoring process for hardware or software failures during operation. These advantages include, but are not limited to, a self monitoring capability which may give a network monitor more information about the state of the system and use of standard IP messages, such as SAP announcements, to not only convey the system status such that anyone on the network can tell the activity status and indicate whether or not a network device is functional, but also to convey other important messages and information. Further, the use of such messages may allow polling by a remote system monitor or may allow information about the failure to be pre-emptively sent. Also, the various interval timeout values for the interval timers maintained by processor  14  may be remotely settable and the announcement types may be remotely configurable. Once notification messages are generated, the messages could be sent to multiple operator-specified NOC destinations. 
         [0063]    As described herein, the embodiments of the present disclosure relate to a failure monitoring technique has been developed so that hardware and software failures in a multiple gateway system may be detected and reported. In a single gateway system, the approach supports failure detection of key software modules. The embodiments of the present disclosure address, among other things, various classes of problems in a multiple gateway device installation, including the fact that gateway devices  10  with non-redundant power supplies can&#39;t detect their own power supply failure, and gateway devices  10  can&#39;t report their own failures if their communication interface hardware has failed. Further, embodiments of the present disclosure may also addresses the class of problems in a single or multiple gateway installation related to detecting catastrophic software module failures using a simple watchdog monitor-based approach, when multiple threads, third-party object code, etc. is involved. Also, although the initial implementation only broadcasts the SAP announcements either between gateway devices  10  or on the local network, extensions of this implementation, even utilizing other types of network announcements, could be developed such that these announcement could be sent to NOC  40 . 
         [0064]    While this disclosure has been described as having a preferred design, the present embodiments can be further modified within the spirit and scope of this disclosure. This application is therefore intended to cover any variations, uses, or adaptations of the disclosure using its general principles. Further, this application is intended to cover such departures from the present disclosure as come within known or customary practice in the art to which the embodiments pertain and which fall within the limits of the appended claims.